Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!rutgers!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.wizards
Subject: Re: Passwords
Message-ID: <17401:Apr1307:58:0691@kramden.acf.nyu.edu>
Date: 13 Apr 91 07:58:06 GMT
References: <26518@adm.brl.mil> <14248: Apr1204:14:4891@kramden.acf.nyu.edu> <1991Apr12.120209.21241@mp.cs.niu.edu>
Organization: IR
Lines: 27

In article <1991Apr12.120209.21241@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
>  What I have never understood is why the password encryption algorithm doesn't
> use additional information other than the password - the user name and the
> machine name (or domain name for YP based networks).  That way anyone who
> broke one encryption has succeeded only in breaking it for one user on
> one system.  Sure, this would make life slightly tougher for administrators
> when propogating accounts to another host.

There's another reason, probably the more important one: if crypt()
depends on the hostname and username, then somebody has to keep that
information around and give it to crypt(). Since so many different
programs use crypt() in so many different situations, this is (for all
practical purposes) impossible.

I advocate a *single* program to do *all* password checking. You give it
a login name and a password on its input; it gives you a username on its
output, or exits 1 with no output. If every use of crypt() were changed
to use this program instead, it would be trivial to add features to
increase security. But do you expect vendors to have enough foresight to
take lasting modularity over short-term convenience?

(By the way, kludging usernames into passwords doesn't really help
except for stored-dictionary attacks. If the username is XORed in before
encryption, you can break the password independently of the username. If
the username is XORed in after encryption, it's pointless.)

---Dan