[Nico]

Very.... very nice post, Kyek!

But I'd like to add one example in which global (hard coded) salts are more secure.

Let's assume we don't have access to the database, and our intention is not to look up passwords in rainbow tables. But instead, we have found an SQL exploit in a vBulletin forum, which allows us to modify an UPDATE query that writes to the "users" table.


We can do two things with that:

• Grab the admin's password hash, and copy it to another field (which we can see without direct database access).
  
  
  • vBulletin uses unique salts for each user, and therefore it's very unlikely to find a match in a rainbow table. Brute forcing would probably be required to get the admin's password.
    
    
  • In that case, you're right, a global salt would be close to redundant.
  
  
  
• Change the value in the "password" field.
  
  
  • The user passwords are hashed using unique (well, probably unique) salts. That's great, but it doesn't protect us from reusing the salt, to generate a new password.
    
    
  • We only have an SQL exploit, and still no access to the file system. But since there's no global hash, we can just run a query similar to:
    
    

    UPDATE `user`
    SET `password` = MD5(CONCAT(MD5('New password'),  `salt`))
    WHERE `userid` = 1
    

    
    
    ... and bang, now we're able to log in using the new password. A global salt could have prevented this because we're not able to access PHP variables from SQL.

Since SQL exploits are likely the most common (remember the pre-this-thread days?), I think it's a good practice to use a global salt. Now vBulletin relied on its own code, but didn't think that some of its add-ons (or "hacks", how they like to call them), might be insecure, and open the SQL injections.

So personally, I prefer to use both, one global and one unique salt.

[Kyek]

Nico, on 20 September 2010 - 09:25 AM, said:

Very.... very nice post, Kyek!

But I'd like to add one example in which global (hard coded) salts are more secure.

That's a very good point . Even so, though, I think a symmetric encryption is the better option. Not only does it unequivocally protect against an attack like the one you described, it also protects against a range of other attacks. AND it's something more feasible to store in a config file so it's changeable by the end user (should you be the type to distribute your code) whereas telling "global salt" to most folks implies a hardcoded value in the app.

So while a global salt would definitely help protect against that one specific kind of attack, I still think an actual encryption may be the more secure long-term method

[kmyr]

Informative and to the point, very good read
I do agree that the value-proposition of adding global salts is low and I believe all I've said personally is that in some types of attacks - mainly targeted ones, not practical for use on a huge set of users - it could potentially add value, if I was unclear about that and confused people I do apologize.


It's was also an interesting read for me because I realised I've been contradicting myself
I've been using ripemd160 as my hashing algorithm of choice because I don't care too much about speed and because it's relatively unknown and unused in comparison to md5 and sha1 which likely means there are fewer lists out there.

At the same time I've been trying to find ways to make it likelier to find a collision rather than the original password - something which would be much easier to do with a basic md5 hashing function like the one you describe.

I'm probably going to rethink how I hash passwords based on this post - mission accomplished Kyek.

[Dissident]

A tip to all of you making your own hashing "algorithms" like this:

<?php

function awesomeHashingAlgorithm($data, $salt) {
return md5(md5(md5(sha1(md5(sha1(base64_encode(substr($salt, 1,1) . strrev(base64_decode($data))) . $salt . $data . $salt . $data . md5($data)))))) . "GLmd5(mdsha15())))))OBAL SALT, md5(md5(" . "I'M UNHAXABLE LOLOLOLOLOLOLOL");
}

?>

You're wasting your time, your code is useless, you're no more secure than before, your code is slow, no one cares about your arbitrary algorithm, etc.

[Nico]

Kyek, on 20 September 2010 - 09:33 AM, said:

So while a global salt would definitely help protect against that one specific kind of attack, I still think an actual encryption may be the more secure long-term method

Point taken! Thanks!

[Dissident]

Here's an interesting fact some of you may not be familiar with. Due to the way MD5 and SHA1 (among others) work, the following is not good:

md5(md5($salt) . md5($password))

(I believe Kyek and I do this, I only realized people shouldn't be doing this a while ago.)

Apparently, a brute forcer would only have to calculate the salt once and then begin to use the MD5 algorithm and append the password data to generate tables. This would render the entire idea of a salt for protecting a single user's password slightly pointless. Salts should always go after the password, like this:

md5(md5($password) . md5($salt))

This is just a more secure habit, mind you. Don't worry, elves will not sneak up on you, burn your house down and leave you naked in the middle of the desert for doing it the former way.

[Kyek]

Dissident, on 20 September 2010 - 10:25 AM, said:

Here's an interesting fact some of you may not be familiar with. Due to the way MD5 and SHA1 (among others) work, the following is not good:

md5(md5($salt) . md5($password))

(I believe Kyek and I do this, I only realized people shouldn't be doing this a while ago.)

Apparently, a brute forcer would only have to calculate the salt once and then begin to use the MD5 algorithm and append the password data to generate tables. This would render the entire idea of a salt for protecting a single user's password slightly pointless. Salts should always go after the password, like this:

md5(md5($password) . md5($salt))

This is just a more secure habit, mind you. Don't worry, elves will not sneak up on you, burn your house down and leave you naked in the middle of the desert for doing it the former way.

Interesting! That's the first I've heard that. I'm not sure I follow the logic, though -- because with the salt-last algorithm, wouldn't it be just as easy to calculate the salt once and then prepend the brute attack?

[NoizeMe]

Kyek, on 20 September 2010 - 11:09 AM, said:

Interesting! That's the first I've heard that. I'm not sure I follow the logic, though -- because with the salt-last algorithm, wouldn't it be just as easy to calculate the salt once and then prepend the brute attack?

I think he was talking about a global salt and not a unique user salt ;D.
If your salt would stay the same all the time you would need knew the first X character of every result.

Lets pretend this case:

$salt = "12345";
$password = "password";
$hash = md5(md5($salt) . md5($password));

Once we decoded $password once our code renders to:

$hash = md5(md5("12345") . md5($password));

We successfully eliminated the hash.
That does not happen to us if we append the hash, because we are not getting the same ending everytime .
This also makes it okay to store the user salt right next to the hashed password.

A small note to using symmetric encryption on the passwords being better then a hard-coded hash:
If you once introduced a global hash to your process you never, ever be able to change it, which is logic.
But you actually CAN change the password of a symmetric encryption at any time without rendering your data to a useless chunk .

[magik]

Kyek, on 20 September 2010 - 11:09 AM, said:

Interesting! That's the first I've heard that. I'm not sure I follow the logic, though -- because with the salt-last algorithm, wouldn't it be just as easy to calculate the salt once and then prepend the brute attack?

not sure I understand that either. And wouldn't the outer md5 negate the brute force? Wouldn't the hacker need to know if the salt/md5(salt) is either prepended or appended to the user's pass/md5(pass) ?


Also, in regards to the global salt debate. I think I agree with Kyek, although yes, this does put another level of "security" on top, is it needed? and does it really prevent much? If the problem is SQL injection and being able to find the stored data in the users table, wouldn't a better solution be to attack that problem - the SQL injection hole? Another thing, if you can't patch SQL injection holes, or the way you code is innately prone to SQL injection attacks, then maybe a better idea would be to practice better SQL injection prevention techniques... Sure a global salt can be one of them, but in my mind it'd be better to re-structure your database. Don't call your users table "users", that's an easy guess. Maybe you should store your password hash and salts in another table with a hard to guess name? I guess this doesn't really help if you have so many SQL injection problems that you don't sanitize any user input, as you would probably expose this table in the end anyways....

Quote

A small note to using symmetric encryption on the passwords being better then a hard-coded hash:
If you once introduced a global hash to your process you never, ever be able to change it, which is logic.
But you actually CAN change the password of a symmetric encryption at any time without rendering your data to a useless chunk .

if you change the password of a symmetric encryption, wouldn't you need to go back an re-encrypt the data? I guess you still have the ability to do this if you use encryption, but with a hash, since you can't un-hash it, you'd have to get the original input again

[derTechniker]

Thanks Kyek for this great post (again).

Still i have some questions:

Quote

Choose a fast, simple symmetric encryption algorithm (RC4, Blowfish... your call), generate a key and store it somewhere in a configuration file.

What do you mean with that? Could you please give me an example code?

Quote

They'd just rainbow table it, and the global salt won't make your password any more secure than a properly long user salt would.

Well what is a properly long salt? md5(time()) ?

Thanks

[Kyek]

derTechniker, on 20 September 2010 - 01:03 PM, said:

What do you mean with that? Could you please give me an example code?

It's all a little different depending on which encryption algorithm to use. Really, it's overkill unless your site is big and folks target attacks at it. If you're interested, though, read up about mcrypt.

Quote

Well what is a properly long salt? md5(time()) ?

Read a little further down ;-) I usually generate a 5-10 character string to store in the database, then hash that. It's not a set-in-stone rule, but it's generally good practice to hash enough characters that you can guarantee collisions on some level. md5'ing the string versions of two 120-bit hexadecimal numbers does a fairly decent job of that without being overly heavy, and is very easily portable to other languages including SQL itself.

[dida]

Once i've heard about a function called crypt() or something like that. Is that safe to use? Is it worse than md5?

Oh and great tutorial! I was looking for something like this

[Kyek]

dida55, on 20 September 2010 - 01:24 PM, said:

Once i've heard about a function called crypt() or something like that. Is that safe to use? Is it worse than md5?

Crypt is just a gateway function to a bunch of different hashing algorithms, MD5 included. Check out the documentation-- it gives all the details: http://php.net/manua...ction.crypt.php

[dida]

Great, thank you. +rep (when i'll be on pc)

[Dissident]

Kyek, on 20 September 2010 - 11:09 AM, said:

Interesting! That's the first I've heard that. I'm not sure I follow the logic, though -- because with the salt-last algorithm, wouldn't it be just as easy to calculate the salt once and then prepend the brute attack?

MD5( A) works O(n) from left to right of input A, with a growth rate of n which is smaller than the growth rates of MD5( B) and MD5( C) where A = B ∪ C.

If you want an English explanation: MD5 works from left to right on the input. If your salt comes first, a brute forcer can save the state of the algorithm (in particular, the current content of the initialization vector) and resume from that position when it evaluates md5($password) for every $password it is bruteforcing.

If you place the salt afterwords, it must process the md5($password) and then process the md5($salt). Following me?

[Mack]

You said that no type is more secure then the other. That is not true, as md5 has a higher chance of colliding then others. Its a low chance, but I have seen it happen

[magik]

Dissident, on 20 September 2010 - 02:57 PM, said:

MD5( A) works O(n) from left to right of input A, with a growth rate of n which is smaller than the growth rates of MD5( and MD5( C) where A = B ∪ C.

If you want an English explanation: MD5 works from left to right on the input. If your salt comes first, a brute forcer can save the state of the algorithm (in particular, the current content of the initialization vector) and resume from that position when it evaluates md5($password) for every $password it is bruteforcing.

If you place the salt afterwords, it must process the md5($password) and then process the md5($salt). Following me?

Ohhhhh I see it now! If one were to brute force using a specific char range/length range, then a hacker could speed up the calculations by not just re-calcing the entire MD5, but instead branching off the "states" and adding different string inputs after these branches. Saving the hacker form having to re-calc all the data that's been hashed so far ( that was the same string input ).

Ingenious!

Mack, on 20 September 2010 - 03:08 PM, said:

You said that no type is more secure then the other. That is not true, as md5 has a higher chance of colliding then others. Its a low chance, but I have seen it happen

rate of collision != security

they are related, but not synonymous - less collisions != more security, just as more collisions != less security. They aren't related like that.

if you read Kyek's post, you would notice that he mentions that you want a hash that DOES collide. What you have to think about is that all hashes collide, it's a fact of their nature. What the different hashes change though, is the rate of collision. If you use a longer hash, it is less likely to collide, but you WANT collisions. Not enough collisions that a string of say password length collides with another string of password length, but enough that when you md5 a salt + password, that there ARE collisions - so that brute forcing would produce false positives.

[Dissident]

Mack, on 20 September 2010 - 03:08 PM, said:

You said that no type is more secure then the other. That is not true, as md5 has a higher chance of colliding then others. Its a low chance, but I have seen it happen

I don't think Kyek meant to say MD5 was more secure than others, like SHA1, and that he is by no means trying to promote use of MD5. He's just saying that when it comes to password hashing, some people seem to think all of their problems go away if they replace md5 with something else.

Kyek's point is that instead people should be focusing on salting passwords rather than using a different hash algorithm, since the majority of attacks against passwords are brute-forcing attacks.

[BokTheGolem]

Mack, on 20 September 2010 - 03:08 PM, said:

You said that no type is more secure then the other. That is not true, as md5 has a higher chance of colliding then others. Its a low chance, but I have seen it happen

Didn't he talk a lot about collisions or did is misread or did you not read? Not being mean just saying.
As it said ALL hashing functions have a chance for collision, ALL. Shorter hashes such as 32 bit collide more than higher hashes like 256. However having some collisions can be helpful for such things as rainbow tables where collision can cause it to loop? Thats what I got from it. Makes sense

Also hashes and things like random numbers are one thing I could never get my head around.
Like for random functions (i'm not 100% sure how this works so just going off what I know) there are many which allow you to retain the "random seed" with which the function generates the random number. Therefore it seems statistically possible to be able to guess a random number from this random seed or at least derive some sort of guess from it.

And same thing with hashing, some sort of function hashes it so is it simply not possible to reverse said function? I know it'd be insanely hard but computer wise I can just never understand how a computer can do things one way and not the other. It can;t possibly generate parts of a hash randomly else there would be random collisions and the hash could be different every time Furthermore the mere presence of collisions proves that the hash must have some sort of common method which could possibly be reversed. If it does it bit by bit could an analysis of two colliding hashes not see some sort of way to reverse?

I guess i'd need to take some college course on these things to understand Maybe asking a bit too much knowledge

Wow in the time it took me to write this two more posts have popped up

Also to the poster above while he is not expressly saying use MD5 he does say for a language like php it is faster and has no downside to say SHA-1. Just saying that because it sounds like you still have some negative connotations associated with MD5, but maybe im wrong. Just from what I read from this MD5 == perfectly acceptable and even faster and just as secure on php.