Re: Not so much a bug as a warning of new brute force attack

[mouse () Collatz McRCIM McGill EDU (der Mouse)]

> > 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