Re: password crypt consideration: simple question

[Marcus Watts <mdw_(_at_)_umich_(_dot_)_edu>]

Gustavo Vieira =?iso-8859-1?Q?Gon=E7alves?= Coelho Rios <gustavo_(_dot_)_rios_(_at_)_terra_(_dot_)_com_(_dot_)_br> writes:
> As far as i know, the only simetrical cipher obsd uses for passwords is
> blowfish, is that right? Would it be a bad ideia to have RC5 too?

Well, RC5 probably has license, trademark, and/or patent issues.  Also
I don't think RC5 gets you anything much over blowfish.

If you wanted to use stronger symmetric encryption, then the next
logical step would be one of the 128-bit blocksize algorithm, which
probably means one of the AES contenders.  Not RC6 because it's got the
same potential issues as RC5.  Rijndael, serpent, twofish, maybe
cast-256.  With any of these, you'd have to use a much larger iteration
count to get the "same" CPU overhead as blowfish.  Serpent is probably
your best bet; it's more conservatively designed, so slightly slower.
Rijndael is likely to be most widely deployed; if you want to
popularize your hash and use it elsewhere, that would be your best
bet.

But why the attraction to using symmetric encryption?  What you're
really looking for here is a one-way password hash; as used for Unix
authentication there's no value to reversibility.

There are plenty of one-way hashes that are better at taking in and
outputing a wide swath of data, so they should be more attractive.  One
useful advantage is there's no reason to have any particular password
length limit (blowfish has an obscure 72 character limit.)  The old md5
password hash that's in openbsd is relatively ad-hoc, but a
recognizable ancestor of pkcs#5 pbkdf2.  Rather than using md5, you
could use sha-1, sha-256, or tiger.  Pbkdf2 includes a variable
iteration count, so mostly plugging it into openbsd would involve
base64 & such.  Blowfish's iteration count is specified log base 2;
that's a useful idea to preserve.

Even with the current blowfish logic, it's probably worth remembering
that computers have long since outstripped people's ability to remember
passwords.  Blowfish saves 168 bits of hash, but the average person
(depending on your reference) can't remember passwords containing more
than 32 or maybe 40 bits of entropy.  More than that, and you start
seeing passwords scribbled on paper and the like.  So, using rijndael
or tiger isn't *really* going to improve your security.  Using a larger
iteration count from blowfish will probably give you all the security
you really need, if you just want a stronger password hash.  Moore's
law says you should add 1 to the iteration count every 18 months, but I
don't know anyone brave enough to put this in cron.  (Does this mean it
ought to get bumped every 3 openbsd releases?)

I've seen one estimate that says passwords should take about 1 second
to compute, and that at this rate, a cracker should be able to
brute-force most passwords in under 90 days.  Personally I tend to
think this is mostly convenient justification that most users get
impatient if it takes them more than one second to log in - Bell labs
used 1/2 second as their delay in the original Morris & Thompson Unix
password security paper.  But if you are concerned, you ought
to expire passwords after 30 days.

				-Marcus Watts