sdyer@Bbn-Unix@sri-unix (10/26/82)
From: Steve Dyer <sdyer@Bbn-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.gwyn@Brl@sri-unix (10/27/82)
From: Doug Gwyn <gwyn@Brl> 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...
Michael.Young@Cmu-10a@sri-unix (10/28/82)
From: Michael Wayne Young <Michael.Young@Cmu-10a> 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