As the maker of an iOS Twitter client that used to use OAuth (now uses xAuth), I can tell you it's trivial to retrieve the user's username and password from the embedded UIWebView. If someone wants to steal user credentials, they'll still be able to.
Twitter created xAuth; no one forced it on them. It's odd that they would remove it now when they could have moved everyone to the web workflow when they transitioned away from basic auth.
When one further considers that they're giving developers only 2 weeks to comply, it's hard to escape the feeling that this isn't really about security and is more about tightening the noose on third-party developers.
Intentional malice will get you banned from the App Store, so there are incentives not to do it. Accidental stupidity ("our database got hacked") won't.
So if you actually want to protect your users, you can now take yourself out of the loop. If you want to fuck over your users, well, you've always been able to do that and you still can do it.
> So if you actually want to protect your users, you can now take yourself out of the loop.
That doesn't even begin to make sense for a native client. Insofar as it comes to security, trust, and data storage, the native client is the user, and they can't be taken out of the loop.
This differs quite a bit from a web service, which is a situation in which OAuth actually makes sense.
I think jrockway is saying that because with Oauth, you shouldn't normal have a users password at all, if a user's password leaks from a given app then the app author won't have an excuse and thus would be banned from the app.
Oauth doesn't protect the user from malcious apps but it protects the user from dumb app and it keeps apps from "playing dumb" when they give info to a third party.
On the other hand, I know nothing of Xauth. It too may allow you not to save passwords.
> I think jrockway is saying that because with Oauth, you shouldn't normal have a users password at all, if a user's password leaks from a given app then the app author won't have an excuse and thus would be banned from the app.
While I understand what he's saying, I don't think the risk assessment makes any sense. When is the last time you heard of a native application leaking passwords in a way that made them accessible to someone who didn't already have access to your desktop or mobile phone?
> On the other hand, I know nothing of Xauth. It too may allow you not to save passwords.
With xAuth, you exchange the user's username and password for a revokable authentication token. The application can then use that token for future requests, discarding the provided username/password.
> it keeps apps from "playing dumb" when they
> give info to a third party.
What companies are giving out usernames and passwords to 3rd parties, and then trying to 'play dumb?' It seems to me like you're talking about companies that sell your email address to 3rd parties, but that's a whole different ballgame. At the risk of venturing off into bad analogy land, you're claiming that companies are giving away the keys to your house (to 3rd parties), when you really mean that they're giving away your mailing address (to 3rd parties).
Twitter created xAuth; no one forced it on them. It's odd that they would remove it now when they could have moved everyone to the web workflow when they transitioned away from basic auth.
When one further considers that they're giving developers only 2 weeks to comply, it's hard to escape the feeling that this isn't really about security and is more about tightening the noose on third-party developers.