It's twitter that's stupid for still not having implemented oAuth. What's keeping them from implementing it TODAY? They are putting people's passwords at risk.
No, _people_ are putting people's passwords at risk ;) That said, I completely agree. Especially sad since Blaine Cook was involved with creating the first Ruby implementation of the protocol, more than a year ago.
I dunno if you've tried using and implementing OAuth, but it is a gigantic pain in the ass. A big factor driving the bewilderingly huge number of twitter mashups is how easy it is to use their API. Not implementing OAuth was a great move.
It's stupid to give any service any credentials except those created specifically for that service. (This dictum includes the common practice of using the same password for multiple services.) This is not an issue of paranoia. Fraudulent or malicious services are, of course, a concern, but not the only one. You are not only trusting these people to use your credentials appropriately, you're trusting them to store/transmit/manage those data securely.
The problem is that this advice will never sink home with users. So Twitter needs to step up and protect its users by implementing OAuth (or something similar). People will do dumb things like this so long as the risks seem remote (and they always will, until it's too late) and there's even a minor benefit to be had. The point is: Anyone that wants to could steal a bunch of Twitter users' passwords right now with hardly any work.
Twitter should regard this as a gaping security hole. It doesn't matter that it's not technically a vulnerability in any of the code they've written.
Ok, So; I posted on monday about mytwitternotebook, an app I made.
Originally, I made it so that you signed up with an openID, and then put in your twitter username, and then got a verification DM, and then verified.
_Nobody_ understood it.
I switched to using twitter username and password, and nearly instantly, my user-base doubled.
I don't store the UN or PW at all, ever; I verify with the twitter server, and forget about it, you don't even need to put your UN or PW into my site to use my service, ever, it can be done completely by Direct Message.
It may be stupid to share your password, but it's stupid to use the same password everywhere. Turns out, it may be stupid, but it's easy, and you get good results.
It's not so much a matter of password exposure for people who share passwords with other sites (that is their own fault), it's having to trust all these sites you put your password into to keep it secure (you may claim you're not storing it, but how can I verify that). The risk of your twitter password getting out is impersonation and taking control of your twitter account, with no way to recover it. Remote keys have problems too, but the idea behind remote keys is that you enable third party access to the core functionality but the authentication and control of the account itself is out of reach of the third party.
I wonder if the "one password" paradigm is the problem. What if Twitter (and any other web service) could have multiple passwords per user. Now you can give away a password at will to whatever Twitter service you want. When you don't want it to be used anymore, just delete it.
Simpler for whom? The user who has to manage N passwords for N services, instead of one password? I'd rather Twitter's staff suffer a moderate amount of pain once than have every user suffer lesser pains continuously.
Programmers (myself included) too often fail to consider whether "technically simpler" is "actually simpler". It is one of the things that ensures the poor quality of software. We'd do well to understand that our job is, first and foremost, to make life easier for the people using our software. This may require martyrdom from time to time.
Besides, OAuth isn't all that complicated. Distilled, it's similar to your idea but with several additional benefits, not the least of which is that there are existing implementations to help you on your path.
That's similar to, but more sophisticated, than what FriendFeed does. FF has an "API password" that you plug into other sites, and you can change the API password at any time, but they don't have separate API passwords for different sites. If there's a rogue site abusing your account, then you have to revoke all sites.
I'd love to have an alternative to storing usernames and passwords. I wrote a web based twitter/identi.ca client mainly for my own use, but it's public and there are people using it, and I've been thinking about purging the auth data every month or so mainly because if I hadn't written it there's no way I'd just blindly hand over my password to some weirdo who happened to write a handy client for my phone. At least then the users could be assured that their authentication info will be removed at a predictable interval.
It's no problem at all. What the fuck is anybody going to do with 5000 twitter passwords? Post something profane pretending to be you? Create link spam, when everything in twitter is rel=nofollow anyway? There's no way to make money by stealing a bunch of twitter accounts.
That's why it's no problem to hand over your twitter credentials. There's no point in stealing your twitter password. It's not useful for anything.
The better alternative is to use random passwords (from a bookmarklet, for instance) so that you'll have no psychological resistance to changing it to ditch a crappy service.
The only problem with this approach is that you cannot de-provision individual bad actors. It's an all or nothing approach. There's a lot of work involved in re-provisioning the good guys, and where there's work, there's psychological resistance.
Agreed. It should be obvious from Twitter by now that folks like building services. It would take a few days of engineering to create "temporary" logins these services could use.
FTA: but the bigger question is when will Twitter users decide to stop handing over their passwords to unvetted third parties who may abuse those details?
Won't the service need to gather a significant number of users/passwords and remain secure for sometime before they are vetted? So won't some people then be giving their details before it is officially vetted.
