On Tue, Jul 04, 2006 at 12:04:34AM -0400, Chet Uber wrote:
> >>I can't resist pointing out that this is an AWFUL policy. You
> >>will be
> >>remembering peoples passwords, a history of them, which are
> >>very likely to be used on other systems. Thats really bad. I wonder
> >>(at least in the USA) what would happen to your company if that
> >>data was ever stolen?
> >
> >Ahhh, .. that's what hash's are for; easily recreatable given
> >duplicate
> >input strings, but creating the input string FROM the hash is just
> >about
> >impossible [lacking near infinate resources].
>
> Not to bicker, but the resources needed to use a database of all
> possible passwords even with alphanumerics and salted is very finite
> -- albeit large. If we are talking about login() that is. Our company
> maintains one for 8 characters and while requiring a large database
> still makes cracking passwords of finding collisions a trivial chore
> for 8 character passwords. We are currently working on one that will
> handle 13 character strings and hope to have it running by the end of
> the year.
>
> Just don't want people to think that they are safe as is not an NP-
> complete problem. It is an NP-hard problem however.
While all this complexity theory is really interesting, this is system
administration. From a .sig: 'computer science is about lofty goals and
algorithmic optimization; sysadminning is about cleaning up the fscking
mess that results'.
In theory, creating a rainbow table for the Blowfish hash as currently
used is not very feasible, and by the times it becomes feasible, adding
a couple of rounds is a very good defense.
In practice, however, a good list of - say - 10.000 commonly used
passwords is very, very likely to yield at least one hit across the
complete population of users. I've heard it say that 1000 is likely to
be enough. (Anyone who disagrees should first find another reason why we
continue to see ssh probes.)
All in all, no, storing hashes is not a good idea, *particularly* if the
users are wont to choose bad passwords.
Joachim
