3 ms·

But the client could also see the SALT which makes it possible to use Rainbow Tables to decrypt the hashes. The SALT should be a secret to the client. Furthermo

But the client could also see the SALT which makes it possible to use Rainbow Tables to decrypt the hashes. The SALT should be a secret to the client. Furthermore, as an attacker, I could just steal the DB hashes and send those from the client and viola I just bypassed your authentication without decrypting anything. If the server does the hashing, then it will recompute the hash of the hash which wont match.

tatersolid 8y ago
Salts are designed to be public knowledge. They’re just supposed to be unique per hashed password to prevent rainbow table attacks against all passwords in the DB. No two users should ever have the same salt, but they’re not a secret. As evidence I cite many of the Password Hashing Competition entries which offer “Server relief” as a feature by giving the salt to any unauthenticated client who asks so most of the hashing can be done on the client followed by a single hash iteration on the server. A “secret per-server salt” is called “pepper” in the security community and is commonly buried in a binary or config file. Pepper has limited security value. An attacker that can get your password DB usually is able to pivot and snag config files and binaries as well.
- blackflame7000 8y ago
  To Start, you bring up an excellent point regarding the Pepper issue of a poorly secured salt(aka Cryptographic Key). Also, you are correct that an attacker that can get your password DB is usually able to successfully pivot. So here's what I propose: Don't store the key anywhere. Instead, have it be computed from something(s) known and done in a very random and complex manner such that there would be no possible way to decompile release mode code in active execution without triggering a segfault and revealing yourself. See the way you beat a rainbow table is you make the ultimate password large enough to exhaust the practical rainbow table limit since it grows exponentially. So if you do a SHA-256 hash of the password on the client size then you have effectively transformed it into a 64 character password, far larger than any rainbow table could hold. Now it is still susceptible to the direct hash storage in the DB. So I suppose the most secure way is to do it both on the server and on the client. Good Post TaterSolid!

tatersolid 8y ago

Salts are designed to be public knowledge. They’re just supposed to be unique per hashed password to prevent rainbow table attacks against all passwords in the DB. No two users should ever have the same salt, but they’re not a secret. As evidence I cite many of the Password Hashing Competition entries which offer “Server relief” as a feature by giving the salt to any unauthenticated client who asks so most of the hashing can be done on the client followed by a single hash iteration on the server. A “secret per-server salt” is called “pepper” in the security community and is commonly buried in a binary or config file. Pepper has limited security value. An attacker that can get your password DB usually is able to pivot and snag config files and binaries as well.

blackflame7000 8y ago
To Start, you bring up an excellent point regarding the Pepper issue of a poorly secured salt(aka Cryptographic Key). Also, you are correct that an attacker that can get your password DB is usually able to successfully pivot. So here's what I propose: Don't store the key anywhere. Instead, have it be computed from something(s) known and done in a very random and complex manner such that there would be no possible way to decompile release mode code in active execution without triggering a segfault and revealing yourself. See the way you beat a rainbow table is you make the ultimate password large enough to exhaust the practical rainbow table limit since it grows exponentially. So if you do a SHA-256 hash of the password on the client size then you have effectively transformed it into a 64 character password, far larger than any rainbow table could hold. Now it is still susceptible to the direct hash storage in the DB. So I suppose the most secure way is to do it both on the server and on the client. Good Post TaterSolid!