Posted: Thu Dec 08, 2005 8:34 am
If someone wanted to hack one of my sites, and they had $250k for the purpose, then a bribe would work far better than buying a supercomputer.
A community of PHP developers offering assistance, advice, discussion, and friendship.
http://forums.devnetwork.net/
umm... How much will you takeonion2k wrote:If someone wanted to hack one of my sites, and they had $250k for the purpose, then a bribe would work far better than buying a supercomputer.
This is a little tricky.shiflett wrote:You seem to be implying that preimage attacks are possible. Do you have any proof?Roja wrote:Security researchers were able to create a specific collision, on demand, in a short period of time.
Xiaoyun Wang's discoveries are a big deal, but let's not get carried away.
On the contrary, my interpretation of the findings suggest it is. Encouraging a programmer to use md5 as a security control - when we know it can be spoofed in mere hours on a standard PC - is definitely bad practice.shiflett wrote:MD5 isn't a bad word.
I'd say it is, yes. In the case of session identifiers, the risk is somewhat lower, because the time it takes to produce a duplicate is longer than the session is likely to be useful for. In addition, the session most likely won't have nearly as much value as a specific protected/monitored file (as the original poster is asking about).shiflett wrote:(PHP's session mechanism uses MD5 to generate session identifiers. Is this insecure?)
Right, so it doesn't apply here. If an attacker has access to the original file as well as its hash, then the game's over, regardless of algorithm.Roja wrote:However, that paper shows a "poor mans" preimage - with a known input and output, using the known behaviors of the Merkle-Damgard construction, you can massage a new input to match the output of the original.
Or put another way, you can create a different message with the same hash result - but it isn't truly arbitrary, you have to work backwards to get it.
Code: Select all
$salt = 'SHIFLETT';
$hash = md5($_POST['password'] . $salt);Code: Select all
$salt = 'SHIFLETT';
$hash = md5($salt . md5($_POST['password'] . $salt));Let's assume that a preimage attack on MD5 is successful within 5 seconds. How would this weaken PHP's session mechanism?Roja wrote:I'd say it is, yes. In the case of session identifiers, the risk is somewhat lower, because the time it takes to produce a duplicate is longer than the session is likely to be useful for.
Yes, there is a need, because of the problems you've brought up. The reason for this need is that PHP can't predict why you need to hash something. Is it to normalize the format of random data, verify file integrity, or hash a password? For some uses, MD5 is no longer a good choice. This doesn't apply to every use, however, which is why I mentioned PHP's session identifier generation.Roja wrote:Related is the fact that the php internals team recently discussed a robust hash and hash_file improvement for PHP6, which adds native (read: no module needed) encryption methods far beyond the current md5/sha1 choices. Clearly, there is a need, and thankfully, professionals like Ilia Alshanetsky are championing better encryption on the PHP internals team.
No, it does.shiflett wrote:Right, so it doesn't apply here.
Not at all.shiflett wrote:If an attacker has access to the original file as well as its hash, then the game's over, regardless of algorithm.
Its not forward thinking. Its the exact issue that was discussed in the paper - generating a second (hostile) input with the same hash as a known good (non-hostile) input. Thats a collision.shiflett wrote:These findings are substantial (and impressive), and we're likely to see preimage attacks emerge eventually, but we're not there yet. I appreciate the need for forward-thinking, but it's also important to consider how weaknesses in MD5 affect each use.
If all you are checking is the checksum, and you aren't using a salt, *yes*. In the case of checking file integrity, you store the checksum - not the file contents. So you check a known good md5 (checksum) against the checksum of a questionable file. If they match, you've been fooled. Thats what the papers show is already possible in a matter of hours.shiflett wrote:Let's also assume that using only this information, you're able to come up with a string (small enough to pass as a password) that generates the same MD5. Will submitting this string as the password necessarily grant you access to the chris account?
Notice that now you are on a different topic. Now, instead of checking a checksum to ensure a files contents are intact, you are checking the checksum of a password to validate identity. Two different processes. Further, you've used salt to ensure the checksum varies - something most file integrity test suites (like tripwire) do not do.shiflett wrote: Imagine that the MD5 is generated as follows:
That's a pretty slight modification, but it still renders the attack useless. Stronger techniques would be even harder to break:Code: Select all
$salt = 'SHIFLETT'; $hash = md5($_POST['password'] . $salt);
In the case of session identifiers, a preimage attack makes no subtantial difference. A preimage attack only helps if you want to change *the content*. Session identifiers don't hash a content, they are simply a unique identifier.shiflett wrote:Let's assume that a preimage attack on MD5 is successful within 5 seconds. How would this weaken PHP's session mechanism?Roja wrote:I'd say it is, yes. In the case of session identifiers, the risk is somewhat lower, because the time it takes to produce a duplicate is longer than the session is likely to be useful for.
One, I'm not here to take a test. You challenged my statement, and I defended it.shiflett wrote:(I'm trying to challenge you to look at not only the significance of recent research, but also the practical implications of it.)
This much we do agree on: There are some places where the damage from the attacks against MD5 won't be substantial.shiflett wrote:Yes, there is a need, because of the problems you've brought up. The reason for this need is that PHP can't predict why you need to hash something. Is it to normalize the format of random data, verify file integrity, or hash a password? For some uses, MD5 is no longer a good choice. This doesn't apply to every use, however, which is why I mentioned PHP's session identifier generation.
I'm not bashing it. I'm sharing relevant facts from researchers who have proven it. You want proof, then read the papers and the links I included in the last post. They show three different examples of actual documents that YOU can run md5 against, and see the same hash, with different inputs.shiznatix wrote:Roja please, if it is really that easy to spoof md5 then please prove it to me. You seam to have the know how, setup a test site and hack it with all these holes in the md5 hash. I wan't to see it done by someone who is bashing it so much.
External storage of the tripwire database is considered a best practice. If you're interested and want to learn more, I think the Linux Security Cookbook details how this approach changes your typical workflow.Roja wrote:On a linux box, with a program like Tripwire, which checks checksums (which is what the OP wants), the game is definitely not over. The attacker has the known input - lets say the bash binary. The attacker can get access to *view* (not change) the hash - the tripwire store is on a CD.
I think this depends upon how you define safe. In fact, you and I are each arguing both sides here - in the overall discussion at hand, I'm suggesting that not knowing the exact method used to create the MD5 hash presents a substantial obstacle to an attacker. You're noting that here. :-)Roja wrote:If the hash algorithm isn't compromised, its still safe.
The paper you're referring to does not describe a preimage attack, and you again seem to be suggesting that it does.Roja wrote:Its not forward thinking. Its the exact issue that was discussed in the paper - generating a second (hostile) input with the same hash as a known good (non-hostile) input. Thats a collision.
Now you're having to qualify your statement, so I think my point has been made. :-)Roja wrote:If all you are checking is the checksum, and you aren't using a salt, *yes*.
Nope, I just generated an MD5 hash.Roja wrote:Notice that now you are on a different topic.
Can you clarify what you mean? It's the exact same process - comparing expected output (with known input) with actual output.Roja wrote:Now, instead of checking a checksum to ensure a files contents are intact, you are checking the checksum of a password to validate identity. Two different processes.
I unfairly painted you into a corner here, but you're wrong, and this was my original point. (I didn't expect for you to try to defend this - I just meant to make a point.)Roja wrote:The danger is in a collision. If I can generate a collision - a duplicate session_id - in a short period of time (5 seconds works), then I can become another user.
I'm just here to help people, including those who want to challenge me. :-)Roja wrote:One, I'm not here to take a test.
Primarily because I'm being pragmatic (and taking the current problem into consideration, since this isn't a generic hashing discussion).Roja wrote:Why, as a security researcher, are you advocating the use of a broken algorithm in the specific scenario where it has been shown to be weak, when there are suitable alternatives?