You're not using MD5 anymore, are you?
Moderator: General Moderators
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
After a certain level of abstract discussion about crypto, you have to get into the realm of true math.anjanesh wrote:How is md5(md5($str)) less secure ?
In general terms, when you try to attack a hash, you are looking for flaws. Flaws are areas where the expected strength isn't accurate in reality.
A hash relies on entropy. Entropy is itself pretty tricky, but it can be simply defined as how much randomness there is in a signal or random event.
By using a predictable function not once, but twice, you decrease the entropy - its more predictable.
By being more predictable, you give a larger window to an attacker.
The "exception" that seems to argue otherwise is triple-DES. But in fact, in the second round of 3des, the equation CHANGES to ensure that more entropy is added. Unfortunately, due to the construction of the formulas for MD5, no similar trick is possible.
The math is extremely high-level, and I won't pretend to be the expert that can describe it all. Its an amazing field with a depth that is honestly rather frightening. You could spend your entire life learning only crypto, and still have more to learn. Its incredible.
But to sum up, you are reducing the randomness, and the randomness is what makes it strong. double-md5 is no stronger than single md5.
A more interesting issue, is that proper use of salts can improve the security of md5 quite a bit (making rainbow/table-lookup attacks less dangerous), but they are meaningless against a bruteforce attack. Doesn't change the fact that it can help in some situations.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
You are wrong, and let me count the ways..Ambush Commander wrote:Of course, if your MySQL server is safe, they'll never get the hashes...
Cleartext interception
Client-side compromise
WebServer compromise (NOT SQL-server!)
Network sniffing (not neccesarily cleartext)
All of which have nothing to do with the SQL server being safe, and (can) allow an attacker access to the hashes.
Assume everything is insecure and under attack, and move forward from there. Once you do, you'll be much closer to reality.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Assuming that we're arguing why you should move to a better hash, Cleartext interception and Client-side compromise have the same power over a SHA256 as they do on MD1 (just for arguments sake) because they target the cleartext. And if the client is compromised, well, not much is safe then.
Although, I do admit, never is a bit of a strong word.
Although, I do admit, never is a bit of a strong word.
We're not arguing about why. Why was established at the beginning of the thread. I was arguing why your statement "Of course, if your MySQL server is safe, they'll never get the hashes..." was completely inaccurate and not a reason to avoid upgrading your hash.Ambush Commander wrote:Assuming that we're arguing why you should move to a better hash, Cleartext interception and Client-side compromise have the same power over a SHA256 as they do on MD1 (just for arguments sake) because they target the cleartext. And if the client is compromised, well, not much is safe then.
Although, I do admit, never is a bit of a strong word.
But we agree on the rest - three of those issues affect both weak and strong hashes. Of course, WebServer compromise isn't the same for both. Neither is a brute force attempt at the application layer with minimal logging. Neither..
You get the idea. There are lots of scenarios that DO give greater value to a stronger hash, although thats not the point I was getting at.
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
Continuing the post of Roja..
as pointed out simply having a secure hash in your database does not by any means they are secure. They can be intercepted at several different points throughout transmission, which is why a secure connection greatly benefits security. On the other hand just because your connection is secure (SSL) does not mean you should ignore other precautions such as hashing. When combined, then you stand a chance against the evil doo'ers of the internet
as pointed out simply having a secure hash in your database does not by any means they are secure. They can be intercepted at several different points throughout transmission, which is why a secure connection greatly benefits security. On the other hand just because your connection is secure (SSL) does not mean you should ignore other precautions such as hashing. When combined, then you stand a chance against the evil doo'ers of the internet
So, doing "md5(md5($var));" isn't a good idea, but how about something like this?
I believe stuff like that is done quite often; would adding other 'random' (the substr() and strlen()) things to the hash make it more secure?
Code: Select all
md5(md5(substr($var, 0, 16)) . strlen($var));