Twitter's OAuth has a gaping security hole
shkspr.mobi
shkspr.mobi
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.
In general, having the average naive user administer any aspect of security beyond choosing a "secure" password is a naive expectation. You can't afford to have both parties acting naively when it comes to Internet security. For this (non-naive) audience, managing OAuth tokens makes sense and Twitter can afford to be naive. For the rest of the Internet audience this approach is probably more dangerous than convenient.
The work around recommended by Twitter? Register a new twitter app that is read/write from the get go. :(
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?
And why is Alice always the bad guy (or chick)?