Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!adm!xadmx!rbj@dsys.icst.nbs.gov From: rbj@dsys.icst.nbs.gov (Root Boy Jim) Newsgroups: comp.unix.questions Subject: /etc/shadow equivalent without a source license! Message-ID: <18939@adm.BRL.MIL> Date: 4 Apr 89 14:42:15 GMT Sender: news@adm.BRL.MIL Lines: 56 ? From: Paul De Bra ? Date: 5 Mar 89 16:50:28 GMT ? In article <199@tnl.UUCP> norstar@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@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 Author of "The Daemonic Versions"