Return to Answer

The classical recommendation for a salt for password hashing is:

• A random value of 128 bits or more;
• obtained from a cryptographically sound random number generator (/dev/random or /dev/urandom on modern day Unixes);
• unique for each entry (i.e. don't re-use the same salt, generate a new salt for each new password);
• stored in plaintext in the database (so that the salt is available when verifying the hash).

There are plenty of past discussions of related topics. And most importantly, you should not implement your own password hashing scheme -- you should use a proven, well tested, peer reviewed implementation (bcrypt/PBKDF2).

The classical recommendation for a salt for password hashing is:

• A random value of 128 bits or more;
• obtained from a cryptographically sound random number generator (/dev/random or /dev/urandom on modern day Unixes);
• unique for each entry (i.e. don't re-use the same salt, generate a new salt for each new password);
• stored in plaintext in the database (so that the salt is available when verifying the hash).

There are plenty of past discussions of related topics. And most importantly, you should not implement your own password hashing scheme -- you should use a proven, well tested, peer reviewed implementation (bcrypt/PBKDF2).

The classical recommendation for a salt for password hashing is:

• A random value of 128 bits or more;
• obtained from a cryptographically sound random number generator (/dev/random or /dev/urandom on modern day Unixes);
• unique for each entry (i.e. a new salt for each password hash);
• stored in plaintext in the database (so that the salt is available when verifying the hash).

There are plenty of past discussions of related topics. And most importantly, you should not implement your own password hashing scheme -- you should use a proven, well tested, peer reviewed implementation (bcrypt/PBKDF2).

The classical recommendation for a salt for password hashing is:

• A random value of 128 bits or more;
• obtained from a cryptographically sound random number generator (/dev/random or /dev/urandom on modern day Unixes);
• unique for each entry (i.e. don't re-use the same salt, generate a new salt for each new password);
• stored in plaintext in the database (so that the salt is available when verifying the hash).

There are plenty of past discussions of related topics. And most importantly, you should not implement your own password hashing scheme -- you should use a proven, well tested, peer reviewed implementation (bcrypt/PBKDF2).

The classical recommendation for a salt for password hashing is:

• A random value of 128 bits or more;
• obtained from a cryptographically sound random number generator (/dev/random or /dev/urandom on modern day Unixes);
• unique for each entry (i.e. a new salt for each password hash);
• stored in plaintext in the database (so that the salt is available when verifying the hash).

There are plenty of past discussions of related topics. And most importantly, you should not implement your own password hashing scheme -- you should use a proven, well tested, peer reviewed implementation.

The classical recommendation for a salt for password hashing is:

• A random value of 128 bits or more;
• obtained from a cryptographically sound random number generator (/dev/random or /dev/urandom on modern day Unixes);
• unique for each entry (i.e. a new salt for each password hash);
• stored in plaintext in the database (so that the salt is available when verifying the hash).

There are plenty of past discussions of related topics. And most importantly, you should not implement your own password hashing scheme -- you should use a proven, well tested, peer reviewed implementation (bcrypt/PBKDF2).