What exactly does password hashing and salting protect against?

[eluser]wowdezign[/eluser]
Is this true,

Rick Jolly -
But creating a rainbow table for each known salt is not hard or time consuming. Let’s say you have a dictionary of 1 million common passwords. If you have the salt, you can md5 the entire dictionary with the salt in about 30 seconds using php.

or is this true?

n0xie -
That’s not how salting works. The point is that it is irrelevant what the salt is. The only reason to use salts is to prevent the generated hash from being predictable. So even if they have the salt, generating rainbow tables would still take too long. So saving the salt in the database is not an issue.

Because that has a bearing on the correct answer.

[eluser]Chad Fulton[/eluser]
Rick Jolly is correct, depending upon what you're worried about.

Calculating the md5 hash of 1 million passwords takes negligible time (on my computer it was much less than 30 seconds). So, if an attacker had your database and wanted to just retrieve the passwords of as many people as possible, without caring in particular which they got, it would be pretty simple for them to do (because surely some subset of your users will have passwords from the 1 million common passwords they care about). However, it would be hit and miss, and they couldn't necessarily count on getting a specific user's password back.

If an attacker wanted to get a specific user's password back, they could first try their 1 million common passwords, but after that they'd have to run a more traditional dictionary attack, which would involve checking all permutations of the alphanumeric characters (a-zA-Z0-9). There are 62 characters in that set, so, if they wanted to check all potential permutations of them up to a password length of, say, 10 characters, then there would be 397,665,154,560,843,844 possibilities which, assuming linear time in calculating the md5s, could take years to find the real password.

Please don't get freaked out about this. Likely for any project you're working on, salting and hashing the passwords will prevent casual attempts at getting people's passwords. Unless you have the resources and responsibility of a bank or similar institution, you not going to have the resources to prevent attacks, but you also won't have persistant hackers attempting to get your data.

(As a side note, even salting and hashing is better than what some high-profile bank/credit card processors who were hacked had done, so if you're hashing and salting, you're doing enough).

[eluser]wowdezign[/eluser]
So, what about running an algorithm on the stored salt before it is hashed?

Then, it wouldn't be site wide or the stored one.

For example:

Code:

Stored salt = Hf35s09W
The Salt used = 5Hf309Ws

In that example, all I did was take the two center characters of the stored salt and moved it to the ends. This pattern could be as complex as you wanted it to be.

The key is that the attacker would have to know how you mutate the salt in order to use the salt.

Unless I have overlooked something, it seems like a simple way to use the advantages of each of the two methods. Each user has there own salt, it's just not the one in the database. However, the one in the database is the key to knowing the one used to hash the password. *IF* you know how it has been changed before the hash.

It could get all kinds of tricky too, like decrementing each numeric by 1, etc. In fact, you could operate on each position. The key is knowing the pattern that goes with each salt.

[eluser]Ben Edmunds[/eluser]
If they have your database it doesn't matter cause they don't know your salt in the first place.

If they have your code and db it doesn't matter how you manipulate it because they will know how you manipulated the salt.

[eluser]wowdezign[/eluser]
The discussion seems to be past the point of which is best because of what Rick Jolly mentioned in post #16.

If I understood him correctly, he's is saying that it would be easy for an attacker to not use a rainbow table, but just test out dictionary + salt and check it against the hash value.

So if I run

Code:

if(md5(stored_salt + dictionary_word) == hashed_password){
    // log dictionary word (the username)
}

That would yield results very quickly. The known element in this scenario is the dictionary word.

However, in the case of a rainbow table, the known element is the relationship between the hashed password and the potential input. By throwing the salt in the mix, even if it is known

Code:

if(rainbow_hash==stored_hash){
  // log rainbow input (the username)
}

now becomes:

Code:

if(md5(rainbow_input+stored_salt) == stored_hash){
  // log results
}

Two different techniques. (That is if I am following correctly).

That is why the link that that n0xie posted earlier says the slower the hash algorithm, the better.

So the user-specific salt is effective against a "Cracker" that has one goal in mind, to get all the results. And the common operation on the salt (or site wide salt) thwarts the efforts of the "Script Kiddie" that just wants to get anything he or she can.

[eluser]Rick Jolly[/eluser]
[quote author="wowdezign" date="1263003348"]
So the user-specific salt is effective against a "Cracker" that has one goal in mind, to get all the results. And the common operation on the salt (or site wide salt) thwarts the efforts of the "Script Kiddie" that just wants to get anything he or she can.[/quote]
I wouldn't say per-user salt "thwarts" any type of cracker. It just increases time linearly. If time is a few seconds per user, then you might as well have one salt. That was my point in response to Chad.

Now, you could slow down the hashing which might make a per-user salt more compelling. A single md5(salt + password) is too fast. But even a slow algorithm won't slow a cracker if the required dictionary is small. I'm convinced the only method to foil a cracker worth mentioning is to enforce complex passwords.

[eluser]Rick Jolly[/eluser]
[quote author="wowdezign" date="1263003348"]
...
If I understood him correctly, he's is saying that it would be easy for an attacker to not use a rainbow table, but just test out dictionary + salt and check it against the hash value.

So if I run

Code:

if(md5(stored_salt + dictionary_word) == hashed_password){
    // log dictionary word (the username)
}

That would yield results very quickly. The known element in this scenario is the dictionary word.[/quote]
Actually, I was suggesting creating a rainbow table first.

Code:

for ($i = 0; $i < $dictionary_size; $i++)
{
    $hash = md5(stored_salt + $dictionary_word[$i]);
    $rainbow_table[$hash] = $dictionary_word[$i];
}

if (isset($rainbow_table[$hashed_database_password]))
{
    echo("got ya");
}

[eluser]SpooF[/eluser]
Huge question here... are you trying to protect the users password, or the information of the user on your site? First of all if they have access to your database (through sql injection) they can simple look at what ever data you have, if not edit it. If they have your code, your just screwed because they can just CHANGE THE HASH. They don't need a rainbow table because they know how the hash is made.

What exactly are we arguing about? I guess it really comes down to how they gained access to your code/database

[eluser]Rick Jolly[/eluser]
[quote author="SpooF" date="1263007944"]Huge question here... are you trying to protect the users password, or the information of the user on your site? First of all if they have access to your database (through sql injection) they can simple look at what ever data you have, if not edit it. If they have your code, your just screwed because they can just CHANGE THE HASH. They don't need a rainbow table because they know how the hash is made.

What exactly are we arguing about? I guess it really comes down to how they gained access to your code/database[/quote]
Have you ever reused a password Spoof? I'm thinking about bank accounts and such.

[eluser]SpooF[/eluser]
Yes, but I never use the same password on anything sensitive. I reuse passwords for forums but nothing I have put money into. I understand what your talking about now though.