4 ms·
Yes, the cost parameter can be tuned without rehashing. This is because the cost is actually stored with the hash, so the == method of the Password object knows
by ehsanul 17y ago
Yes, the cost parameter can be tuned without rehashing. This is because the cost is actually stored with the hash, so the == method of the Password object knows what cost to use to check if a password matches. Don't take my word for it, try it in irb (I just did). From the documentation:
In addition, bcrypt() allows you to increase the amount of work required to hash a password as computers get faster. Old passwords will still work fine, but new passwords can keep up with the times.
Obviously, old passwords would be weaker than new passwords this way. An easy solution to this problem is to check the cost of hashed password in your database when a user tries to log in. If the cost is lower than the cost you want, and the password matches, then replace the hash at higher cost using the password the user just gave you.
As for hashing SSNs, you can easily overcome the problem of a limited range of data by the usual solution: salting. Bcrypt-ruby does salting automatically, which you can observe by rehashing a password in irb multiple times, getting different results (the salt is also stored with the hash, which makes this possible). You can also add additional salt yourself if you really want to.
- oomkiller 17y agoStill, if an attacker were to have access to the salt, I would be in the same situation. I guess I could always increase the cost by a lot, but once they've calculated all of the results, its too simple to get the SSNs.
- ehsanul 17y agoYou're right, salt just protects against rainbow tables, my mistake. Increasing the cost so that a single brute-force attack would take a few years/decades is actually fine. I don't see why it would then be "too simple to get the SSNs", given that you're using a different salt with each. Here's another idea: Use a secret salt, similar to AWS's secret id. Make it long enough that it would pretty much impossible to brute-force (do the calculations). Does that seem like a workable solution? Of course, if the "secret" isn't secure, then well, you're in trouble, and if the secret is in your code in plaintext... Yeah, it's an uphill battle. I'm sure someone more experienced than me here can provide some solution.