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.

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.

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.

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

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.

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.

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.

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.

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.

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

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

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.