12 August 2008
On iPhones and user credentials
Simon Willison argues that the iPhone app, Exposure, behaves “suspiciously” because it uses an embedded web view for users to log into to their Flickr/Yahoo accounts using OAuth.
The crux of his argument is that the embedded web view makes it impossible for users to tell if they are logging into the genuine Yahoo OAuth website or a phishing site. He cites Pownce as a better implementation because it opens the authentication page in Safari, which has lead to complaints/negative reviews from users due to the interruption of having to exit the Pownce app, sign in in Safari, then return to the Pownce app.
Whilst I can see his point about the transparency of using Safari directly, I’m not convinced that it’s worth compromising on the end-user experience to attain some kind of technical compliance with a protocol that most users haven’t heard of nor care about. More to the point, I’m not convinced this is as big a security issue as is being made out.
Ultimately, security often boils down to trust. Do you trust Service X with your credentials and personal information? If the answer is no, then you should not use Service X.
Using an embedded web view in the way that Exposure does isn’t really any different from a native login UI using iPhone interface widgets – without the source code to that application you have absolutely now way of knowing what that app is doing with your credentials. Most of the service-based iPhone apps that I use have a native iPhone login screen – NetNewsWire, Twitter etc. Am I wary of inputting my login details, despite the fact that they could be doing anything with them? No, because I trust the developers of these apps with my credentials (in the same way that I trust them with the same data when I use NewsGator or Twitter.com).
By passing users over to Safari to login – despite the transparency – all they are really doing is shifting the burden of trust on to the login provider and damaging the user experience overall.
Return to home page | Check out my tumblelog
5 Comments on this article
Return to home page | Check out my tumblelog
Commenting on this article is now closed
1. Comment by Luca Mearelli on 12 Aug 2008 at 14:08
I think that there is a little misunderstanding about where the user is required to login and which credentials he is required to give away,
Exposure is asking for your flickr login credentials. It’s not a service based app asking for its password through a web page instead of a native login form.
The assumption of oauth is that it’s generally bad to give your credentials for one service to another service just to connect the two, but i admit that delegating authorization is a challenge for the usability, plus it’s a bit hard to educate the users to the problems after years of applications happily asking for your email password to get at the contacts :)
2. Comment by Luke Redpath on 12 Aug 2008 at 14:08
I disagree that Exposure isn’t a service-based app – it’s just using somebody else’s service ;)
Don’t get me wrong, I see the motivation behind a central point of authorization but I still believe that it ultimately comes down to whether or not you trust the authors to use your credentials in a responsible way.
I can think of one way around this that doesn’t require leaving the app – the iPhone webkit view lets you hold down on links and see the URL. Instead of presenting the user with the authorisation screen directly, present them with an intermediate page that explains what is about to happen and why, and then a link to take them to the login page. Any user that cares can simply hold down on the “take me to the login screen” link to verify it’s destination.
3. Comment by Blaine Cook on 13 Aug 2008 at 05:08
Hi Luke,
I posted a comment on Simon’s flickr photo, but I did want to address your alternate proposal. Does it really make things better to have an additional click that prevents overt web-based phishing (but doesn’t prevent app-level snooping) versus having an application switch like the Pownce app?
Beyond that, your proposal is trivially exploitable, since application authors could just create a faux webkit view that provides a faked link popup.
I’d propose a simpler solution – developers could, before dropping into Safari, provide a tiny bit of documentation informing users that they need to go to the web to authorise their application.
OAuth came out of my worry that if the Twitter API became popular, we’d be spreading passwords all around the web. OAuth took longer to finish than it took for the Twitter API to become popular, and as a result many Twitter users’ passwords are scattered pretty carelessly around the web. This is a terrible situation, and one we as responsible web developers should work to prevent.
4. Comment by Luke Redpath on 13 Aug 2008 at 08:08
Blaine,
I agree that my proposed solution still isn’t ideal; I don’t actually believe there is a good solution that meets both aims and your point that it could be easily spoofed by the developer brings me back to me original point, that trust is the key aspect here.
5. Comment by Simon Willison on 14 Aug 2008 at 09:08
OAuth massively improves the situation with regards to trust because it introduces two new abilities (which handing over your username and password don’t provide). The first is the ability to allow only a subset of abilities – “this app can post new photos but it can’t delete old ones” for example. The second is the ability to revoke permissions on a per-application basis – you can disable access for a rogue application without needing to change your password (and then go out and tell all of the good applications what your new password is).