lab@qubix.UUCP (06/21/83)
Observing the discussion about password security on UN*X, it seems
that the problem focuses on two locations: login and /etc/passwd.
Where this "bad guy" has been, he has seen some non-standard but
fairly (one of them VERY) secure solutions to the problems.
/bin/login should check for consecutive bad tries on a single
invocation, and after, say, 5 or 6, notify the system
administrator of monkey business on a specific terminal or line.
The bad guy can get wise and force an exit from login back to
/etc/getty, but this may taken more time than he can afford (and
if a dial-in line, there may be problems with port competition).
There could also be a log of unsuccessful logins which the SysAdm
could peruse and circumvent the bad guy's circumvention.
Perhaps the most secure way is to lock up the file containing the
passwords, so the bad guy can't get anything to compare his
encryption to. You ask "How?" considering that /etc/passwd is needed
for about 10**x different things! Notice I didn't say "lock
/etc/passwd"; I said "the file containing the passwords." What we
did was change two programs, /bin/login and /bin/passwd, to use a
different file, which was mode 600 root. Those are the ONLY
programs which really NEED the real passwords. /etc/passwd would
then be only a copy of the real password file, with junk where the
passwords should be (a sed script works nicely). And if login and
passwd are mode 6711, no user will be able to figure out what the
name of the file is from the object code.
I would be glad to hear of any flaws in my reasoning.
Larry Bickford
{ucbvax,decvax}!decwrl!qubix!lab
...!{ittvax,amd70}!qubix!lab
decwrl!qubix!lab@Berkeley.ARPA (?)