Hacker News Reader

Comment by swalkergibson | Hacker News Reader

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

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.

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).

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."

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.

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.

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".

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

To quote, emphasis his: Using raw hash functions to authenticate passwords is as naive as using unsalted hash functions. Don’t.

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."

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.

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-secur...

Then go back, read the rest of it :)

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."

Reply on news.ycombinator.com