Why Can't You Hash a Password Multiple Times

[Tjcrazy]

I've had this thought for a while - but always figured there was a reasonable solution to it.

 

I run a CMS system that currently hashes its passwords into MD5 and then into SHA1 passwords - or SHA256, depending on the system.

I've always thought why can't you hash passwords a lot, to make them more secure.

 

For example:

<?php
$password = 'ilovepassword1';
$securepass = sha1(md5(md5(sha1(md5(sha1($password))))));

echo $securepass;
?>

Apart from it being totally stupid, and inefficient - why isn't this a 'proper' solution?

 

Surely to crack it, you'd have to crack every layer- in the example above, 6 layers?

 

 

Would love an answer!

 

 

Tim

[night_stalker_z]

Because its still quite easy to crack.

You need something like a salt added to each password so that the hashes are random.

Now if you were to use 6 salts for each password...

[Joe User]

I'm not great at explaining this. Here's a good article.

 

http://crackstation.net/hashing-security.htm

[threetonesun]

It's better to just generate a random salt and encrypt with that. You could also generate six random salts and hash with each one, or whatever other series you'd like.

 

If you read the news, though, you'll find that many of the sites have all of their users passwords released either stored them in plaintext(!), or didn't salt them, or did other generally terrible things.

[+Xinok Subscriber²]

To give my non-expert opinion on your example:

 

MD5 is broken and should be avoided altogether. There hasn't been a demonstrated attack against SHA-1 yet, but there are ever more effective theoretical attacks against it, so it's time to move away from SHA-1.

 

SHA-1 has an output of 160 bits whereas MD5 only has an output of 128 bits. By alternating between the two algorithms, you're limiting the amount of entropy to 128-bits at most.

 

As others have said, add a random salt which prevents attacks involving hash tables and rainbow tables.

 

Also consider key stretching which increases the time to calculate each hash; while it may seem counterintuitive, the longer it takes to hash a password, the slower brute force and dictionary attacks are. There's a time period between when you get hacked and when you know you got hacked. Key stretching increases the amount of time it takes to perform a dictionary attack on the hashes, which gives you more time to detect the hack and force a password reset on all your users, reducing the number of compromised accounts.

[Andre S. Veteran]

Why should it be more secure? Why shouldn't it be less secure? Can you prove it? Do you have any idea how? 

 

Cryptography is really ######ing hard; only qualified experts can tell that a certain algorithm is secure or not. As far as I'm aware, no expert has ever validated that "chained md5" is secure at all. Rely on known algorithms and don't try to devise your own, unless you really know what you're doing (and you probably don't).

[n_K]

It's more secure against dictionary attacks and rainbow tables, anyone that tells you otherwise is a grade A ****ing idiot.

It makes it weaker to collisions though.

 

People that go on about 'oh double hashing doesn't improve security' really need to have their ability to talk taken away.

Here's a quick example; If a hashing mechanism outputs a 32 character code from any input, and for A you run it once and B you run it twice:

A can be found in a lookup table expecially if it's less than 13 characters. A can also be found using a dictionary or brute-force attack.

B will not be found in a lookup table because it's 32 characters. If someone can provide even a 16 character rainbow table for MD5 (which is known to be broken) please, do. B will not be found in a dictionary attack _AT ALL_ and is incredibly unlikely to be found via a bruteforce attack UNLESS a collision is found. If a collision is found, they have an alternative string that hashes to give the correct MD5 hash, they can't they crack that string to get the original data used for the first MD5 though.

 

The real problems are, if someone has access to your site and database whereby they can read off all the hashed passwords, they can change any password to login to any account so don't need to crack the password at all, if however they want to get something else like a bank account or email account and the person has used the same password for both sites, that's what they'd be cracking the password for.

[srbeen]

I'd think devising a way to randomly rehash passwords at random time intervals may be more beneficial in providing security than devising a way to layer or chain things together.

I'm not a crypto expert but I love learning how the DSS, console, and cellular technologies encrypt and secure their 1's and 0's. From watching these industry leaders it seems real-time internet connected scenarios where the wheel (encryption) can be reinvented/changed at will, or several wheels (encryption keys) working in a phase-shift-keying routine seems more successful than layering or chaining encryptions off one another. Key in encryption is not to rely anything on anything else.. I hope I am making sense here. Sony lasted like 4 years just obfuscating static random numbers before the 3.55 signing bug was discovered. Microsoft lasted like 6 before someone figured out their processor favored 'ok' results when you just blanked the key half-way through its check. If theres a will theres a way, just hope by the time its figured out it the encryption is pointless.

[Phouchg]

  On 17/07/2013 at 22:04, n_K said:

The real problems are, if someone has access to your site and database whereby they can read off all the hashed passwords, they can change any password to login to any account so don't need to crack the password at all, if however they want to get something else like a bank account or email account and the person has used the same password for both sites, that's what they'd be cracking the password for.

 

Which makes the point that strong hash and properly random salt is enough. Instead of wasting server's compute time which is expensive one should focus on other potential weak links. It's easier to compromise the system through someone's idiocy or oversight than brute forcing - a determined attacker will look for existing holes before resorting to making his own.

This belongs to security through obscurity and works unprovably fine, but *only* until attacker gains access to the source code and therefore your method. In web applications he most likely already has such access, so he knows that you're double hashing and it's all for naught.

[n_K]

  On 17/07/2013 at 22:31, Phouchg said:

Which makes the point that strong hash and properly random salt is enough. Instead of wasting server's compute time which is expensive one should focus on other potential weak links. It's easier to compromise the system through someone's idiocy or oversight than brute forcing - a determined attacker will look for existing holes before resorting to making his own.

This belongs to security through obscurity and works unprovably fine, but *only* until attacker gains access to the source code and therefore your method. In web applications he most likely already has such access, so he knows that you're double hashing and it's all for naught.

What's it got to do with anyone gaining access to your code? If someone knows which encryption systems you're using and in which order makes no difference to anything.

They'll only crack the password if they need to for other uses and if they can get their hands on the hashed passwords which would imply they already have full database access. You can usually guess by the length of a hash what type it is.

If all they've got is access to your front end and are trying frantically to crack a user account, it really makes no difference what encyption you are using, how many different times you use it or if you even use encryption at all.

[+Xinok Subscriber²]

  On 17/07/2013 at 22:04, n_K said:

It's more secure against dictionary attacks and rainbow tables, anyone that tells you otherwise is a grade A ****ing idiot.

It makes it weaker to collisions though.

 

People that go on about 'oh double hashing doesn't improve security' really need to have their ability to talk taken away.

Here's a quick example; If a hashing mechanism outputs a 32 character code from any input, and for A you run it once and B you run it twice:

A can be found in a lookup table expecially if it's less than 13 characters. A can also be found using a dictionary or brute-force attack.

B will not be found in a lookup table because it's 32 characters. If someone can provide even a 16 character rainbow table for MD5 (which is known to be broken) please, do. B will not be found in a dictionary attack _AT ALL_ and is incredibly unlikely to be found via a bruteforce attack UNLESS a collision is found. If a collision is found, they have an alternative string that hashes to give the correct MD5 hash, they can't they crack that string to get the original data used for the first MD5 though.

 

The real problems are, if someone has access to your site and database whereby they can read off all the hashed passwords, they can change any password to login to any account so don't need to crack the password at all, if however they want to get something else like a bank account or email account and the person has used the same password for both sites, that's what they'd be cracking the password for.

It doesn't matter how many hash functions you chain together, the fact remains that, in the end, the same password will always produce the same hash. Therefore, you can produce a table for it. The most secure way to protect against hash/rainbow table attacks is to include a random salt so that the same password will produce a different hash each and every time. Doing it any other way is only putting the security of your users at risk.

[giantpotato]

  On 17/07/2013 at 22:04, n_K said:

It's more secure against dictionary attacks and rainbow tables, anyone that tells you otherwise is a grade A ****ing idiot.

It makes it weaker to collisions though.

 

People that go on about 'oh double hashing doesn't improve security' really need to have their ability to talk taken away.

Here's a quick example; If a hashing mechanism outputs a 32 character code from any input, and for A you run it once and B you run it twice:

A can be found in a lookup table expecially if it's less than 13 characters. A can also be found using a dictionary or brute-force attack.

B will not be found in a lookup table because it's 32 characters. If someone can provide even a 16 character rainbow table for MD5 (which is known to be broken) please, do. B will not be found in a dictionary attack _AT ALL_ and is incredibly unlikely to be found via a bruteforce attack UNLESS a collision is found. If a collision is found, they have an alternative string that hashes to give the correct MD5 hash, they can't they crack that string to get the original data used for the first MD5 though.

 

The real problems are, if someone has access to your site and database whereby they can read off all the hashed passwords, they can change any password to login to any account so don't need to crack the password at all, if however they want to get something else like a bank account or email account and the person has used the same password for both sites, that's what they'd be cracking the password for.

 

Genius, so the solution to security is to append 1111111111111111 to all passwords before hashing. Since the password is now 32 characters it won't be found in a rainbow table :/ 

[wrack]

Hashing is multiple times can work most of the time but using salt is a more common practice (in my experience). With that you can use different techniques to use the salt (https://www.neowin.net/forum/topic/1163508-web-server-salt-storage/)

 

Some more good info http://crackstation.net/hashing-security.htm

[n_K]

  On 18/07/2013 at 00:04, Xinok said:

It doesn't matter how many hash functions you chain together, the fact remains that, in the end, the same password will always produce the same hash. Therefore, you can produce a table for it. The most secure way to protect against hash/rainbow table attacks is to include a random salt so that the same password will produce a different hash each and every time. Doing it any other way is only putting the security of your users at risk.

  On 18/07/2013 at 00:14, giantpotato said:

Genius, so the solution to security is to append 1111111111111111 to all passwords before hashing. Since the password is now 32 characters it won't be found in a rainbow table :/

do u even read though?

So you're going to make a rainbow table of 32 character hashes? Seeing as it took 4 years of clustered computing to make the NTLM rainbow tables up to length 12, you're just talking straight out your arse. Yes I agree using salt is the best way to do it, but for the for-seeable future, 32 character or even longer length rainbow tables will not be appearing.

[Salutary7]

Definitely agree with recommendations of salting. Also, if available, using any SHA-2 hash is the more future-proof option.

[+Xinok Subscriber²]

  On 18/07/2013 at 00:56, n_K said:

do u even read though?

So you're going to make a rainbow table of 32 character hashes? Seeing as it took 4 years of clustered computing to make the NTLM rainbow tables up to length 12, you're just talking straight out your arse. Yes I agree using salt is the best way to do it, but for the for-seeable future, 32 character or even longer length rainbow tables will not be appearing.

 

It sounds like you don't understand. This is how you would generate a hash table of MD5 hashes:

 

MD5(password) -> password

 

This is how you would generate a hash table of some chain of hash algorithms:

 

MD5(SHA1(SHA1(MD5(SHA1(MD5(password)))))) -> password

 

The point is to store the final hash, not the intermediary hashes.

 

For simplicities take, lets pretend that you only generated an 8-bit salt, creating 256 possible hashes for each password. To generate a hash table for that, you would need to store every possible salt with each password:

 

MD5(SHA1(SHA1(MD5(SHA1(MD5(password + 00000000)))))) -> password

MD5(SHA1(SHA1(MD5(SHA1(MD5(password + 00000001)))))) -> password

MD5(SHA1(SHA1(MD5(SHA1(MD5(password + 00000010)))))) -> password

MD5(SHA1(SHA1(MD5(SHA1(MD5(password + 00000011)))))) -> password

etc.

 

Now if you generate a 128-bit salt for each password, that means 2^128 possible hashes for each password. That's a huge number of hashes to generate for even a single password, beyond the storage capacity of any system in the world, making it infeasible to generate a hash table or rainbow table.

 

Chaining hash algorithms together is useless as long as it means one hash per password, because you can still map each output hash to the input password that generated it.

[jkenn99]

The true best-practice is to never ever design your own password storage alg. There are libraries out there for every language that are designed by people with much more security experience than you. For PHP, you should take a look at phpass.

[+theblazingangel MVC]

  On 17/07/2013 at 18:57, Tjcrazy said:

I've had this thought for a while - but always figured there was a reasonable solution to it.

 

I run a CMS system that currently hashes its passwords into MD5 and then into SHA1 passwords - or SHA256, depending on the system.

I've always thought why can't you hash passwords a lot, to make them more secure.

 

For example:

<?php
$password = 'ilovepassword1';
$securepass = sha1(md5(md5(sha1(md5(sha1($password))))));

echo $securepass;
?>

Apart from it being totally stupid, and inefficient - why isn't this a 'proper' solution?

 

Surely to crack it, you'd have to crack every layer- in the example above, 6 layers?

 

 

Would love an answer!

 

 

Tim

Your assumption that such hashes have to be cracked one layer at a time MUST be based on an presumption that an attacker will have no knowledge of your algorithm (your choice of which hash functions are used and how they are chained, etc) and will be unable to determine it. In theory and based on this presumption: In terms of an attacker using lookup tables, when they lookup a hash they would find that the result is a string that's not the password itself but instead the hash from the parent hashing function. They would then need to look that up, and so on until they eventually get to the actual password. There is an inefficiency of having to do multiple lookups, but more crucially for this to actually work in practice, in order to actually be able to perform these lookups, the attacker would require lookup tables that cover the hashes of all possible hashes. Such tables cannot exist because they would require a vast amount of disk space to store. Only two chained hash functions could therefore actually suffice here to block lookup attacks.

You cannot rely upon this presumption though. If we assume that an attacker does somehow know the algorithm, then with a lookup table based attack, the attacker can compile lookup tables based on your specific algorithm prior to then attempting an attack on the stolen hashes. Understand that hashing algorithms are designed to be quick, so throwing in a few extra function calls isn't really going to significantly impact an attacker generating them. Furthermore in relation to brute-force/dictionary based attacks against an offline copy of the hashes, the impact of your algorithm in terms of speed of execution is going to be negligible.

Xinox and Asik also raised some excellent additional points earlier.

 

  On 17/07/2013 at 22:04, n_K said:

It's more secure against dictionary attacks and rainbow tables, anyone that tells you otherwise is a grade A ****ing idiot.

It makes it weaker to collisions though.

 

People that go on about 'oh double hashing doesn't improve security' really need to have their ability to talk taken away.

Here's a quick example; If a hashing mechanism outputs a 32 character code from any input, and for A you run it once and B you run it twice:

A can be found in a lookup table expecially if it's less than 13 characters. A can also be found using a dictionary or brute-force attack.

B will not be found in a lookup table because it's 32 characters. If someone can provide even a 16 character rainbow table for MD5 (which is known to be broken) please, do. B will not be found in a dictionary attack _AT ALL_ and is incredibly unlikely to be found via a bruteforce attack UNLESS a collision is found. If a collision is found, they have an alternative string that hashes to give the correct MD5 hash, they can't they crack that string to get the original data used for the first MD5 though.

 

The real problems are, if someone has access to your site and database whereby they can read off all the hashed passwords, they can change any password to login to any account so don't need to crack the password at all, if however they want to get something else like a bank account or email account and the person has used the same password for both sites, that's what they'd be cracking the password for.

Again, you're also simply presuming the attacker does not know the algorithm.

I don't know why you think that chaining is somehow "weaker to collisions". Chaining multiple instances of the same hash function simply transforms one hash to another. Why would the final hash we settle on be weaker in terms of collisions than the first hash. If we chain different hash functions such as md5 and sha1 together, then as Xinox pointed out, entropy and therefore security is reduced to that of the weakest function. Furthermore I believe (and I'm by no means an expert) that 'second preimage' resistance would also be reduced to that of the weakest algorithm, and chaining would make no difference compared to simply using that weakest function on its own.

Also, in regards to the "real problem" as you put it, you can't just blindly state that an attacker with access to a set of password hashes is guaranteed to have write access to the database and is therefore only going to crack a password in order to access accounts on other services. That's crap. An attacker may have simply gained access to a backup of a database not the actual live database itself, or may have found a flaw in a web application through which they have gained read-only access. Also, even if they did have the ability to switch a hash on a user record and therefore login to the account, it doesn't mean that that is the best option for the attacker, it might be more advantageous on certain services to gain access to accounts without the account owners being aware that a malicious entity also has access.

 

  On 17/07/2013 at 22:30, srbeen said:

I'd think devising a way to randomly rehash passwords at random time intervals may be more beneficial in providing security than devising a way to layer or chain things together.

I'm not a crypto expert but I love learning how the DSS, console, and cellular technologies encrypt and secure their 1's and 0's. From watching these industry leaders it seems real-time internet connected scenarios where the wheel (encryption) can be reinvented/changed at will, or several wheels (encryption keys) working in a phase-shift-keying routine seems more successful than layering or chaining encryptions off one another. Key in encryption is not to rely anything on anything else.. I hope I am making sense here. Sony lasted like 4 years just obfuscating static random numbers before the 3.55 signing bug was discovered. Microsoft lasted like 6 before someone figured out their processor favored 'ok' results when you just blanked the key half-way through its check. If theres a will theres a way, just hope by the time its figured out it the encryption is pointless.

Since hashing is non-reversible, the only time you could perform an operation on a user's password would be when they provide it in the login form, so there's a limit to the ability to "randomly" do something with it. Also, "rehashing" passwords would make absolutely zero difference. The same string will always result in the same exact hash every time it goes through the algorithm. I'm sure you knew that though really... What I expect you're really suggesting is the concept of forcing users to change their passwords every so often, which from a security perspective may have a little merit to it, but wouldn't go down well with users. Really it's salting and good choice of hash function that are the crucial things here.

I disagree with your simple notion that the key to encryption is to not rely one thing on another; in cryptography this seems to me to be prevalent. Most if not all crypto relies on the discreet logarithm problem for instance. HTTPS relies on both public-key (asymmetric) and symmetric crypto. I could go on, but I'm just nit-picking :p

 

  On 18/07/2013 at 00:04, Xinok said:

It doesn't matter how many hash functions you chain together, the fact remains that, in the end, the same password will always produce the same hash. Therefore, you can produce a table for it. The most secure way to protect against hash/rainbow table attacks is to include a random salt so that the same password will produce a different hash each and every time. Doing it any other way is only putting the security of your users at risk.

I think you might have missed that what he wrote has to be based on a presumption of the attacker not knowing the algorithm.

 

  On 18/07/2013 at 00:14, giantpotato said:

Genius, so the solution to security is to append 1111111111111111 to all passwords before hashing. Since the password is now 32 characters it won't be found in a rainbow table :/

You've completely misunderstood what he was talking about.

 

  On 18/07/2013 at 00:31, wrack said:

Hashing is multiple times can work most of the time but using salt is a more common practice (in my experience). With that you can use different techniques to use the salt (https://www.neowin.net/forum/topic/1163508-web-server-salt-storage/)

 

Some more good info http://crackstation.net/hashing-security.htm

I made some comments in the thread you linked to relating to your "different techniques to use the salt"!

 

  On 18/07/2013 at 00:56, n_K said:

do u even read though?

So you're going to make a rainbow table of 32 character hashes? Seeing as it took 4 years of clustered computing to make the NTLM rainbow tables up to length 12, you're just talking straight out your arse. Yes I agree using salt is the best way to do it, but for the for-seeable future, 32 character or even longer length rainbow tables will not be appearing.

Lots of misunderstanding going on here, you and Xinox are arguing from two completely different perspectives!

[The_Decryptor Veteran]

I don't see the multiple hashes making it less secure, but it doesn't really make it more secure either since while you're running multiple iterations of the hash function, they're "fast hashes", so you're not increasing the cost by a large extent. Something like bcrypt follows a similar design (where it iterates over the input multiple times), but it does it to increase the computational complexity of the entire hash computation (That is, it's designed to take a certain amount of time per hash, not a certain amount of iterations)

Regarding salts, instead of using just one salt for all accounts (I've seen that suggested/used before), use a random salt per user (like their username). Even without something like bcrypt that would defeat rainbow tables in the case where the attacker is trying multiple accounts (While if the attacker is just targeting one account, like an admin, it won't help at all, that's where bcrypt comes in)

[n_K]

So for anyone that says that double or triple or n+ hashing doesn't make it secure, put your money where your mouth is;

342a404105b959b98bf4c52af0732e6b

MD5 hash of an MD5 hash of a simple password.

And if in 7 days you can't produce either the original MD5 nor the original text, we'll just assume like previously predicted; you're wrong.

[Phouchg]

How about you take your childish contests elsewhere and just understand that one plaintext produces one hash no matter how many times you hash it. Or one shirt stays one shirt now matter how many times you wash it.

 

I take a dictionary, I hash every entry from aaa to zzz (for example) of it:

MD5('aaa') = 47bce5c74f589f4867dbd57e9ca9f808

MD5('zzz') = f3abb86bd34cf4d52698f14c0da1dc60

 

Then I hash every result once more, because you've just told me that's what you did (or I might have found it myself because I'd got read access to your source code):

MD5('47bce5c74f589f4867dbd57e9ca9f808') = d4fbb7d8d5603db43ac2094f5955787c

MD5('f3abb86bd34cf4d52698f14c0da1dc60') = 689505e20843a46d0f9afaaf837dcb2b

 

And I come to know that:

MD5(MD5('aaa')) = d4fbb7d8d5603db43ac2094f5955787c

 

It works that way, not backwards. It's not even crypto 101, it's elementary school. Seriously, are you trolling us all?

[n_K]

  On 18/07/2013 at 12:18, Phouchg said:

How about you take your childish contests elsewhere and just understand that one plaintext produces one hash no matter how many times you hash it. Or one shirt stays one shirt now matter how many times you wash it.

 

I take a dictionary, I hash every entry from aaa to zzz (for example) of it:

MD5('aaa') = 47bce5c74f589f4867dbd57e9ca9f808

MD5('zzz') = f3abb86bd34cf4d52698f14c0da1dc60

 

Then I hash every result once more, because you've just told me that's what you did (or I might have found it myself because I'd got read access to your source code):

MD5('47bce5c74f589f4867dbd57e9ca9f808') = d4fbb7d8d5603db43ac2094f5955787c

MD5('f3abb86bd34cf4d52698f14c0da1dc60') = 689505e20843a46d0f9afaaf837dcb2b

 

And I come to know that:

MD5(MD5('aaa')) = d4fbb7d8d5603db43ac2094f5955787c

 

It works that way, not backwards. It's not even crypto 101, it's elementary school. Seriously, are you trolling us all?

Why don't you learn to ****ing read?

Using a salt means the salt is known, include salt in the cracking system.

Salts do not slow down cracking or stop dictionary/bruteforce attacks from working, all they do is stop rainbow tables.

An md5 hash of an md5 hash also stops rainbow table attacks because THERE ARE NO RAINBOW TABLES OF THE MD5 HASHES, WILL YOU PLEASE RE-READ UNTIL YOU FINALLY UNDERSTAND?

tldr; MD5'ing an MD5 stops rainbow table attacks like salting does, neither method stops or slows down dictionary/bruteforce attacks.

[Phouchg]

Sure, with certain certainty, no one has computed such rainbow tables for me, but it's increasingly possible to do and when it's done, your method is fscked, which is unacceptable. I don't even need rainbow tables of MD5 hashes. I don't care of intermediary MD5 values just as I don't care of the number of rounds MD5 internally does. I mash the password any number of times and feed only the final value to the reduction function.

 

Instead we settle for the proven best method - proper salt, which instead makes rainbow tables *not even worth considering* rather than a increasingly feasible option.

 

Perhaps it'd also help if you'd turn down the rage dial a little.

[Mike]

  On 18/07/2013 at 12:38, n_K said:

An md5 hash of an md5 hash also stops rainbow table attacks because THERE ARE NO RAINBOW TABLES OF THE MD5 HASHES, WILL YOU PLEASE RE-READ UNTIL YOU FINALLY UNDERSTAND?

 

You do realise that the md5 hashes have a small number of characters and a fixed length. The original MD5 (the hash of the password) is trivial to find because you know its exact length and what characters are in it!

[threetonesun]

  On 18/07/2013 at 13:36, Mike said:

You do realise that the md5 hashes have a small number of characters and a fixed length. The original MD5 (the hash of the password) is trivial to find because you know its exact length and what characters are in it!

 

Right, sha1(md5(password)) is... well, it's silly.

 

Adding salt prevents the generation of rainbow tables, adding iterations prevents (or at least, makes less feasible) brute force attacks. Both of these ideas have been used in modern encryption algorithms, there's not a good reason to try and cobble together something using md5 hashes.

 

The real concern is, if someone gets access to your entire database, what information to they now have? That's what often gets overlooked by sites.