2 added 150 characters in body
source | link

For starters, password hashing should be done with a dedicated password hashing function such as bcrypt, Argon2, scrypt or PBKDF2. In that case, you don't have to deal with concatenating the salt and password like a primitive; the function takes those as separate arguments. See "How to securely hash passwords?", one of the top Q&A's on this site for this topic.

The purpose of the salt in password hashing is to randomize the hash function that's applied to each password entry. So three rules that generally apply to modern specialized password hashes are these:

  1. Everytime you enroll a new password you should generate a fresh salt. (Note this means that when a user changes their password, you should generate a fresh salt for that password, not reuse the salt for the old one. Salts are bound to states of a password database entry, not to users.)
  2. The salt's value should be independent of the password itselfitself; knowledge of the password should be of no help in guessing the salt, or otherwise an attacker could use such knowledge to precompute an attack table. An obvious example here is you shouldn't use the password itself as the salt. (That's less dumb than it might sound—you wouldn't store the salt along the password in this case—but it is dumb, because two users with the same password would have the same hash.)
  3. The chance that two salts are equal to each other should be very low. Preferably not just within your application, but globally across the whole world.

Now we can answer your question by making these observations:

  • A salt that's made up of a sufficient number of random bytes satisfies these criteria already. 16 random bytes (from a cryptographically strong random number generator) sounds sensible.
  • Concatenating the username to such a random salt doesn't help.
  • If the salts are being generated in some way that's predictable but somewhat nonrepeating—for example, as a counter that's incremented each time you enroll a new password, or as a timestamp—concatenating additional values like the username or your site's domain name can help make it more unique. But using random salts would be simpler (no need to keep track of a persistent counter state).

For starters, password hashing should be done with a dedicated password hashing function such as bcrypt, Argon2, scrypt or PBKDF2. In that case, you don't have to deal with concatenating the salt and password like a primitive; the function takes those as separate arguments. See "How to securely hash passwords?", one of the top Q&A's on this site for this topic.

The purpose of the salt in password hashing is to randomize the hash function that's applied to each password entry. So three rules that generally apply to modern specialized password hashes are these:

  1. Everytime you enroll a new password you should generate a fresh salt. (Note this means that when a user changes their password, you should generate a fresh salt for that password, not reuse the salt for the old one. Salts are bound to states of a password database entry, not to users.)
  2. The salt's value should be independent of the password itself. An obvious example here is you shouldn't use the password itself as the salt. (That's less dumb than it might sound—you wouldn't store the salt along the password in this case—but it is dumb, because two users with the same password would have the same hash.)
  3. The chance that two salts are equal to each other should be very low. Preferably not just within your application, but globally across the whole world.

Now we can answer your question by making these observations:

  • A salt that's made up of a sufficient number of random bytes satisfies these criteria already. 16 random bytes (from a cryptographically strong random number generator) sounds sensible.
  • Concatenating the username to such a random salt doesn't help.
  • If the salts are being generated in some way that's predictable but somewhat nonrepeating—for example, as a counter that's incremented each time you enroll a new password, or as a timestamp—concatenating additional values like the username or your site's domain name can help make it more unique. But using random salts would be simpler (no need to keep track of a persistent counter state).

For starters, password hashing should be done with a dedicated password hashing function such as bcrypt, Argon2, scrypt or PBKDF2. In that case, you don't have to deal with concatenating the salt and password like a primitive; the function takes those as separate arguments. See "How to securely hash passwords?", one of the top Q&A's on this site for this topic.

The purpose of the salt in password hashing is to randomize the hash function that's applied to each password entry. So three rules that generally apply to modern specialized password hashes are these:

  1. Everytime you enroll a new password you should generate a fresh salt. (Note this means that when a user changes their password, you should generate a fresh salt for that password, not reuse the salt for the old one. Salts are bound to states of a password database entry, not to users.)
  2. The salt's value should be independent of the password itself; knowledge of the password should be of no help in guessing the salt, or otherwise an attacker could use such knowledge to precompute an attack table. An obvious example here is you shouldn't use the password itself as the salt. (That's less dumb than it might sound—you wouldn't store the salt along the password in this case—but it is dumb, because two users with the same password would have the same hash.)
  3. The chance that two salts are equal to each other should be very low. Preferably not just within your application, but globally across the whole world.

Now we can answer your question by making these observations:

  • A salt that's made up of a sufficient number of random bytes satisfies these criteria already. 16 random bytes (from a cryptographically strong random number generator) sounds sensible.
  • Concatenating the username to such a random salt doesn't help.
  • If the salts are being generated in some way that's predictable but somewhat nonrepeating—for example, as a counter that's incremented each time you enroll a new password, or as a timestamp—concatenating additional values like the username or your site's domain name can help make it more unique. But using random salts would be simpler (no need to keep track of a persistent counter state).
1
source | link

For starters, password hashing should be done with a dedicated password hashing function such as bcrypt, Argon2, scrypt or PBKDF2. In that case, you don't have to deal with concatenating the salt and password like a primitive; the function takes those as separate arguments. See "How to securely hash passwords?", one of the top Q&A's on this site for this topic.

The purpose of the salt in password hashing is to randomize the hash function that's applied to each password entry. So three rules that generally apply to modern specialized password hashes are these:

  1. Everytime you enroll a new password you should generate a fresh salt. (Note this means that when a user changes their password, you should generate a fresh salt for that password, not reuse the salt for the old one. Salts are bound to states of a password database entry, not to users.)
  2. The salt's value should be independent of the password itself. An obvious example here is you shouldn't use the password itself as the salt. (That's less dumb than it might sound—you wouldn't store the salt along the password in this case—but it is dumb, because two users with the same password would have the same hash.)
  3. The chance that two salts are equal to each other should be very low. Preferably not just within your application, but globally across the whole world.

Now we can answer your question by making these observations:

  • A salt that's made up of a sufficient number of random bytes satisfies these criteria already. 16 random bytes (from a cryptographically strong random number generator) sounds sensible.
  • Concatenating the username to such a random salt doesn't help.
  • If the salts are being generated in some way that's predictable but somewhat nonrepeating—for example, as a counter that's incremented each time you enroll a new password, or as a timestamp—concatenating additional values like the username or your site's domain name can help make it more unique. But using random salts would be simpler (no need to keep track of a persistent counter state).