Hacker News Reader

Comment by jasonkester | Hacker News Reader

I don't think the solution is to use oAuth either.

I mean, yeah, it's technically the right thing to do. But it's just shy of impossible to implement, and it presents a goofy user experience to your users.

So if all your thing does is post stuff to Twitter on behalf of your users, I think it's probably best to save yourself 40-odd hours of frustration and perplexity, and simply save their user/pass in your database. It is, after all, just somebody's Twitter account, not their banking credentials.

If you're logging into something where money can change hands, then yeah, go nuts and do the right thing. But not for some throwaway-password site where the worst thing that could possibly happen in the case of a compromise is that somebody whinges about their cat in one of your users' name.

View on HN

(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.

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.

I don't think I agree.

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.

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? ;)

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.

> 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 :)

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.

I mean, yeah, it's technically the right thing to do. But it's just shy of impossible to implement, and it presents a goofy user experience to your users.

oAuth is actually really easy to implement. I've done it several times now, never takes more than an hour.

I also find the user experience to be pretty solid too. Whats your specific complaint?

It is, after all, just somebody's Twitter account, not their banking credentials.

Problem being many people use the same password for Twitter as they do for their email.

I concur - I really like the user experience with oAuth.

As a user, you absolutely know that a) the service they're signing up for doesn't get their twitter credentials, b) they get more value out of the original service, c) they don't have to remember / make up / reuse yet another password.

It's a lot like the paypal experience... Paypal handles all the "dangerous" stuff, like billing information; the user knows that it's paypal handling it, because it's on paypal's site; when they're done paying for it, they get redirected back to the merchant. It's a workflow many, many people are very, very comfortable with. It's a far sight easier to wrap your brain around than OpenID, that's for sure.

Yes but how many people use the same password between all website? I was shocked recently when I saw that my mother was using the same password for a forum as her paypal account...

If you're storing people's password in plain text in your db you should make your potential users aware of this so people (like myself) can avoid accidentally using your site.

I don't get the `shy of impossible to implement` part. It takes a good coder just a couple of hours (and maybe one hour to someone who has done it before).

Reply on news.ycombinator.com