Hacker News Reader

Comment by timclark | Hacker News Reader

The faster you hash, the faster I can run a brute force attack on your password form.

No, this is technically wrong. There are better ways of stopping a brute-force attack on a password form, such as attack detection, and black-lists. If you rely on a computational delay to slow attackers down on your servers, you will merely open yourself to a simpler DDOS attack. The purpose of a computationally expensive hashing algorithm is that it prevents brute-force attacks against a stolen copy of your password database, where the attacker no longer has to deal with your other defenses.

Quick question, if you have the db but not the salt, does the speed of the hashing algorithm still matter?

The salt is usually in the db as you should have a different salt per password. The purpose of the salt is to add some complexity so that each password is in fact hashed by a slightly different algorithm (in order to defeat pre-computation based attacks.) If the attacker does not know that salt, then he does not know the full hash algorithm and cannot brute-force the password. So technically no, I don't think so. However, if the attacker can get your password db he can also get your salt db so I wouldn't rely on this by any means.

Disclaimer: I'm absolutely not a security professional.

It wouldn't, but it's a Bad Plan not to have per-user salt, so the circumstances where you'd have the passwords but not the salts that go with them would be... odd.

Thanks to you and astine, I just learned today about per-user salts. I thought that you only needed a site-wide salt and after reading on the topic, I now understand why it's better to have a per-user salt stored in the db.

I was also confused by these frameworks (e.g., Django) that ask you for a secret key and I thought that the secret key was a site-wide salt. Fortunately, they knew better than me ;-)

Reply on news.ycombinator.com