Confused about salting (Cryptography)? [closed]

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 11 years ago.

Improve this question

I'm a newb at this so this question is prob really easy. I just don't quite understand salting.

Without salting and with sha1 you can hash a password to be sha1('password') and to开发者_开发知识库 verify a user you just compare sha1_stored ==? sha1(user_input).

With salting and sha1 you hash the password to be sha1('password' + salt), but i'm not sure how to verify it.

Based on what I've read the salt is always random. So if you sha1('password' + random_salt1), do you have to store the random_salt somewhere because when you verify sha1('password' + random_salt1) ==? sha1(user_input + random_salt2), you can't guarantee that random_salt1 == random_salt2. Or is salt like a site_key(a random salt, but only one is stored for the whole site) ? I get how salt would increase security, but I'm not sure how to implement it correctly such that I can verify what I stored(don't know about this either). So can someone explain this to me and possibly give me an example of salting and verifying a string?

---

Yes, you have to store the random salt somewhere.

No, you shouldn't have it be the same for the whole site, as it completely defeats the purpose of salting.

The purpose of salting is to increase security on an entire list of passwords. If you do not salt, and your database is breached, an attacker gets all your accounts and passwords. If they're not salted, the attacker just sha1's a bunch of words and compares all of them to all of the sha1 passwords. Some of them will match some of the passwords, and wha-la some accounts are compromised.

With salting, the attacker has to operate on each password independently, starting with an entire dictionary of words, salting them, hashing them, and then comparing them each to the salted, hashed, password. You can see that this would be much less efficient, as the attacker must change the salt each time. In this way it is much harder to get passwords from a compromised database.

One common method of storing the salt is to just append or prepend it to the hash and store it in the database. Since the salt and hash are of known length, it's pretty easy to pull them out independently.

---

The salt is randomly chosen and different for each string, but it is not secret. So you store the salt along with the hash: salt + hash. To verify check that hash(salt + password) equals the stored hash.

The main purpose of using a salt is to ensure that two equal passwords don't hash to the same thing, and also to make an attack on the hashed password more difficult. Without salt, you'd just have to break a given hash once and for all to identify all passwords that hash to it. With salt, you'd essentially have to attack each hash anew.

Note that in these modern days of cheap parallel computing hardware (GPUs and cloud), a single salted hash is not all that secure anymore, as it can possibly be discovered by brute force in feasible amounts of time. The current recommendation is therefore to hash a password many times (like 1000 rounds or so) to make the computation expensive. When presented with the correct password, the extra time won't matter, but if you try to brute-force, then an increase by a factor 1000 is a significant deterrent.