

How Not To Implement A Web Application That Handles External Authentication - archon810
http://beerpla.net/2010/02/03/how-not-to-implement-a-web-application-that-handles-external-authentication-using-betwittered-com-as-an-example/

======
tptacek
The only problem I have with this article is the insinuation that encrypting
passwords in cookies is a solution to this problem. Most of the tricks you
come up with to encrypt and store passwords will be broken, too.

~~~
IgorPartola
Agreed. It's also a conceptually wrong thing to do. The password _does not
belong_ there.

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

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

~~~
jasonkester
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.

~~~
tptacek
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.

~~~
JeremyBanks
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.

------
blhack
Storing the username and password in the cookie is _completely_ ridiculous,
but I just want to point out that it doesn't appear as though twitter itself
uses SSL either.

Unless I'm completely missing something, neither does facebook, or reddit, or
hacker news, or really any other website other than my bank.

edit: I had a complete lapse of thinking here and am totally wrong about this.
There are still lots of websites that do not use SSL, but twitter and facebook
are not among them, nevermind.

~~~
a2tech
Many websites post the forms to encrypted sites. Facebook and others do this-I
haven't looked into hacker news or reddit.

~~~
kogir
This doesn't do any good because the page that contains the form can be
transparently altered to post somewhere else by a man in the middle.

~~~
revetkn
Saying that it doesn't do any good might be a bit strong - it's still
vulnerable, but much less so than straight-up POSTing over an unencrypted
channel.

------
IgorPartola
So they didn't want to pony up the money for an SSL certificate, hired someone
who thought putting a password in browser cookies was a good idea and stored
the password in clear text... Where can I buy their stock?

------
pvg
_encrypt the username and password via a secure salted two-way hash_

I wonder what that means.

~~~
sketerpot
Loosely translated, it means "Don't try to figure this out yourself except for
fun; use a library like bcrypt instead."

------
zackattack
Let's say that I'm implementing a login form via AJAX. After the "Submit
button" click event, I fire up a jQuery ajax.get() to the auth script, and
then store logged-in status as a session cookie. This seems reasonably secure
except for the fact that the password gets passed plaintext via the network.
Is my best option to md5() it locally via JS, before I send it over? It's for
a charity website so I don't think it'll be a big target, but I don't think
that excuses bad security.

Sorry if this is better for StackOverflow, it just seems appropriate here as I
have gleaned some great coding tips via HN.

~~~
andymism
Yes, this will work if you want to keep from sending the password in plain
text. But you should make sure you send the request via POST rather than GET
and know that you are still vulnerable to replay attacks--an attacker could
just sniff out the username and hash, which they could present to you and
still authenticate on your site (though they wouldn't know the actual
password). Also, as far as md5 hashes go, rainbow table lookups work pretty
well, so hashing alone won't provide great password security.

Another way to solve your problem would be post to your auth script via SSL.
From what I know of SSL (correct me if I'm wrong, please), the handshake and
encrypted connection is established before any data is sent, which will
protect you against sending passwords in the clear and against password
sniffing.

------
zy1143
?this is hacker site?

