21–26 of 26 posts
What approaches do other OAuth providers take to this problem? Revoking all OAuth tokens on a password change/reset takes away a good chunk of the value that many people get from using OAuth.
Agreed, but would it be difficult to have a checkbox marked "revoke all permissions to use my account from all applications" to the reset password menu?
What approaches do other OAuth providers take to this problem? Revoking all OAuth tokens on a password change/reset takes away a good chunk of the value that many people get from using OAuth.
When you connect to a site with OAth, doesn't it require that you a) sign in using Twitter or b) are already signed in using Twitter? I would think this is necessary, otherwise people with multiple Twitter accounts, each of which use the same OAuth site, would end up with a lot of confusion.
So given this, Eva would have to a) sign in to Alice's Twitter account, which she can't do because Alice changed her password, or b) continue to be signed into Alice's Twitter account, while Alice changes her password, which would also be a security compromise of Twitter in general, no need to get into OAuth at that point.
Did I crack this thing or did I miss something?
That's a feature, not a bug. In twitter as far as I remember you have the opportunity to revoke tokens yourself. It's definitely not a security hole.
It's at the intersection of security and user experience. Changing your password because you think it's been compromised is a different use case from changing your password because you've been using it for years or forgotten it.
As looking at the issues with that infamous little "lock" icon to indicate HTTPS shows, security and UX intersections are always difficult.
Seriously though, why do all the security examples and scenarios always involve an Alice and a Bob? And why is Alice always the bad guy (or chick)?
Earlier quoted context omitted.
It's at the intersection of security and user experience. Changing your password because you think it's been compromised is a different use case from changing your password because you've been using it for years or forgotten it.
At the risk of encouraging Yet Another Warning, would displaying a notice after changing passwords that sites are still authorized be a solution? I'd say that it should have links to more info and to the Connections page, but I despair of users giving up at any sign of warnings. As looking at the issues with that infamous little "lock" icon to indicate HTTPS shows, security and UX intersections are always difficult.
It's difficult because people don't expect another step after they've changed their password, and (I'd guess) wouldn't immediately understand the need for it.
Perhaps the answer is Yet Another Configuration Setting: the default option revokes all site authorisations when you change your password; the alternate option allows (but forces) you to think about it.