Hacker News Reader

Comment by ZoFreX | Hacker News Reader

The nice thing about bcrypt is that it stores the work factor and salt and hash all in one value, so you can very easily migrate to harder work factors. I have seen similar schemes used to store hashes from a variety of algorithms, you can simply have something like bcrypt$workfactor$salt$hash stored in the password field.

View on HN

Yes, storing the algorithm used in the same column would be fine as well. But if you drop the "bcrypt$" from your example, you would still run into issues if bcrypt itself is broken.

Isn't that simply giving the attacker all the info they need to start cracking these passwords with a dictionary attack?

Sure - but the idea of salting is to make the dictionary too time consuming to create. The security is NOT in how secret your methods are (it rarely is).

Additionally, each salt is still unique per password, so the attacker would need to generate a full dictionary per record that they want to crack - generally not worth it.

I was thinking more along the lines of just running the top 100 passwords through each user

Salting is no replacement for strong passwords, this would work against most any salting scheme.

Not if part of the information is kept in code only, like iteration count on bcrypt

There is a chance that if your DB is compromised, your code is as well. Additionally, what if you want to change your work factor, how would you handle doing that? If you upgrade your server environment and then all of a sudden realize that your hashing algorithm only take .1 seconds, when it used to take .5 you might want to change it.

While that may slow down an attacker in some circumstances, a sufficiently secure password scheme will still be secure with total knowledge of the system available to the attacker. See also: security through obscurity.

Reply on news.ycombinator.com