Andrew Howell writes ("Re: md5sum passwords"):
> Daniel Quinlan writes:
> > I think switching would probably be a decent idea, although it is not
> > of earth-shattering importance to me. I'm also concerned about doing
> > Debian doing it alone, instead of with the cooperation of the rest of
> > the Linux community.
>
> Though it would be nice if the whole community switched I don't think
> it's that great a deal whether they do or not, us using MD5 and others
> using DES shouldn't lead to any incompatibilties or problems as far
> as I can see.
Don't many programs have built in limits like 8 on the length of a
password, and 13 or whatever it is on the length of an encrypted
password ? I don't see the point in switching.
> > I am more interested in longer user names and longer password. I'm
> > disgusted with being limited to eight characters.
>
> Yes, MD5 obviously makes the system that much more secure from attempts
> at using crack on a passwd file. MD5 being much slower than DES and also
> just the fact that you can't count on the password being 8 characters long
> anymore would make it a quite a more difficult process.
It's very hard to get people to remember a decently-long secret. For
this reason longer passwords aren't in general going to make for
better security.
What we should do instead, IMO, is to keep a secret cookie in a
read-protected file and use that as part of the data when hashing the
password (we can use MD5 or DES or SHA or whatever, though if we use
MD5 we'll have to truncate the result).
Programs that can read the file would just use it; programs that can't
would consult a system daemon to do the crypt() for them.
The effect of this would be that the cracker would have to use your
daemon to do all the crypts - which makes cracking infeasible - and
that *no programs would even need to be recompiled*.
We have 13 characters available, and 2 of these are known to be the
salt. Each character yields 6 bits with a sensible encoding, so we
have 12 bits of salt and 66 bits available for the encrypted
passwords.
The salt is less important if we constrain the potential cracker to
use our daemon, so we can keep some of it (4 bits perhaps?) as an
index number into a smallish table of secrets, so that we can change
the secret without having to have all the users change their passwords
at once.
Daniel Quinlan writes ("Re: md5sum passwords"):
> I am more interested in longer user names and longer password. I'm
> disgusted with being limited to eight characters.
Longer user names is pretty much a lost cause at this late stage, I
think. Feel free to try, but expect a lot of problems. Longer
passwords are difficult too, and even 8 lowercase alphanumerics are a
bit over 40 bits of entropy: this is fine to prevent guessing if the
attacker can't run an off-line search. If you use case and
punctuation too you can get around 50 bits, which is pretty good for a
login application.
Getting people to remember even 40 bits worth of password is the real
problem; we should be concentrating on ways to get good use out of
even 20 or 10 or less bits of randomness - and the way to do this is
to ensure that attempts at password searching have to go through
something you control.
> A little reading on using MD5 instead of DES turned up a FreeBSD web
> page on the topic.
>
> http://www.freebsd.org/handbook/handbook68.html
The FreeBSD web page seems to say to me that they made the decision to
use MD5 instead of crypt because of the export control issues. It
seems that the Linux community in general has taken the view that
since it is no more practical to use crypt than MD5 for
confidentiality it is silly to replace one with the other (the US
government view is - broadly speaking - that integrity and
authentication is OK whereas confidentiality isn't, which is very
silly when you try to apply it to algorithms: there's a standard way
to turn a hash function into a block cipher).
I think we should continue to provide a crypt()-like interface, and I
think my plan above is a way to significantly improve our security -
bringing it up to the level of systems with shadow passwords - without
the pain of recompiling every binary.
(The scheme also allows users to check their own and each others'
passwords, so that screenlocker programs &c don't need to be trusted
by the sysadmins. This feature could be disabled simply by not
running the crypting daemon.)
If people think this is a sufficiently good idea I might even be
persuaded to implement it, just so I can write a paper about it :-).
