Here is another "lazy developer" hash strengthening technique. It is what I refer to as variable entropy, and the idea is that entropy is appended to the end of a password before being hashed, but the length of the entropy is unknown. All that is known is the range of the length of the entropy. The length of the entropy is chosen when the hash is originally created between a minimum and maximum value for the number of entropy bytes desired. The larger this difference is, the better.
The entropy byte count is pseudo-randomly chosen, then a known byte value is appended to the password that many times. This value can be generated by some algorithm you devise, or in the lazy case, just append the same byte over and over. Conceptually, either works. What this does is make it so neither the attacker or the server have a hash that can be directly reversed to the password, but allows the server(who is only confirming one hash per login) to quickly verify the password, where it will increase the processing required by a hash cracker even more. For the hash cracker to verify an input is not the password, it would need to hash with every possible entropy count, therefore, only the correct input will take the shortest amount of time.
Please let me say, this isn't an excuse to not use proper hashing methods, such as actual salts, and algorithms such as bcrypt and PBKDF2. This is just a lazy idea to make hash cracking take longer without much effort at all from developers. For strong cryptographic hashing measures, please look at the research paper on it, as well as the blog post on using digital signatures for storing hashes.
Here is a quick code sample.
//Variable Entropy PoC
//Generic random seeding with current time from php.net
function make_seed()
{
list($usec, $sec) = explode(' ', microtime());
return (float) $sec + ((float) $usec * 100000);
}
srand(make_seed());
//Number of bytes of possible entropy
$min_entropy = 5;
$max_entropy = 1024;
function GenerateHash($password)
{
global $min_entropy;
global $max_entropy;
$entropy_count = rand($min_entropy, $max_entropy);
for($iter = 0; $iter < $entropy_count; $iter++)
{
$password .= chr(0x80);
}
//This is not hash algo specific, so md5 is the example
return hash("md5", $password);
}
$password = "password";
print hash("md5", $password)." is the md5 hash of 'password'
";
$VEHash = GenerateHash($password);
print $VEHash." is the variable entropy md5 hash of 'password' with between $min_entropy and $max_entropy 0x80 bytes appended to it.
";
if(VerifyPassword($VEHash, $password) === true)
{
print "'password' is the password
";
}
if(VerifyPassword($VEHash, "not the password") === false)
{
print "'not the password' is not the password
";
}
?>
One possible output is as follows:
5f4dcc3b5aa765d61d8327deb882cf99 is the md5 hash of 'password'
e756fc1bbb96a0da2e990d6e50f4f741 is the variable entropy md5 hash of 'password' with between 5 and 1024 0x80 bytes appended to it.
'password' is the password
'not the password' is not the password
Another:
5f4dcc3b5aa765d61d8327deb882cf99 is the md5 hash of 'password'
f03d3e5fea455e2440e4c4665d424666 is the variable entropy md5 hash of 'password' with between 5 and 1024 0x80 bytes appended to it.
'password' is the password
'not the password' is not the password
The creator of that page is a complete idiot. You can use an iterated hash with a salt and be very secure. He should watch calling other people a fool before he makes one of himself. European men like him are such passive-aggressive pussies.
You know what's worse than bad crypto? People who don't know what they're talking about copping an authoritarian attitude on cryptography and posting about it. I'm not sure why all of these Ruby/Javascript cunts have come out of the woodwork to talk about crypto, but they should stick to being mental midgets in some other field.
People would actually want to understand why bcrypt is worth learning if stupid newbies stopped calling them 'idiots' and 'fools'. Remember the definition of "expert" (ex-spurt)? That's most of these people.
The actual advantage of bcrypt over an iterated hash with a salt is that it's less likely to be cracked by parallel hardware. That's it. (Read here: http://security.stackexchange.com/a/6415)
>>4
Uhhh, what? So let's say you store the hash of that password + the entropy string in the database.
How do you verify on user login that the user entered the right password without knowing the entropy string associated with a particular password? You'd have to store it in the database too, meaning you've reinvented a salt.