4 ms·

How Not To Implement A Web Application That Handles External Authentication

40 points by archon810 17y ago

blhack 17y ago
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 17y ago
  Many websites post the forms to encrypted sites. Facebook and others do this-I haven't looked into hacker news or reddit.
  - kogir 17y ago
    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 17y ago
      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.
    - tptacek 17y ago
      You're right in the general case, but in the API case it doesn't matter how the form is rendered because API clients don't parse forms.
  - blhack 17y ago
    It doesn't look like reddit or hacker news do. reddit: <form method="post" id="login_login-main" action="http://www.reddit.com/post/login" onsubmit="return post_user(this, 'login');" class="login-form-side"> HN: <form method="post" action="/y">
    - revetkn 17y ago
      ...but reddit's only 91 lines of lisp, what did you expect?
  - IgorPartola 17y ago
    Thanks to OpenID I don't have to worry about some of that.
jasonkester 17y ago
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.
- gommm 17y ago
  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...
- tptacek 17y ago
  (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 17y ago
    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 17y ago
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 17y ago
  Agreed. It's also a conceptually wrong thing to do. The password does not belong there.
IgorPartola 17y ago
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 17y ago
encrypt the username and password via a secure salted two-way hash I wonder what that means.
- sketerpot 17y ago
  Loosely translated, it means "Don't try to figure this out yourself except for fun; use a library like bcrypt instead."
zy1143 17y ago
?this is hacker site?
zackattack 17y ago
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.
- simonw 17y ago
  MD5ing in JavaScript doesn't help, because the thing you're defending against is a man-in-the-middle attack. If someone can get in the middle and steal an unencrypted password, they can also get in the middle and re-write your HTML form to remove the client-side encryption code. To protect against man-in-the-middle you need SSL.
- andymism 17y ago
  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.

40 points by archon810 17y ago

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 17y ago
Many websites post the forms to encrypted sites. Facebook and others do this-I haven't looked into hacker news or reddit.
- kogir 17y ago
  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 17y ago
    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.
  - tptacek 17y ago
    You're right in the general case, but in the API case it doesn't matter how the form is rendered because API clients don't parse forms.
- blhack 17y ago
  It doesn't look like reddit or hacker news do. reddit: <form method="post" id="login_login-main" action="http://www.reddit.com/post/login" onsubmit="return post_user(this, 'login');" class="login-form-side"> HN: <form method="post" action="/y">
  - revetkn 17y ago
    ...but reddit's only 91 lines of lisp, what did you expect?
- IgorPartola 17y ago
  Thanks to OpenID I don't have to worry about some of that.

jasonkester 17y ago

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.

gommm 17y ago
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...
tptacek 17y ago
(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 17y ago
  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 17y ago

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 17y ago
Agreed. It's also a conceptually wrong thing to do. The password does not belong there.

IgorPartola 17y ago

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 17y ago

encrypt the username and password via a secure salted two-way hash I wonder what that means.

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

zy1143 17y ago

?this is hacker site?

zackattack 17y ago

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.

simonw 17y ago
MD5ing in JavaScript doesn't help, because the thing you're defending against is a man-in-the-middle attack. If someone can get in the middle and steal an unencrypted password, they can also get in the middle and re-write your HTML form to remove the client-side encryption code. To protect against man-in-the-middle you need SSL.
andymism 17y ago
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.