[2706] in bugtraq
Re: Not so much a bug as a warning of new brute force attack
daemon@ATHENA.MIT.EDU (der Mouse)
Sun Jun 9 15:07:40 1996
Date: Sun, 9 Jun 1996 14:03:20 -0400
Reply-To: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
>> I would suspect that your average [black-hat] wouldn't know what to
>> do if he found "$1$rEU5lGMq$x5g.f98lqkUfQ8rn89foQl" in the encrypted
>> password field.
> Yeah, but if it becomes popular, there's not much stopping one of
> them with a clue from adding an MD5/rsalib call right after the
> crypt() in crack, et al.
Except that once you drop compatability with the past, you can do
things like run the number of rounds up high enough that, once again, a
single crypt() call takes a significant fraction of a cpu-second...at
which point dictionary cracking becomes infeasible. (Back when
DES-based crypt() was designed, a crypt call _did_ take a significant
fraction of a cpu-second. It's just 20 years (25? 15? no matter) later
now, and cpus are faster.
I don't know what code FreeBSD is using, but I don't see a round count
in the above hashed password. My NetBSD libcrypt has not only a format
value in a hashed password, but also a round count. I haven't yet
tuned the default, but you can certainly run it up until it takes .1
cpu-seconds on a P120 to do a single crypt(), at which point even if
they _do_ have a clue and _do_ modify crack, it's hopeless for another
N years...and you can always just goose the round count again when cpu
speeds catch up.
der Mouse
mouse@collatz.mcrcim.mcgill.edu
