hello >This is the exact same thing APOP does - server sends a string, client >appends password to string, takes MD5 hash and sends back. If your >cracker is what you say it is (I haven't checked) then APOP should be >just as vulnerable. > >Greetz, Peter yep, looking briefly at the rfc 1939, i found that: RFC quote ========= In this example, the shared secret is the string `tan-staaf'. Hence, the MD5 algorithm is applied to the string <1896.697170952at_private>tanstaaf which produces a digest value of c4c9334bac560ecc979e58001b3e22fb giving, while in the authorization state: S: +OK POP3 server ready <1896.697170952at_private> C: APOP mrose c4c9334bac560ecc979e58001b3e22fb S: +OK maildrop has 1 message (369 octets) ========= the same trick, a malicious user has to sniff a complete negociation before bruteforcing the challenge response and may retrieve the original password. note that the string in the example above fit the range of chars needed by mdcrack. (up to 56) Obviously, the writer known the fragility of such protocols relying on the key length (comparing to the fast growing of computers speed) he added this few lines at the end. RFC quote ========= Note that as the length of the shared secret increases, so does the difficulty of deriving it. As such, shared secrets should be long strings (considerably longer than the 8-character example shown below). ========= So we have the same problem here. Why not just use MD5 as BSD already does in crypt(), wasting a lot of cpu time to generate one hash and thus complicating the bruteforce process ? Relying upon users safe behavior and knowledge is far more dangerous. cheers, Gregory _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
This archive was generated by hypermail 2b30 : Tue Jul 10 2001 - 06:51:59 PDT