Jump to content



Photo

Why Can't You Hash a Password Multiple Times

password hashing md5 multiple sha1 sha256 php

  • Please log in to reply
56 replies to this topic

#1 Tjcrazy

Tjcrazy

    Your Average Neowin Guy.

  • Joined: 02-May 09
  • Location: The Cotswolds, United Kingdom

Posted 17 July 2013 - 18:57

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




#2 night_stalker_z

night_stalker_z

    Neowinian

  • Joined: 16-August 07
  • Location: Hove, UK

Posted 17 July 2013 - 19:04

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...

#3 Joe User

Joe User

    Lazy Joe's

  • Tech Issues Solved: 1
  • Joined: 29-May 07
  • Location: Somewhere in the US
  • OS: Windows 8.1 Update 1
  • Phone: Nexus 5

Posted 17 July 2013 - 19:06

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

 

http://crackstation....ng-security.htm



#4 threetonesun

threetonesun

    Neowinian Senior

  • Tech Issues Solved: 1
  • Joined: 26-February 02

Posted 17 July 2013 - 20:09

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.



#5 +Xinok

Xinok

    Resident Reresident

  • Joined: 28-May 04
  • Location: Shikaka
  • OS: Windows 7 x64
  • Phone: Galaxy S3 (Wicked)

Posted 17 July 2013 - 21:43

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.



#6 Andre S.

Andre S.

    Asik

  • Tech Issues Solved: 10
  • Joined: 26-October 05

Posted 17 July 2013 - 21:49

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).



#7 n_K

n_K

    Neowinian Senior

  • Tech Issues Solved: 3
  • Joined: 19-March 06
  • Location: here.
  • OS: FreeDOS
  • Phone: Nokia 3315

Posted 17 July 2013 - 22:04

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.



#8 srbeen

srbeen

    Neowinian

  • Joined: 30-November 11

Posted 17 July 2013 - 22:30

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.



#9 +Phouchg

Phouchg

    Random Oracle

  • Tech Issues Solved: 9
  • Joined: 28-March 11
  • Location: Tannhäuser Gate
  • OS: V'Ger 6.1.7601 x64
  • Phone: SQNY D5503

Posted 17 July 2013 - 22:31

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.



#10 n_K

n_K

    Neowinian Senior

  • Tech Issues Solved: 3
  • Joined: 19-March 06
  • Location: here.
  • OS: FreeDOS
  • Phone: Nokia 3315

Posted 17 July 2013 - 22:39

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.



#11 +Xinok

Xinok

    Resident Reresident

  • Joined: 28-May 04
  • Location: Shikaka
  • OS: Windows 7 x64
  • Phone: Galaxy S3 (Wicked)

Posted 18 July 2013 - 00:04

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.



#12 giantpotato

giantpotato

    Neowinian Senior

  • Joined: 27-January 04
  • Location: Montreal, Canada

Posted 18 July 2013 - 00:14

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 :/ 



#13 wrack

wrack

    Wireless Robotic Android Calibrated for Killing

  • Joined: 09-December 06
  • Location: Melbourne, Australia

Posted 18 July 2013 - 00:31

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 (http://www.neowin.ne...r-salt-storage/)

 

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



#14 n_K

n_K

    Neowinian Senior

  • Tech Issues Solved: 3
  • Joined: 19-March 06
  • Location: here.
  • OS: FreeDOS
  • Phone: Nokia 3315

Posted 18 July 2013 - 00:56

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.

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.



#15 Salutary7

Salutary7

    Neowinian

  • Joined: 05-March 12

Posted 18 July 2013 - 01:04

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