I'm currently going through a course on software security. I've recently been introduced to the idea of password salting, where a random value is concatenated to a password prior to being hashed and stored. I believe I understand the operation correctly, but I don't understand how this makes the process itself any more secure.

Obviously, for authentication to occur, there has to be a reference to the salt used for the specific password during creation, thus creating a matching hash. In this reference there is a direct link to both the salt and the password/hash. If a perpetrator has access to the database, thus compromising both the hashes and salts, would he not have access to the algorithm or references to the salt as well?

Based on my understanding of salting, this method seems to be security by obscurity.

2 Answers
2

This topic is documented extensively all over the web as well as on this site, so taking the time to do some research on your own would have been a much faster way to get answers. However, if you're just having trouble understanding the concept a simple explanation may help.

Simply put, it alters the hash of a password so that it does not physically match the hash of another password.

For example, a user has the password, "password123" and is put through a SHA1 hash. In the password database, all of the users with the password "password123" will have the exact same hash, because of the nature of hashing functions.

So, if an attacker was to breach the database and brute force the password of the user mentioned above, he could look for all the hashes that match the original user's and would know their passwords are also "password123".

By implementing a salt, the password hashes would no longer be identical to one another, even though the actual password is still the same. This requires the attacker to go in and attempt to brute force the second password (which has a different salt), even though it may be the same as the first. In a nutshell, it prevents an attacker from uncovering one password and subsequently uncovering multiple others.

In your question, you are correct that the salt is typically right next to the hash, such that anyone that has gained access to a database of password hashes would also have access to the salts. However, that doesn't detract from the original purpose in that it is preventing multiple hashes from being brute forced in a single guess. Each and every hash has to be guessed on its own.

This topic has really been discussed to death, so this is only the short version.

Salts have several benefits. The most important one is that it forces an attacker to break each hash individually.

Without salts, the attacker needs to go through his list of possible passwords just once. For each item, he calculates the hash and checks if it matches any of the stored hashes. So to search a space of n possible passwords, the attacker needs at most n hash calculations.

With salts, you effectively hash every password with a unique variation of the basic hash algorithm. Now an attacker can't just do one calculation and compare the result with all stored hashes. They need to attack each hash individually. So if there are m stored hashes with unique salts, searching a space of n possible passwords requires at most m * n hash calculations. That's m times as much effort as before.

The salts do not have to be secret. They only need to be sufficiently random so that they're indeed unique (not just in your own application but globally). 16 bytes from a source like /dev/urandom are fine.

Note, however, that salts do not magically turn weak hash algorithms into strong ones. They do not protect a particular hash. They also don't help if the underlying hash algorithm is so fast that an attacker can easily make up for the extra effort.

So concepts like “salted MD5” or “salted SHA” (whatever that means) are nonsensical. If the attacker can calculate hundreds of billions of hashes per second, he simply doesn't care about some additional calculations. Salts are only effective in the context of a strong hash algorithm like bcrypt.