5 ms·

This type of dictionary attack is largely mitigated by salting your hashes, is it not?

richardwhiuk 13y ago
Salting defeats rainbow tables, not word lists. This sort of attack is largely defeated by basic password complexity and using plenty of rounds of hashing in order to increase the work effort to hash a given size of word list.
- mistermumble 13y ago
  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".
benhirashima 13y ago
from wikipedia: "A public salt makes it more time-consuming to crack a list of passwords. However, it does not make dictionary attacks harder when cracking a single password. The attacker has access to both the encrypted password and the salt, so when running the dictionary attack, the attacker can simply use the known salt when attempting to crack the password."
- benhirashima 13y ago
  one strategy that has occurred to me is to use a secret "master" salt, in addition to random public salts for each password. that way, an attacker would have to obtain the secret salt, as well as the public salts. the secret salt would be stored in the program that does the hashing, and not in the database. this requires an attacker to gain access to the filesystem where the program lives, as well as the database. of course, this offers no guarantees, but does make it harder for the attacker.
  - shabble 13y ago
    I think this occurs to nearly everyone. It's commonly referred to as a "pepper"[1], and is generally considered not all that helpful in most scenarios, as well as being potential evidence that you're a witch^W^WDoing Your Own Crypto, which is bad. [1] See towards the end of the very comprehensive first answer. http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords/31846#31846 http://security.stackexchange.com/questions/211/how-to-secur... Then go back, read the rest of it :)
    - benhirashima 13y ago
      thanks for the link. it was a good read. however, i see nothing in there that suggests that using a pepper is necessarily a bad thing. i think the answer from rory mcclune puts it well: "Another add-on I've seen to this is to also add in what was called a pepper value. This was just another random string but was the same for all users and stored with the application code as opposed to in the database. the theory here is that in some circumstances the database may be compromised but the application code is not, and in those cases this could improve the security. It does, however, introduce problems if there are multiple applications using the same password database."
owenmarshall 13y ago
Since our own tptacek hasn't shown up, I'm going to link to (the only copy I can find of) one of his great blog posts on this subject: http://www.securityfocus.com/blogs/262 http://www.securityfocus.com/blogs/262 To quote, emphasis his: Using raw hash functions to authenticate passwords is as naive as using unsalted hash functions. Don’t.

Salting defeats rainbow tables, not word lists. This sort of attack is largely defeated by basic password complexity and using plenty of rounds of hashing in order to increase the work effort to hash a given size of word list.

mistermumble 13y ago
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".

benhirashima 13y ago

from wikipedia: "A public salt makes it more time-consuming to crack a list of passwords. However, it does not make dictionary attacks harder when cracking a single password. The attacker has access to both the encrypted password and the salt, so when running the dictionary attack, the attacker can simply use the known salt when attempting to crack the password."

benhirashima 13y ago
one strategy that has occurred to me is to use a secret "master" salt, in addition to random public salts for each password. that way, an attacker would have to obtain the secret salt, as well as the public salts. the secret salt would be stored in the program that does the hashing, and not in the database. this requires an attacker to gain access to the filesystem where the program lives, as well as the database. of course, this offers no guarantees, but does make it harder for the attacker.
- shabble 13y ago
  I think this occurs to nearly everyone. It's commonly referred to as a "pepper"[1], and is generally considered not all that helpful in most scenarios, as well as being potential evidence that you're a witch^W^WDoing Your Own Crypto, which is bad. [1] See towards the end of the very comprehensive first answer. http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords/31846#31846 http://security.stackexchange.com/questions/211/how-to-secur... Then go back, read the rest of it :)
  - benhirashima 13y ago
    thanks for the link. it was a good read. however, i see nothing in there that suggests that using a pepper is necessarily a bad thing. i think the answer from rory mcclune puts it well: "Another add-on I've seen to this is to also add in what was called a pepper value. This was just another random string but was the same for all users and stored with the application code as opposed to in the database. the theory here is that in some circumstances the database may be compromised but the application code is not, and in those cases this could improve the security. It does, however, introduce problems if there are multiple applications using the same password database."

owenmarshall 13y ago

Since our own tptacek hasn't shown up, I'm going to link to (the only copy I can find of) one of his great blog posts on this subject: http://www.securityfocus.com/blogs/262 http://www.securityfocus.com/blogs/262 To quote, emphasis his: Using raw hash functions to authenticate passwords is as naive as using unsalted hash functions. Don’t.