APOP passwords at risk

["gregory duchemin" <c3rb3r () hotmail com>]

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.697170952 () dbc mtview ca us>tanstaaf
which produces a digest value of c4c9334bac560ecc979e58001b3e22fb

giving, while in the authorization state:

S: +OK POP3 server ready <1896.697170952 () dbc mtview ca us>
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.