mailing list archives
Re: Windows NT rantings from the L0pht
From: daw () CS BERKELEY EDU (David Wagner)
Date: Tue, 29 Jul 1997 13:48:36 -0700
Thanks for the very thorough explanation of the attacks on the
LanMan hash (and associated challenge/response protocol).
Actually, there are even slightly stronger attacks out there,
waiting for someone to implement.
Observation 1: Even though the challenge varies, you can use a
pre-computed dictionary to recover the last 7 characters of the
password from the LanMan challenge/response more efficiently.
Observation 2: >7 byte passwords are likely to be even less
secure than <8 byte passwords. You learn the last 7 bytes quickly,
and then use them to extend backwards to learn the first 7 bytes.
(If the last 7 bytes of the password are "achable", then the
password is probably "inapproachable".)
You can recover the last two bytes of the 16-byte password hash
trivially from the LanMan challenge/response pair. So if you've
pre-computed a bunch of possible password hashes, you can eliminate
all but 1/2^16 of the wrong ones; then another 2^8 work for each
remaining possibility (guessing the 8th byte of the 16-byte password
hash) lets you verify correctness. If you've got N pre-computed
password hashes (which requires N work up front), then N/2^8 DES
computations gives you the last 7 bytes of the password (assuming
that the password is in your wordlist).
This can be optimized even further, by noting that you can greatly
reduce the number of possibilities for the second 7-byte half of
the password. The LanMan challenge/response protocol lets you
isolate the last 7 bytes of the password and do a dictionary
search on them alone. But most people use passwords derived
from dictionary words, and that greatly reduces the number of
possibilities for the second 7-byte half. My small wordlist has
45000 words, but only 3000 unique 7-byte suffixes; this is a savings
of a factor of 15.
Now you can use the last half of the password to narrow down the
number of possibilities for the first half. Also, you can apply
a similar precomputation trick to the first half as well.
A technical analysis I did over a year ago, listing these concerns
in more cryptographic detail, can be found at