Why is saving the salt for a hashed password in the same database secure?

Question

I understand the need for hashing and salting, but I do not understand how storing the salt in the same (potentially compromised) database as the entire hash is secure. For example, a book I'm studying instructs to create a unique hash for each user (good) by randomly generating an integer and creating a byte[] using the RNGCryptoServiceProvider. That is all well and good, but in order to validate a user's password upon login, it will be necessary to read that unique salt from the database (or some other file). Is this a secure way of storing a salt?

Joel Coehoorn · Answer 1 · 2019-03-07T14:24:55.007

Imagine you're a bad guy, and you get access to a password database. There's a lot of information there, things are already bad enough. The only good news for the rest of us is this is dead data in the end. What you really want is access to the living, running system, and the ability to make that system do whatever you want... especially if no one knows you're in.

Here's the trick. To get the access, you don't need to actually discover real passwords: you only need to find some text value that results in the same hash. Worse, you don't need to brute-force a result. There are helpful tables out there that allow you to quickly find texts that will produce the hash you need.

The purpose of the salt, then, is to add a wrinkle against these pre-computed tables. You might have a value that can produce a specific hash, but your pre-computed "rainbow tables" don't account for the salt. A salt completely changes the hash. Now you're back to needing to brute-force individual passwords, and if the system designer used a good encryption algorithm that could take years.

The nice thing here is the salt has this impact even when you know it's value. Just having a per-user salt, even if the salts are public, breaks an attackers ability to use rainbow table attacks on your password database.

(A shared salt, though, would allow an attacker to start running a cracking solution using common passwords, etc and start throwing things against a wall... comparing hash results against all users and see what comes up).

score 4 · Accepted Answer · edited Apr 01 '13 at 01:49

4

This is secure because having access to the salt does not make the process of hashing any easier to reverse for an attacker. Given the password, the salt, and the hash, you can quickly check if the triple is right. However, you cannot use the knowledge of the salt to help you get the password.

Recall that the reason the salt is needed in the first place is to avoid equal passwords produce equal hashes. Without the salt, attackers would be able to hash the "rainbow table", and check hashes against the encoded dictionary.

edited Apr 01 '13 at 01:49

Peter Elliott

3,273
16
30

answered Apr 01 '13 at 00:26

Sergey Kalinichenko

714,442
84
1,110
1,523

The process of *hashing* is not easily reversible. That has nothing to do with salting. – nneonneo Apr 01 '13 at 00:28
maybe I don't fully understand how that kind of attack works but if the DB falls into an attacker hands he will have the salt and the hashed salted password, wouldn't he be able to obtain the password with that? – jigzat Apr 13 '13 at 05:11

score 3 · Answer 3 · answered Apr 01 '13 at 00:26

Salting increases the difficulty of performing offline attacks against a compromised database. While an attacker with sufficient resources will eventually crack all your passwords, salting makes it harder in two ways:

Precomputed lists of hashes based on common passwords (known as rainbow tables) cannot be applied to salted passwords (at least not without taking into account all salts)
Cracking one salted password gives no information about any other passwords (e.g. whether two passwords are identical).

The increase in difficulty allows for more time to discover and mitigate the effects of a compromised database.

You may obtain slightly better security by separating the hashes and the salts, because an attacker without the salts would have to bruteforce the salts. However, in practice, it is difficult and cumbersome to achieve this separation, and the attacker is very likely to be able to obtain the salts along with the passwords if he has that level of access.

score 1 · Answer 4 · answered Apr 01 '13 at 00:26

1

Salting prevents cracking the hash by looking it up in a pre-made table. If an attacker knows the salt it won't help them in this attack vector as they will still need to brute-force the password.

answered Apr 01 '13 at 00:26

wRAR

25,009
4
84
97

Thanks. I understand salting. Is your answer that storing the salt in the same database is secure then? – field_b Apr 01 '13 at 00:27
@field_b I think I answered why it is secure. – wRAR Apr 01 '13 at 00:28

score 0 · Answer 5 · answered Apr 01 '13 at 00:27

Having a different salt per user means that they would have to expend all their resources to brute-force a matching hash just for a single user. So it's not necessarily "secure", but rather it's significantly difficult (impossible?) to crack an entire database, when it would take a ridiculous amount of effort to crack even one.

You can combine a per-record salt with a global salt so that even if your database is compromised, they'd still be one element short of a workable brute-force.

I'd say go with both - can't hurt after all...

Why is saving the salt for a hashed password in the same database secure?

5 Answers5