3 ms·

But aren't the password and the salt hashed together? So a password with different salts will result in a different hashes. Therefore you have to know the salt

But aren't the password and the salt hashed together? So a password with different salts will result in a different hashes. Therefore you have to know the salt in order to guess the password (for offline matching against a dataset of hashed passwords retrieved from a target site). Ideally, every password will have a different salt, and the dataset of salts is stored separately from the dataset of hashes. Or am I missing something? (Genuine question, because this is not my area of expertise).

agwa 13y ago
Chances are extremely high that if an attacker gets the hashes, they also get the salts. Since knowing the salt is necessary to authenticate against the hashed password, any application that has access to the hash also has access to the salt, making the salt just as likely to be compromised as the hash. A hash with an unknown salt is just as useless to a legitimate application as it is to an attacker, so there's really no point in trying to store salts "separately."
kcorbitt 13y ago
If someone has penetrated your security enough to get the list of hashed user passwords it's assumed that they've got the salt as well. Salts aren't really considered "secret" and they don't make it harder for an attacker to crack a specific password, they just make it harder for the cracker to reuse his work against all the passwords in existence.
stonemetal 13y ago
Salts are usually not stored separately. The password checker needs to access both the password hash and the password salt. This means that there is one set of privileges(whatever the password checker has) necessary to get both the hash DB and the salt DB. Therefore any attacker that has the password hash DB also has the Salt DB. Ideally, every password will have a different salt, More than ideally, the only way it makes any sense at all is if they are different. As an example: User: bob password: password1 password hash: 12345 User: sue password: password1 password hash: 12345 with salt that is the same for all users: User: bob password: password1 salt: 7 password hash: 22345 User: sue password: password1 salt: 7 password hash: 22345 with salt that is different per user User: bob password: password1 salt: 7 password hash: 22345 User: sue password: password1 salt: 8 password hash: 32345 Per user salt means that an attacker who has stolen the password db can't crack one password and unlock 100 accounts because they all have the same password hash. That is the only point of a salt it serves no other purpose.
- Steuard 13y ago
  Per user salt means that an attacker who has stolen the password db can't crack one password and unlock 100 accounts because they all have the same password hash. That is the only point of a salt it serves no other purpose. I wouldn't say no other purpose. A single common salt can at least protect you from the guy who has a pre-computed lookup table of dictionary words hashed with a standard, unsalted function. (That is, it prevents a zero-computation attack.) Admittedly that doesn't gain you much these days, but it's not "zero benefit".

agwa 13y ago

Chances are extremely high that if an attacker gets the hashes, they also get the salts. Since knowing the salt is necessary to authenticate against the hashed password, any application that has access to the hash also has access to the salt, making the salt just as likely to be compromised as the hash. A hash with an unknown salt is just as useless to a legitimate application as it is to an attacker, so there's really no point in trying to store salts "separately."

kcorbitt 13y ago

If someone has penetrated your security enough to get the list of hashed user passwords it's assumed that they've got the salt as well. Salts aren't really considered "secret" and they don't make it harder for an attacker to crack a specific password, they just make it harder for the cracker to reuse his work against all the passwords in existence.

stonemetal 13y ago

Salts are usually not stored separately. The password checker needs to access both the password hash and the password salt. This means that there is one set of privileges(whatever the password checker has) necessary to get both the hash DB and the salt DB. Therefore any attacker that has the password hash DB also has the Salt DB. Ideally, every password will have a different salt, More than ideally, the only way it makes any sense at all is if they are different. As an example: User: bob password: password1 password hash: 12345 User: sue password: password1 password hash: 12345 with salt that is the same for all users: User: bob password: password1 salt: 7 password hash: 22345 User: sue password: password1 salt: 7 password hash: 22345 with salt that is different per user User: bob password: password1 salt: 7 password hash: 22345 User: sue password: password1 salt: 8 password hash: 32345 Per user salt means that an attacker who has stolen the password db can't crack one password and unlock 100 accounts because they all have the same password hash. That is the only point of a salt it serves no other purpose.

Steuard 13y ago
Per user salt means that an attacker who has stolen the password db can't crack one password and unlock 100 accounts because they all have the same password hash. That is the only point of a salt it serves no other purpose. I wouldn't say no other purpose. A single common salt can at least protect you from the guy who has a pre-computed lookup table of dictionary words hashed with a standard, unsalted function. (That is, it prevents a zero-computation attack.) Admittedly that doesn't gain you much these days, but it's not "zero benefit".