/etc/shadow equivalent without a source license!

Root Boy Jim rbj at dsys.icst.nbs.gov
Wed Apr 5 00:42:15 AEST 1989


? From: Paul De Bra <debra at alice.uucp>
? Date: 5 Mar 89 16:50:28 GMT

? In article <199 at tnl.UUCP> norstar at tnl.UUCP (Daniel Ray) writes:
? >Hello everybody. I am trying to hack together a working equivalent to
? >the /etc/shadow scheme of unreadable passwords. I run a XENIX 386 v2.2.3
? >system, and only have a binary license. Working with the 'bpatch' binary
? >editor, I was planning to substitute the word 'shadow' for 'passwd' in
? >the text string appearances of '/etc/passwd' in the compiled object files
? >for: /bin/passwd, /etc/login, and /bin/su. (Then I would have cron periodic-
? >ally copy /etc/shadow to /etc/passwd except that the 2nd field would be
? >an 'x' in the public /etc/passwd version, while the real passwd file would
? >be /etc/shadow).
? >...

? Wait a minute... this is not a useful way to implement /etc/shadow.
? The idea of /etc/shadow is to have a publicly accessible /etc/passwd that
? does not contain the (encrypted) passwords. /etc/shadow only contains the
? login and encrypted passwords (and possibly some other secret stuff).
? It is to prevent password hacking that the password should be in the
? unreadable file. I don't see much use for your copy of /etc/passwd.
? Maybe you want to reconsider the whole idea?

? Paul.
? -- 
?  ------------------------------------------------------
? |debra at research.att.com   | uunet!research!debra     |
?  ------------------------------------------------------

I disagree. Both files, /etc/passwd *and* /etc/shadow should look *exactly*
alike, except that the passwords in /etc/passwd should be random. Consider:

The Bad Guy is really, or rather looks like, a Good Guy. That is, he
has an account on your machine. So he changes his password, and sees
that /etc/passwd doesn't change, or that the entry remains `x'. You
have now alerted him to the fact that /etc/passwd is not the real
file, so he goes looking for the real one. The above reasoning applies
if he gets a copy of /etc/passwd somehow.

Perhaps the point is moot; the real security comes from the fact that
/etc/shadow is unreadable. However, one of the best ways to keep a
secret is not to let on that there is one. Often Bad Guys are quite
clever at one thing while totally missing another obvious point; I
can just see someone `successfully' cracking the fake password
file only to discover mysteriously that it doesn't work.

In any case, there are several solutions to the problem of changing
/etc/shadow to mode 400 instead of mode 444. The first is the
hard way; either use bpatch or adb or something else, find the
constant 444, and change it to 400. Another easier way is to 
wrap /bin/passwd in another program that simply does a chmod
after the real /bin/passwd runs. This leaves a small window
where /etc/shadow could possibly be read however.

	Catman Rshd <rbj at nav.icst.nbs.gov>
	Author of "The Daemonic Versions"



More information about the Comp.unix.questions mailing list