Md5 & salt question

[perky416]

Hi guys,

 

Iv been reading into password salting and im struggling to understand its purpose.

 

From what iv read you can basic salt a password by doing the following:

 

$salt = "randomtext";
$password = "apple";
$password = md5($password.$salt);

 

I was wondering though, if a hacker is able to crack the md5, wont they see the password and the salt? Example: a hacker cracks the md5 to reveal applerandomtext.

 

From applerandomtext it wont be hard for them to work out that the password is apple. So doesn't that make the idea of salting pointless?

[jordanmoore]

MD5 cracks mainly work on a collision basis. This means that they create another string which creates the same hash.

For example (this is not a working example), we could have the hash "jordan" coming to "d16d377af76c99d27093abc22244b342", but have the phrase "thisisanmd5collisionSALT" which also comes to "d16d377af76c99d27093abc22244b342".

 

With "jordan" being the "decrypted" version of "thisisanmd5collisionSALT", this would usually pass an MD5 check. However, when the login function applies the salt to "jordan" to make "jordanSALT", we could no longer get "d16d377af76c99d27093abc22244b342" as the hash.

 

So essentially, from what I understand, the SALT protects again collision based attacks.

[btherl]

Password "apple", hashed password md5("apple") - the problem here is that the hacker has a pre-generated table containing md5($password) for every possible $password up to 8 or so characters long, especially dictionary words.  He can instantly look up md5("apple") and find that the password used to generate it was "apple".

 

But if you use a salt, the hashed password is md5("randomtextapple").  It's not likely the hacker will have "randomtextapple" listed in his pre-generated database.  Even if he knows the salt, he still has to generate the md5 hash for every password he wants to guess, instead of looking it up instantly from the table.  If the password is long enough, it'll take so long to try all combinations that the attack becomes impractical without very expensive computing power.

 

The best use of a salt is to have a different salt for each user.  It can be stored in the database along with the hashed password.  Then the hacker has to do an individual attack on each user, instead of a single attack on all users in the database.  If you have 1000 users, it'll take him 1000 times longer to get a match.

[Zane]

Like jordanmoore pointed out, the ONLY way to "crack" MD5 would be through a collision.  And more realistically it is impossible to decrypt an MD5 hash.  I don't care how many website there are out there they say they can do it, those sites are only looking to get traffic and what better way to do it than to offer something that isn't real.

 

Imagine that we were using MD5 for voice encryption, which could be done.  If I encrypt my voice saying "Hello Zanus".. it is theoretically possibly that someone could attempt to mimic my voice and possibly be authenticated.

 

BUT, if I also add a salt.... an extra little voice, automatically added to all my voice passwords, then it is at least 1000 times or more ... more difficult to mimic.

[btherl]

An attack looking for a random collision won't be affected by salts, because the chance of a collision is the same with or without a salt.  It's only focused attacks based on likely passwords that are made ineffective or at least more expensive by salts.

 

You can try going to http://www.md5decrypter.com/ and entering in these to hashes:

 

36f3770213dfaa5d8781958be9a99ff3

1f3870be274f6c49b3e31a0c6728957f

 

Only one of them (the unsalted one) will be solved.  The salted one, which is md5("randomtextapple"), needs a brute force attack, and the data generated during that attack will be worthless for any attacking any other site with a different salt.

[gizmola]

The assumption in using a salt is that some other mistake will have been made (a SQL injection usually) that in some way discloses the md5 hash.  Otherwise, I agree with the comments made in the previous replies.  You should use a salt, however it's just an additional degree of protection.  What you're really trying to do is avoid a worst case scenario where your entire user table leaks out, and you become the source for people reverse engineering the passwords of all your users.  This is certainly a bad situation but not as bad as one where you have the raw md5 hashes that allow anyone with a rainbow table determine what your user's password is, which can then be used to attempt logins at the user's other sites like facebook, gmail etc.  Most people use the same password across multiple sites.  With the salt applied, someone would have to generate an entire new table using the salt, which is also why it's much better to have a salt per user.

[cssfreakie]

With the salt applied, someone would have to generate an entire new table using the salt, which is also why it's much better to have a salt per user.

 

Just to be sure I understand what you say here: could a table look like this:

 

ID | username | password_hashed | salt

---+------------+--------------------+--------------

1  |John        | HJDUuEBujsu271 | fatmonkeys

---+------------+--------------------+--------------

 

Where salt is a random string that is being created on registration, for that specific user, and on login the system checks if the value entered + the salt in the database = the same as the hashed value.

 

Btw, wouldn't that require 2 database queries instead of 1? Sorry i am not a big hero in php, but it seems logical to me this way.

[btherl]

Yep, that's the way.  You can do it all with one query which fetches both the hashed password and the salt.  Then compare md5(salt+password) against password_hashed.  It doesn't matter if you use salt+password or password+salt as long as you do it the same way every time.

[cssfreakie]

Yep, that's the way.  You can do it all with one query which fetches both the hashed password and the salt.  Then compare md5(salt+password) against password_hashed.  It doesn't matter if you use salt+password or password+salt as long as you do it the same way every time.

 

wicked! thanks for the response!

[perky416]

Ahhh i understand now.

 

I was getting the impression that people could easily de-hash an md5 password and reveal the plain text of the hash. Thats why i was starting to wonder lol.

 

So what most of you are saying is that the hacker has a database with hashed words that he just checks against the user passwords. And adding the salt means the password wont pop up fro his list.

 

Thanks guys,

 

 

[Psycho]

I think this is the first post on hashing that didn't get out of hand with a bunch of idiotic responses. There are really two separate issues discussed above. I'll add my 2 cents:

 

First of all it is important to know that hashes are not encryption. They are NOT meant to and cannot be unencrypted (at least not in a real sense).

 

The "collision" problem that was referred to really has no relevancy with passwords. Collisions with hashing IS an issue though. Collisions refers to the frequency of when two separate inputs could result in the same hashed value. Since hashes aren't meant to be decrypted to the original input value it may not seem like a big deal. But, you have probably seen sites that allow you to download executables, pdfs etc. and include a hashed value for the download. That is so you can run a hash on the file after you download it to ensure it matches the one the site provides. This is typically used when a provider allows 3rd party sites host the downloads to ensure one of those third party sites isn't compromised. With a large enough input hashed with MD5 it is possible to create a rogue file that has the same characteristics as the original and will result in the same MD5 hash. But, that is not a problem with passwords. If it was a user could enter the wrong password and still be authenticated.  Passwords are finite values that have a limited character set and a limited count of characters. Although not proven (that I am aware) I would bet there are no combinations of strings from 1-32 characters that would generate the same MD5 hash.

 

So, the reason we hash passwords - as stated above - is that if the user database was compromised we don't want a malicious users to know what the passwords are. Many people use the same usernames/passwords on multiple sites - which is a bad, bad idea. If a user's password is compromised on one site a malicious user could try that username/password on multiple other sites (e.g. banking sites) until they found a match. Now, the fact that MD5 has an issue with collisions is irrelevant when hashing passwords. A hacker isn't trying to find a value that will result in the same MD5 hash, they are trying to ascertain the input value.

 

But, as stated above a hash cannot be unhashed, right? That is true, but the same input will always results in the same hashed value. Plus, may users - stupidly - use common words for their password (e.g. "password"). For this, hackers use a dictionary/rainbow table where they has common words/phrases and store the original and hashed values. If they have a hashed value and compare it to their table it could return the original value IF they had included that value in the values they had hashed. That is why users should use strong passwords (upper/lower case letters, numbers, and special characters). To generate a table with all possible values up to the limit of most passwords would take many, many years.

 

If you add a salt - especially if the salt is unique for each user - it is far more difficult. Even if the hacker has the hashed value and the salt, they would have to regenerate all the values in their table using the salt.

 

- - - - - - - -

 

By the way, for the salt I would propose something other than just appending a word as cssfreakie suggested. Use some random text as you apparently intended. Otherwise you could end up with an input value that is two words put together. It would still be "pretty good" but after creating hashes of single words the next thing they would add would be two words (or 1337 text). You could also do somethign such as reversing the letters.

[gizmola]

*it seems like I'm repeating a lot of what mjdamato wrote, but I swear I was writing this at the same time he was   *

 

Yes, md5 is a 1-way hash.  Hashes are used in a lot of different ways and were really designed to help fingerprint data or provide checksums.  People still gravitate towards it because it is a fast computation and has been widely implemented.

 

For example, in redhat linux's RPM system, when you generate a package, md5 is used to fingerprint every file in the package.  This can later be used to determine if a particular file that came in the package was changed since the time it was originally installed. 

 

The benefit of using it for a password is that it absolves you of responsibility or ability to look at someone's password, which over time has become the generally accepted best practice.  Just for the record, you do have the alternative of using sha1 which is cryptographically stronger than md5.  I don't want to overstate the issue however.  What many people seem to miss is that the weak link is typically someone's password.  So if you allow a system to brute force attack your site trying different accounts and using a table of passwords there is a good chance they will determine the password for any number of users.  That is a far more likely scenario, and requires code and strategies to prevent it from happening.

 

 

 

[cssfreakie]

By the way, for the salt I would propose something other than just appending a word as cssfreakie suggested. Use some random text as you apparently intended. Otherwise you could end up with an input value that is two words put together. It would still be "pretty good" but after creating hashes of single words the next thing they would add would be two words (or 1337 text). You could also do somethign such as reversing the letters.

I totally agree with mjdamato, and the word I used i think it was "fat monkeys" was just as an example. Any ways thanks a lot on then explanation. I think a lot of people will find this useful at least I do.

 

Cheers!

 

Cssfreakie

[JonnySnip3r]

A very interesting a useful topic []

[phpSensei]

Yep, that's the way.  You can do it all with one query which fetches both the hashed password and the salt.  Then compare md5(salt+password) against password_hashed.  It doesn't matter if you use salt+password or password+salt as long as you do it the same way every time.

 

wicked! thanks for the response!

 

I think PHPBB software uses this method

 

I have seen a few forum softwares do it this way

 

I also don't understand why there is such long posts regarding the matter, its very simple, I won't explain because you guys just did 20 times over lol.

[efficacious]

they do.. the passwords are stored in the DB hashed, when the user logs in the typed password is then hashed and compared to the hash in the DB.

 

Its really nice method because the only person who ever knows what the password is, is the user who typed it.