Public Safety Announcement: On the subject of password security

[MikesMechanix]

Unless you're a cryptographer you shouldn't be writing your own cryptographic functions.

This.

99 % of what's being said about password hashes here seems to be inaccurate or flat out wrong.

MD5 isn't nearly as weak as people seem to think. A lot of is because articles often say things like "a 6-character alphanumeric MD5 can be cracked in a second these days". While that may be true, they often fail to mention that the required time grows exponentially with each character. A 12-character one takes 56800235584 times longer. If the "in a second" part is correct, that's 1801 years. Add a special character in there and you are looking at 540360087662636962890625 combos. At 10 terahashes per second you will be through them all in some 600000 years. And that's just a simple MD5. Unix crypt does it somewhere around 1000 times over with some added flavors.

The purpose of a salt also seems to be misunderstood. It's really only there so that each password needs to be tested separately. Having something 'secret' added to the string doesn't hurt, but it doesn't add any value to cryptographic strength. It's really just a plaintext password hidden in code.

[MikesMechanix]

I have often seen suggestions to use song lyrics or portions of books. Consider this: I think in the history of mankind, fewer than 1.844674407×10¹⁹ paragraphs have been written. If your password has ever been published, assume Google or well-funded governments have it in their database. That includes examples of "secure" passwords and known UUID's

Using just plain song lyrics would be really, really bad advice.

Deciding on an algorithm only known to oneself and using song lyrics as a source of entropy is a good idea.

[M4v3R]

This.

99 % of what's being said about password hashes here seems to be inaccurate or flat out wrong.

MD5 isn't nearly as weak as people seem to think. A lot of is because articles often say things like "a 6-character alphanumeric MD5 can be cracked in a second these days". While that may be true, they often fail to mention that the required time grows exponentially with each character. A 12-character one takes 56800235584 times longer. If the "in a second" part is correct, that's 1801 years. Add a special character in there and you are looking at 540360087662636962890625 combos. At 10 terahashes per second you will be through them all in some 600000 years. And that's just a simple MD5. Unix crypt does it somewhere around 1000 times over with some added flavors.

The purpose of a salt also seems to be misunderstood. It's really only there so that each password needs to be tested separately. Having something 'secret' added to the string doesn't hurt, but it doesn't add any value to cryptographic strength. It's really just a plaintext password hidden in code.

Take notice that not many people use 12 character passwords. Heck, most of the hacked passwords I saw was 6-8 character long. Also, if you take GPU hashing into account, the times needed to crack them drops significantly.

The salt has real value - it prevents rainbow table attacks. Without it, one could crack many passwords in a fraction of a second.

[BCEmporium]

Actually is ironic that a lot of BTC users were hacked using a technique mostly developed to actually mine BTC; GPU hashing.

[Rob P.]

The salt has real value - it prevents rainbow table attacks. Without it, one could crack many passwords in a fraction of a second.

Too bad MtGox stored the salt in the password field, next to the password. 

[BCEmporium]

The salt has real value - it prevents rainbow table attacks. Without it, one could crack many passwords in a fraction of a second.

Too bad MtGox stored the salt in the password field, next to the password.  

Unless you use a single admin-added salt to everyone, you need to store the salt per-user for use different ones to everybody.
Also that is the way crypt returns it:

Code:

<?php
$a = crypt("pass","$1$salt$");
echo $a;

will return something like $1$salt$klhi%$# (not exactly this hash output)

Single salt added by config can be brutte-forced if the attacker has a hash for which he knows the password, eg for md5:

Pwd: 12345
$k = 0;
while($result != $hash){
 $result = md5("12345",$salts_to_try[$k]);
 if($result == $hash) $salt = $salts_to_try[$k];
$k++;
}

[Rob P.]

The salt has real value - it prevents rainbow table attacks. Without it, one could crack many passwords in a fraction of a second.

Too bad MtGox stored the salt in the password field, next to the password.  

Unless you use a single admin-added salt to everyone, you need to store the salt per-user for use different ones to everybody.
Also that is the way crypt returns it:

Code:

<?php
$a = crypt("pass","$1$salt$");
echo $a;

will return something like $1$salt$klhi%$# (not exactly this hash output)

Single salt added by config can be brutte-forced if the attacker has a hash for which he knows the password, eg for md5:

Pwd: 12345
$k = 0;
while($result != $hash){
 $result = md5("12345",$salts_to_try[$k]);
 if($result == $hash) $salt = $salts_to_try[$k];
$k++;
}

"Stored per user" doesn't mean "Stored next to password, per user". 

It could have been stored on a separate system, in a separate database.  Which would have made the leaked passwords worthless without the other "half" of the password file.

No one is arguing against having per-user salts.

[mrb]

It's not 25 rounds. It's 25 * login length + 25 * password length + 1 iterations. So it's basically few hundrets. Did you measure this code or just 25 rounds of SHA-512?
I stand corrected on the random salt though - it shouldn't derive from username alone.

gmaxwell's point still stands though. A few hundred rounds of SHA512 is not sufficient. This is barely a bit more computationally intensive than MD5-based crypt(), which is not good enough and which is why MtGox and modern Linux distributions are phasing it out.

(Also an undesirable property of your hash function is that the pw/user pair "a:b:c/d" will hash to the same as "a:b/c:d" or "a/b:c:d".)

Use PHP's builtin crypt() CRYPT_SHA512 people! Don't re-invent your own crypto.

PS: I write password bruteforcers.

[mrb]

"Stored per user" doesn't mean "Stored next to password, per user". 

It could have been stored on a separate system, in a separate database.  Which would have made the leaked passwords worthless without the other "half" of the password file.

This is pointless. This is the same as saying "store the hash on a separate system and make sure it does not get stolen". Hashes (and salts) both get stolen and must be designed to withstand bruteforcing as best as possible.

The point of a salt is not to be secret but to be unique. It can be stored alongside the hash. It is an industry-standard practice (think all Linux/Unix systems).

[netrin]

The point of a salt is not to be secret but to be unique. It can be stored alongside the hash. It is an industry-standard practice (think all Linux/Unix systems).

This is certainly true, but the salt/nonce can also be thrown out. Known as strengthening or stretching. Now both the server and attacker need to do extra work, just that the server at the time of authentication has much more information, namely the plaintext password.

[dserrano5]

Quick question: could a simple CRC32 (plus some additional mangling) of the login be used as a salt? That way, it wouldn't have to be stored, it just would be computed everytime it was needed.

(Only useful on closed-source projects, tho).

[mrb]

@netrin: stretching means iterating the hash function multiple times, eg. 1000 times for Unix MD5()-based crypt.

@an0therlr3: it would lower security to derive a salt from the username only. If an app was doing that and came with a default account (say "admin"), then every user of this app choosing the same admin pw would result in the same hash being generated everywhere.

[netrin]

Quick question: could a simple CRC32 (plus some additional mangling) of the login be used as a salt? That way, it wouldn't have to be stored, it just would be computed everytime it was needed.

(Only useful on closed-source projects, tho).

Your suggestion is just adding a simple variation to the hashing algorithm which may prevent an attacker from using an off-the-shelf rainbow table as long as it is a unique idea. If no one knows this is your technique then it is an effective security-through-obscurity measure but if the attacker does know of this technique then an attack table can be compiled even before or while compromising the password list. And what advantage do you have over a salt? saving 10 bytes on disk per user. Sure use a hash of the username as well. I don't think it'll hurt.

This is similar to including a secret into the hash, which is compiled into code (not the password file/database). It's a fine example of security-through-obscurity as it increases the difficult or required attack vectors, but not particularly robust.

[dserrano5]

Quick question: could a simple CRC32 (plus some additional mangling) of the login be used as a salt? That way, it wouldn't have to be stored, it just would be computed everytime it was needed.

(Only useful on closed-source projects, tho).

If no one knows this is your technique then it is an effective security-through-obscurity measure but if the attacker does know of this technique then an attack table can be compiled even before or while compromising the password list. And what advantage do you have over a salt? saving 10 bytes on disk per user.

Re: the attacker knowing of the technique, that's exactly why I said it would be only useful for closed-source apps.

The main benefit isn't the 10 bytes on disk, but the fact that the salts aren't stored anywhere, so they can't be stolen unless the hacker gets to the source code, in which case the impact of the compromise is more severe than just a user/password database leak.

[mrb]

Netrin, with your technique the salt is known: it is effectively the username (plus a fancy hashing algo that you want to keep secret). It is trivial to reverse engineer the hashing algo of a closed source app. People have done this for Oracle, Windows NTLM auth, etc. All closed source and all have been reversed engineered and documented.

[BCEmporium]

So, mrb, you made a good point for use just MD5 or RipeMD

Basically your statement is: giving enough computing power and every hash can be broken.
Well, MD5 is fast, protects you in case someone had his eyes on the database, and protect the db is the realm and responsibility of the site's owner. Going further to paranoia levels, will just make you to waste electrical power for nothing.

[mrb]

No. My point is: use industry standards like PHP's builtin crypt() CRYPT_SHA512 mode. They are an excellent compromise between CPU time & strength.

You have no reason to refuse to follow industry standards.

[netrin]

Netrin, with your technique the salt is known: it is effectively the username (plus a fancy hashing algo that you want to keep secret). It is trivial to reverse engineer the hashing algo of a closed source app. People have done this for Oracle, Windows NTLM auth, etc. All closed source and all have been reversed engineered and documented.

Thanks, but I respectfully deny credit for this security through obscurity technique. I stated at best this saves 10 bytes but was not robust.

[BCEmporium]

No. My point is: use industry standards like PHP's builtin crypt() CRYPT_SHA512 mode. They are an excellent compromise between CPU time & strength.

You have no reason to refuse to follow industry standards.

So was MD5 10 years ago...

You've a GOOD reason to NOT follow industry standards actually; it's called "Rainbow Tables" and alike.
MD5 was never broken, NTLM was never broken, all of those 1-way hashing mechanisms were never broken, what happened is that they're "industry standards", so it become easy to create dbs with their possible contents.

[BCEmporium]

Thanks, but I respectfully deny credit for this security through obscurity technique. I stated at best this saves 10 bytes but was not robust.

You take this as a dogma, but security IS obscurity. Otherwise there would be no problem into have databases for all sites published in the web.
Data security is to create counter-measures for the principles of information:

WHEN - Information is only valid for a period of time, if someone tips me now that the Nazis have plans to invade Poland it is useless information, as it already happened.

WHERE - Information is only valid at some places. If I get an user/pass db but have no idea from which site it came from, I can do nothing with it.

HOW - What was used to conceal that information. If I can't figure that out within the WHEN buffer I may have useless information in hands. Using "industry standards" or "clear to all security" voids this point, as it's known what was used. The issue may be that a bad cryptographer may create a weak to break code, but variances of known algorithms can help.