How to use password salt the right way

Question

I understand the basic idea of password salts.

1. You generate a 'random' string of data
2. prepend this data to a user password
3. store password and salt (salt maybe even in 'clear' form)

Like in the following scenario: You have a client side mobile application and a server application with a database. The user registers with a username and password using the mobile app. The password gets a prepended salt and is stored hashed on the server side. The salt has to be stored on the server side too, because you wouldn't trust the mobile client at all. And the salt should somehow be connected to the right user account. So let's assume, it is stored in the same user table right beside the password.

How could using a salt in this case prevent any attack (e.g. dictionary attack)? If the attacker already has access to the database server it would be easy to get the salt. If the attacker uses the interface of the server application in a proper way the salt would also be applied to his 'attack attempts for login'. Maybe I'm missing some important point how this kind of attack is usally carried-out. Or would this system only be secure if salting and hashing would be executed directly on the client?

Answer 1

Salting by itself does not prevent a dictionary attack against the password itself. But it makes rainbow-table or common password attacks against the hash much harder. If you use a PBKDF instead of a simple hash o HMac, a dictionary attack against the password may become infeasible, too.

P.S.: The salt is nothing to be kept secret. Its only purpose is to randomize the hash and make it unique to another factor other than the user-chosen password.

Answer 2

How could using a salt in this case prevent any attack (e.g. dictionary attack)?

The purpose of a salt is to increase the computational work the attacker must perform by ensuring the same password is hashed differently for different users.

Let's say you have 1,000 users. And let's say the attacker uses a dictionary of 100,000 words to try as passwords. If there are no salts, he must hash the 100,000 words and compare them to the stored hashes of your 1,000 users - the computational work is 100,000 hash operations.

On the other hand, if those users are salted, then he must hash 100,000 words multiplied by 1,000 salt values for a total of 100,000,000 hash operations.

Consider that user_a and user_b both use 'hello123' as their password. If no salt is used, they would both have the same hash:

f30aa7a662c728b7407c54ae6bfd27d1

Now let's consider where each user has a salt ("1" in the case of user_a, and "2" in the case of user_b). The salt+password will hash to two separate values:

1e081602cd8b58d2fbb83b9d5c3511ee
e91627dc5b332b288e98cb82194cae06

and now if the attacker gets lucky and guesses one, he won't have guessed both of them.

Answer 3

Salt doesn't prevent dictionary attacks. Salt slows down dictionary attacks.

Imagine that I have a database with a bunch of users and passwords:

• user1:2ac9cb7dc02b3c0083eb70898e549b63
• user2:60bd8ed7a768e8bd6925beb0a691aadb
• user3:2ac9cb7dc02b3c0083eb70898e549b63
• user4:8e601d1cd9d9ea079d8f15a0414e5d2b
• user5:306578f0e3e22fc26e9295069d9961b1

You don't know what the passwords are, but you can see, given a bit of looking, that user1 and user3 have the same password, even though it is hashed. Therefore, you can look for common hashes, and try to break those, knowing that you'll get a handful of users.

If I have the same database, with the same passwords, but with unique salts for each (in this case, I've appended the username):

• user1:08df37a942cb96598d8b459861bbcb45
• user2:ed763cc6753bde74ad1ea491e31882dc
• user3:95f6430be7989dc73dac21407817c048
• user4:a01805e1f7d1f88e9b0d8eab8f1aebb6
• user5:b913e9c11863bf6f9c49777a45dcc3ce

Now, you can't tell if any of the users are using the same password as one another. Your only choice to try and break passwords is to try cracking each one in turn.

If I know my data has been taken, I will tell my users to change their passwords. In the first case, though, you will almost certainly get some hits quite quickly for weak passwords, and they'll give you access to multiple accounts.

In the second case, you still get the weak password hits, but you only get one account for each. That gives me a bit of a buffer to tell my customers, and hopefully fewer of them will get affected.

And that's before you consider that for some common passwords, experience will give attackers knowledge of the contents based on common hashes - user1 in this case is using Password1, and I'm sure that some of the visitors to this page will have noticed that almost instantly (it's just an MD5 hash).

Salt also restricts the use of rainbow tables, although these appear to be less popular nowadays. This might be down to increased use of random salt.