Bugtraq mailing list archives
Re: Messenger/Hotmail passwords at risk
From: Ishikawa <ishikawa () yk rim or jp>
Date: Fri, 13 Jul 2001 01:50:12 +0900
(I sm re-sending this afer minor editing since I am not sure if this went out or has been accepted/rejected after I switched my subscription e-mail address.)
From the discussion, I think some readers missed
the point of the original poster. Using "||" as string concatination operator, it seems that MD5 (given-long-string || short-password-candidate ) can now be brute forced to produce a given/observed hash value returned in challenge/response using fast and inexpensive CPU in a reasonable time. (Provided that the given-long-string and short-password-candiate is not so long after all.) Now, however, why don't we use the reversed order for the two strings concatenated in the md5 calculation? MD5 ( short-passwd || given-long-string) I take that the original poster's brute force program saves the intermediate state of md5 calculation up to the last 16 words block where the block in which the short-password is embedded. (The password may span across block boundary, but the gist of argument should hold.) By using such saved state, the brute force calculation of MD5 (given-long-string || short-passwd-candidate ) for each short-passwd-candiate can be done rather fast since, by using the saved state, only the update of the result array using the last round of the calculation step (based on the block in which the password candidate is placed) is now necessary. We can re-calculate for each candidate short password string repeatedly in this manner. (This must be the gist of the original poster's brute force program.) However, using `short-passwd || given-long-string' makes such brute-forcing rather difficult (comparatively speaking). This is because now md5 calculation of the full steps over all the blocks spanning the total string must now be performed for each password candidate. (We can't save the intermediate state as before to speed up brute force attempts.) Is this analysis correct? If so, we should switch to the hash ( possibly-short-user-response || long-seed-string ) scheme where hash (long-seed-string || possibly-short-user-response) is currently used (hash is md5 for example). Many challenge/response seems to use the former string. However, we should use rather long string and long password as well.
Current thread:
- Messenger/Hotmail passwords at risk gregory duchemin (Jul 09)
- Re: Messenger/Hotmail passwords at risk aleph1 (Jul 09)
- Re: Messenger/Hotmail passwords at risk Peter van Dijk (Jul 09)
- Re: Messenger/Hotmail passwords at risk Jeffrey W. Baker (Jul 09)
- Re: Messenger/Hotmail passwords at risk Pavel Kankovsky (Jul 10)
- Re: Messenger/Hotmail passwords at risk Gaurav Agarwal (Jul 15)
- Re: Messenger/Hotmail passwords at risk Martin Macok (Jul 16)
- Re: Messenger/Hotmail passwords at risk Pavel Kankovsky (Jul 10)
- <Possible follow-ups>
- Re: Messenger/Hotmail passwords at risk Ishikawa (Jul 15)
- Re: Messenger/Hotmail passwords at risk gregory duchemin (Jul 16)
- RE: Messenger/Hotmail passwords at risk Michael Wojcik (Jul 16)
- Re: Messenger/Hotmail passwords at risk Mark (Jul 16)