Using a random salt in password encryption?

Question

Hey,

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)?

Any insight is greatly appreciated,
Jengerer

Answer 1

I use a fixed salt (for all passwords) which is hardcoded on the application code. Assuming that the salt cannot be exposed (e.g via the UI of the application) this looks simple and good enough.

Answer 2

Security introduced by salt is that you obtain hash for something much bigger and non-standard than the plain password. It doesn't matter if its algorithm is closed, because it protects the hash stored in plain in database from rainbow or dictionary attacks.

It's also reccomended to take hash several times recursively, maybe readding the salt at each iterations, so that brute force will take much longer.

EDIT: to what Bevan said about communication: usually the "number used once" (NONCE) scheme is used to transmit passwords over unsecure channels. The server gives a random string never used before to the client, he appends it to the plain password, computes hash, and sends it. This protects you from eavesdropping attacks.

Answer 3

Hashing passwords protects against plainly visible passwords, and salting them guards against dictionary attacks. As far as protecting passwords during transport, I would recommend SSL/TLS.

Answer 4

The only way to not send an unencrypted value which can be used to log in is to use SSL. If the hash gets sent to the server, the hash itself can be sniffed and used to log in. Do it server side.

+1 to what ruslik said about the salt. It prevents dictionary/rainbow attacks. A rainbow table for an average password + several bytes of random binary data would be astronomically huge.

Answer 5

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.