password security, especially shadow passwords

password security, especially shadow passwords

Post by Dan Strombe » Wed, 13 May 1992 09:51:18



I noticed a lot of things about passwords going by tonight, (haven't
been keeping up on the group much), and want to respond to some of
what's being said.

I ported the shadow password package to linux, primarily for my
own use.  When I uploaded the package the first time, it was split
into two pieces - binaries and sources.  Sadly, no doc was put in
the binaries archive - it went in with the sources instead.  I
don't mean to point any fingers at anyone, as far as I'm concerned
it just *happened* (If you're reading, don't feel bad at all, I know
you were very pressed for time, and any time you contribute to linux
is best considered a gift)

The shadow-bin and shadow-src that are in the archives, are *obsolete*.
Please stop using them, especially the binaries.  If you're an archive
maintainer, and reading this, please delete them both.  The binaries
in shadow-bin worked dandily for me a while back, but people seem to
be having trouble with them - use the latest stuff!  The new release
contains improvements from both the author, and me.  (those of you who
have had difficulty with the package, did you run pwconv?  I imagine
that's the largest stumbling block in getting it set up - realizing
that it needs to be run, hard to do without doc)

I didn't distribute binaries this time.  The package is
not very hard to compile, doesn't take terribly much disk (for
source code), there are *many* configuration items, and *many*
resulting binaries - for which I didn't wish to create .a's.

The current source distribution, as configured, uses
passwords with 16 significant characters, not the traditional 8.
It also supports the BSD quota and AT&T aging fields.  Hence,
It is *not* binary compatible with a large percentage of the stuff
that is flying around for linux.  I prefer it this way, because:
1) I don't really feel that encryption should be standardized, beyond a
library interface (which could possibly be made read-only root) and
2) I think binary compatibility is a long-term hindrance to a system's
growth.  Semi-consequently, I recompile most of what I use anyway.

I can't resist mentioning: To a purist, no password mechanism is
truly irreversible.  Most, if not all, of the current methods are
intractable, but hardly incomputable.  The day has already
arrived, when a slowish unix box can crack a distressingly
high percentage of a traditional /etc/passwd.  I work in a place
where precisely this happened - the machine in question
was (notoriously :-) *slow*, and the progress was surprising.

Since the time to crack a password is generally exponential in
the length of the input, using longer passwords is A Good Thing.
(n^16 is *vastly* larger than n^8, integer n >= 2, eh?)

About US export restrictions.  I'm not completely certain what
I've heard is correct, but I'll mention it anyway.  Last I
heard, no encryption source code could leave the states - you
could export as many encryption text books as you wanted, but
no source code could go.  In fact, It's been said by our local
encryption expert, that encryption hardware imported to the
US from a foreign country, cannot even be (re)exported from the
US! This calls into question the exportability of both ufc, and
the shadow password suite.  I am not sure I believe MIT went
to all the trouble of making two releases (one containing
encryption, one not) of Kerberos (which also uses nonstandard
encryption, though I believe it's a modified DES) for
no reason.  This has pesky implications for mirror sites...

I'd love to find out I'm wrong about that.  Is the NSA out
there?  :-)

One final plea: If you choose to use the shadow passwords,
please compile the source from the latest release:
/usr/linux/usr.bin/shadow.tar.Z, on tsx-11.mit.edu - not
shadow-bin.tar.Z, and not shadow-src.tar.Z.

- Dan