efficiency of /etc/passwd lookup
Bbn-Unix@sri-unix
Date: 23 Oct 1982 15:39:23 EDT (Saturday)
At Harvard we replaced /etc/passwd with a hashed-on-logname, fixed
record organization, with "private" information (such as encrypted
passwords, student ID nos., etc.) kept in a parallel, publically-
unreadable file. And, yes, it's very easy to encapsulate these
changes by rewriting the handful of get**ent routines. Standard
Bell or Berkeley programs run without reprogramming. For those
few programs which might migrate to our system in binary form,
we regenerated an /etc/passwd file (with a phoney password field)
every morning.
It wasn't a realistic possibility for us to use the /etc/passwd
organization, because we had over 2500 unique lognames on each of
our 11/70's.
Steve Dyer
P.S.: The decision to prevent access to passwords was deliberate,
stemming from the fact that the earlier V6 password algorithm
had been broken easily by a number of undergraduates. The latest
DES is tougher, of course, but we didn't want to be the testbed.
Brl@sri-unix
Date: 25 Oct 82 11:00:11-EDT (Mon)
The BRL (JHU) UNIX used here has been modified to use a separate user-
information file, among many other similar system changes. The encrypted
passwords have been moved to a less readable file, as you suggest. I
would also like to urge the following:
When the "passwd" program is run (automatically upon password
aging, as implemented in newer Bell UNIXes, or manually when
the user or system manager needs to change a password), it
should ONLY allow passwords that pass the following tests:
1) certain minimum number of characters, etc. as recommended
in the paper "Password Security: A Case History";
2) not in the on-line dictionary;
3) not equal to the login name.
Perhaps other security checks could be added, but these seem
essential.
Given this more stringent password checking, there should be no problem
with the current readable encrypted "salted password" scheme. Please
note that UNIX security does not seem to be tight enough for classified
Defense work (does anyone know what the outcome of the "Kernelized Secure
UNIX" project was?).
Yes, let's get at the password through the library interface rather than
directly. The less known about file formats the better off a system
utility is when the formats change. Apparently Berkeley is going to
make us all change the way we search directories anyway...
Cmu-10a@sri-unix
Date: 26 October 1982 1216-EDT (Tuesday)
I'm not sure I agree with the statement that you should allow ONLY
those specific passwords. The 'passwd' programs I've seen warn to
that effect, but after 4 or 5 tries at something it would reject, it
gives up. I think a better approach is just to not let anyone but
user foo get user foo's encrypted password. Still, I DO think it's
essential to warn the naive about the silly passwords (like those in the
"Case History") -- most naive users won't have enough nerve to disregard
what the passwd program says 4 times in a row.
When you say the "Kernelized Secure UNIX" project -- do you mean the
"UCLA Unix Security Kernel"? If so, they had NO interest in dealing with
passwords -- the paper (CACM Feb. 80) discusses their effort at proving
the kernel itself secure. It in fact leaves out of the discussion those
"trusted processes" that we all know and love.
Nonetheless, I agree that library interfaces are the way to go: if I were
dealing with an old V6 system, this entire conversation would be inane
because of the amount of code that would need fixing.
Michael