(1) For a significant fraction of all users --- perhaps even most users --- the twitter password is the same as the gmail password. Passwords are always hazmat and should be treated accordingly.
(2) I strongly dispute the idea that OAuth is hard to implement or is goofy to use. Unlike OpenID (which is both annoying to implement and also genuinely weird to use), OAuth's interface is simply a login page and a "yes/no" dialog. Your programming environment already has a library to do the scary math bits for you.
Is OAuth hard to implement compared to OpenID? No. Tough compared to plain old stored passwords and auth headers? Definitely.
I say this as someone who's using OAuth - because it's The Right Thing To Do For My Users - but any integration with a third-party service involves a lot more logic and state storage than just asking for their account name and password on your own site. Does the code do the right thing if the user doesn't do anything on the screen you redirect them to, closes it but they then refresh your page? Or how about if they decline and the provider doesn't send them back?
All the current authentication processes are horrible hacks. Do you really believe that user's check the URL bar if I throw them at a page that looks like Twitter's login one from my OAuth app? How about if I put a look-alike in an iframe within my page?
This is something that's really hard to hack on top of the current infrastructure. I'm really hoping something that users understand (or grow to understand) is buildable, but we shouldn't pretend we're in a happy place right now.
In startup-time, anything that takes a day to do is worse than something equivalent that takes 20 minutes.
Auth'ing Twitter using a user/pass meant that I could add Twitter support to Blogabond in 20 minutes. Reading Twitter's oAuth instructions took longer than that. For the amount of geek-cred it'd buy me, and the added headache if somebody physically broke into my datacenter and stole the production server, it's just not worth the extra time to implement.
As to your first point, naturally I have absolutely no leg to stand on there. Your mom will still use her bank password for her Twitter account, and I'm a bad person for storing it.
You think it's my mom I'm trying to protect here, but it's not. It's you. You're the one who's going to lose the user table in your database. Please take my word on that. Don't let it be full of valid passwords.
Maybe a bit of an improvement over the current method of using passwords would be to take the user's username and password, immediately using them to connect the account using OAuth, and then store them no longer. This would make the connection persistent if the user changed their password, and would eliminate a lot of the risk.
It really depends on the transaction cost of the thing implemented. If it takes a day to implement something that has a 2x signup rate that the 20 minute thing, you are clearly making a bad tradeoff.
This is engineering. There are no absolutes, just a series of tradeoffs.
This is the sort of time saver that will cost you time later, when you want to spend your time on authentication even less. Twitter is wanting to cut off basic auth because of "security issues" (http://apiwiki.twitter.com/OAuth-FAQ#Whenareyougoingtoturnof...), and while OAuth isn't required now, it likely will be soon.
This is a tragedy of the commons thing. As a web developer, you have a moral responsibility to help your users stay secure online. Teaching them that it's OK to enter their Twitter username and password on any site that asks for it (when Twitter are trying to teach them what OAuth is and why it matters to them) is irresponsible.
Sure, it's cheaper to implement. But you should be better than that.
And now that you've read the oAuth instructions, you should understand oAuth. It took me six hours to implement it for the first time, including reading the documentation. Granted, I was using a third-party library to handle the API interaction because, well, it's already been done - so why re-do it? ;)
> Auth'ing Twitter using a user/pass meant that I could add Twitter support to Blogabond in 20 minutes. Reading Twitter's oAuth instructions took longer than that.
With all due respect; I wrote a library for Kohana PHP which allowed Twitter to be used as a login in about an hour. If I'd just been integrating it would have been faster.
The beauty of Oauth is that it conforms to a specification - so any Oauth library for whatever language your working with will co-operate with Twitter.
I'd argue that the ease of implementation means that even if it saves you from one in a thousand chance of that headache it's worth it :)
(2) I strongly dispute the idea that OAuth is hard to implement or is goofy to use. Unlike OpenID (which is both annoying to implement and also genuinely weird to use), OAuth's interface is simply a login page and a "yes/no" dialog. Your programming environment already has a library to do the scary math bits for you.