CODEWITHSUNDEEP
phpmysqlsecurityhash
luca.p.alexandru
luca.p.alexandru

Reputation: 1750

Salted password security

Let's say I have a table where I store a hashed password and also the salt with which the password was salted with (for each individual user).

Based on another stackoverflow question, I understood that it is ok that the salt would be saved on the same table with the hashed password.

How insecure is a salted SHA1 compared to a salted SHA512

My question is, If the database with the hashed passwords would get hacked and that the user would have a rainbow table for those hashes and considering the salts are stored in the same table with the hashed passwords, wouldn't it be quite simple to see the actual password? You would just have to eliminate the salt from the password from that specific rainbow table.

Considering this, I do not understand why it is ok to store the salt in the same database, table with the hashed password. Can someone please give a more clearer explanation?

Upvotes: 0

Views: 114

Answers (1)

tadman
tadman

Reputation: 211540

Okay, stop right there. If you're even asking about salting you're already on the wrong path. This is something that's very easy to get wrong and there's so many horribly bad examples of how to do this out there that it's easy to get overly confident about the completely wrong thing.

The simplest correct way to do this is to use the password_hash function and not invent your own quirky way of doing it. This is actually a lot easier and way more secure than what you're considering here.

The password_hash function uses Bcrypt internally by default and it's a hash that's designed to be extremely difficult to brute force and cannot be used with rainbow tables. It's also adjustable so you can make it arbitrarily even more difficult if you want.

You need this adjustability factor to protect your database for longer periods of time. What's very hard to crack today might be trivial in ten years, we just don't know. You can make it harder now to be sure that if your database does leak out somehow you're still protected for some time.

Storing the hash and salt in the same table is often a necessity and splitting them up is usually futile, it's scarcely more effort for an attacker to grab two different tables. They'll likely grab everything from a backup you've lost control of anyway.

Modern cracking systems don't even bother with rainbow tables. The state of the art in GPU cracking is so insanely fast that it makes it pointless, common passwords can be cracked in seconds, less common ones in minutes, and the more obscure ones in hours or days if that's even a priority. Bitcoin's use of SHA256 has driven a lot of research in this department rendering those algorithms mostly useless for this sort of security. There are devices on the market that can perform multiple trillions of hashes per second.

That's actually faster than you can read your rainbow table from the hard disk. Rainbow tables are basically history.

The threat today is gigantic dictionaries of known-good passwords and a way to mutate that into an even more astronomical number of variants. These keep the GPUs busy and can uncover many of the less common, deliberately trickier passwords that people use.

Upvotes: 7

Related Questions