Question

I’ve seen a few other threads about this topic, but I can’t seem to find a few answers to some questions involving the use of a random salt in password encryption. To my understanding, the steps go something like this:

1. Generate a random salt for the user.
2. Append the salt to their password.
3. Use something like SHA-2 to hash the result.
4. Store both the salt and hashed password in the database.

How does this method work when retrieving the user’s password and verifying log-in? One response says that the user’s salt should be retrieved, appended to their inputted password, hashed, and then compared to the stored hash, but doesn’t this raise some issues? Namely:

• How do you retrieve the salt without compromising that user? If someone wanted to brute-force a certain account’s password, wouldn’t they be able to retrieve the salt that was sent back from the server to hash the inputted password, thereby eliminating the security that having a salt adds?
• If we avoid the previous problem by doing the salt retrieval server-side, then won’t we be sending the user’s inputted password unencrypted at one point or another (so that it may later be appended to the retrieved salt)?

Answer 1

The salt should never be exposed outside of the service – your instinct is right that this would be exposing the salt and introducing risk.

Any communication between your client and server should occur over an SSL connection – or at least using some kind of encryption of the interaction.

Keep in mind the purpose of the salt: to make it harder for someone to precalculate hash codes and therefore be able to look up passwords in the case of the database being compromised. An 8 bit salt makes the hash space 256 times bigger, making precalculation that much harder. The salt isn’t about securing communication – there are other solutions for that.