why would you need to transmit the unique salt? why would you transmit anything other than the form to the client? all the checks would be done on the server side.
a) user enters username/password
b) server looks up in a file the unique string and appends it to the password
c) server finds username's salted-password hash
d) server extracts hash from stored salted-password hash (possibly the first 4 characters or whatever)
e) server concatenates salt, plaintext password and unique string and hashes via sha-N/md5
f) server compares to stored salted-password and if same performs login. otherwise sends generic "invalid username/password combination" message.
I think stcredzero is concerned about the plaintext password passing through the pipes.
In this case, unique salts and hashes are used to simply protect the database; when the data is stolen, a rainbow attack will not effectively work.
Hashing those passwords also protects the user who uses the same email/id/password everywhere; if your db is compromised, you don't also compromise the user's identity (e-mail accounts, banking, etc).
It depends on the app, but I also think sending salts to the client and doing some md5/javascript in the browser is generally overkill.
Could not agree any more strongly about this. You still need to use bcrypt to store passwords, because you will eventually screw up Unicode and SQL on a complicated form somewhere and give up your whole password database. But if you're willing to spend ever a quarter person/day on password auth, there is no economy at all to skipping SSL.
If you're connecting to a website that looks the same, but the URL is slightly different, it won't help. What's more, the URL doesn't have to be different for the entire user's session.
Could you explain further what sort of MITM attack you mean for which SSL doesn't help? (Are you assuming users who don't insist on an SSL connection with a recognized domain?)
The certificate needs to match the domain and bear a signature chain that traces back to your root certificate store. SSL was designed to assume that the DNS is totally insecure, which of course it always has been.
The problem with Man in The Middle attack is that it's a fundamental problem. It's on the same level as the Two Generals problem. In a way it's a variation of it. The only way to deal with it is to have a 2nd channel. Everyone who has to deal with security would be well advised to actually study this, and not blithely wave it away:
This isn't true at all. Mutual key agreement between two unrelated parties talking for the first time is hard problem. SSL gets rid of that problem by having every participant in the system rendezvous with 10+ CA's before they talk to anyone.
The SSL problem is mutual key agreement between two related parties communicating for the first time, and it's an easy one to solve.
There is a really persistant meme that SSL breaks when the DNS breaks, because all that happens when your certificate doesn't match or verify is that you get a warning. That warning says SSL isn't working anymore. You're not supposed to click through it. Real applications that use SSL under the hood don't pop up warnings: they freak out and quit.
"There is a really persistant meme that SSL breaks when the DNS breaks, because all that happens when your certificate doesn't match or verify is that you get a warning. That warning says SSL isn't working anymore. You're not supposed to click through it."
I didn't know it was this bad, Browsers should "freak out" and totally refuse to proceed with the page then.
The problem with this is that SSL certificates can become nonverifiable through innocuous circumstances --- for instance, by expiring, or by moving. Most providers and most users would not accept a hard failure in this case.
And there you have one of the biggest problems with DNSSEC --- without a massive software revamp, there's no "soft" failure mode. gethostbyname() doesn't have a warning channel.
OK, you agree SSL does protect savvy users from MITM attacks.
You're talking about users who can be tricked into what are essentially non-SSL or degraded SSL (certificates from untrustworthy authorities) sessions, because they misread the URL bar or ignore warnings. That's a legitimate concern, most users are easily tricked, but that's not a vulnerability of SSL itself.
That may or may not be true, but what is certain is that additional mucking around with salts, Javascript crypto, and protocols isn't going to improve the story you get with HTTPS.
Comments
So the unique salt has to be transmitted from the server to the client in order to do authentication? Why not just use a hash of the username?
why would you need to transmit the unique salt? why would you transmit anything other than the form to the client? all the checks would be done on the server side.
a) user enters username/password
b) server looks up in a file the unique string and appends it to the password
c) server finds username's salted-password hash
d) server extracts hash from stored salted-password hash (possibly the first 4 characters or whatever)
e) server concatenates salt, plaintext password and unique string and hashes via sha-N/md5
f) server compares to stored salted-password and if same performs login. otherwise sends generic "invalid username/password combination" message.
That's exactly what I'm doing.
I think stcredzero is concerned about the plaintext password passing through the pipes.
In this case, unique salts and hashes are used to simply protect the database; when the data is stolen, a rainbow attack will not effectively work.
Hashing those passwords also protects the user who uses the same email/id/password everywhere; if your db is compromised, you don't also compromise the user's identity (e-mail accounts, banking, etc).
It depends on the app, but I also think sending salts to the client and doing some md5/javascript in the browser is generally overkill.
SSL certs are like $15/year. Not sure why people don't just get them instead of playing with md5/javascript...
Could not agree any more strongly about this. You still need to use bcrypt to store passwords, because you will eventually screw up Unicode and SQL on a complicated form somewhere and give up your whole password database. But if you're willing to spend ever a quarter person/day on password auth, there is no economy at all to skipping SSL.
You can't rely entirely on SSL. You're still vulnerable to man in the middle attacks, among other things.
No, the whole point of SSL is that it is not vulnerable to MITM attacks, because the client carries anchor keys.
If you're connecting to a website that looks the same, but the URL is slightly different, it won't help. What's more, the URL doesn't have to be different for the entire user's session.
If you want to call that a "man in the middle attack", I won't argue, but as far as I'm concerned, that's a UI problem.
Could you explain further what sort of MITM attack you mean for which SSL doesn't help? (Are you assuming users who don't insist on an SSL connection with a recognized domain?)
DNS poisoning enables a MITM attack even if you're connecting to your safe, legitimate domain.
The certificate needs to match the domain and bear a signature chain that traces back to your root certificate store. SSL was designed to assume that the DNS is totally insecure, which of course it always has been.
SSL throws all sorts of warnings if the cert doesn't match the domain.
The problem with Man in The Middle attack is that it's a fundamental problem. It's on the same level as the Two Generals problem. In a way it's a variation of it. The only way to deal with it is to have a 2nd channel. Everyone who has to deal with security would be well advised to actually study this, and not blithely wave it away:
http://www.webmasterworld.com/website_technology/3711575.htm
Read the whole thread and learn. SSL can only protect savvy users. Depending on how sensitive your data is, this can still be a problem.
Combining this with DNS poisoning would be particularly bad.
This isn't true at all. Mutual key agreement between two unrelated parties talking for the first time is hard problem. SSL gets rid of that problem by having every participant in the system rendezvous with 10+ CA's before they talk to anyone.
The SSL problem is mutual key agreement between two related parties communicating for the first time, and it's an easy one to solve.
There is a really persistant meme that SSL breaks when the DNS breaks, because all that happens when your certificate doesn't match or verify is that you get a warning. That warning says SSL isn't working anymore. You're not supposed to click through it. Real applications that use SSL under the hood don't pop up warnings: they freak out and quit.
"There is a really persistant meme that SSL breaks when the DNS breaks, because all that happens when your certificate doesn't match or verify is that you get a warning. That warning says SSL isn't working anymore. You're not supposed to click through it."
I didn't know it was this bad, Browsers should "freak out" and totally refuse to proceed with the page then.
The problem with this is that SSL certificates can become nonverifiable through innocuous circumstances --- for instance, by expiring, or by moving. Most providers and most users would not accept a hard failure in this case.
And there you have one of the biggest problems with DNSSEC --- without a massive software revamp, there's no "soft" failure mode. gethostbyname() doesn't have a warning channel.
OK, you agree SSL does protect savvy users from MITM attacks.
You're talking about users who can be tricked into what are essentially non-SSL or degraded SSL (certificates from untrustworthy authorities) sessions, because they misread the URL bar or ignore warnings. That's a legitimate concern, most users are easily tricked, but that's not a vulnerability of SSL itself.
My assertion is that you can't just use SSL and leave it at that. In that case, you're only going to protect savvy users, and not even all of those.
That may or may not be true, but what is certain is that additional mucking around with salts, Javascript crypto, and protocols isn't going to improve the story you get with HTTPS.