pokey@well.UUCP (Jef Poskanzer) (02/24/88)
Ok, one fix would be to keep the encrypted passwords in a non-world-readable
file, while leaving the rest of /etc/passwd readable so that nothing breaks.
Doing this would mean adding a small hack to the getpwent routines, and
recompiling login and passwd. But if you don't have source, this is a
problem.
Here's another idea. Change the password encryption algorithm so that
it runs through crypt a hundred times instead of once. And so that it
doesn't take minutes to log in, use fdes instead of crypt. Yeah, that's
it, use the same technology that the crackers use! Doing this would
mean small changes to login and passwd. But once again, if you don't
have source, you're s.o.l.
Or are you? It turns out that login is not really that complicated.
A friend of mine recently wrote his own login, not for increased
security but because the version supplied with his system wouldn't
allow more than two people to log in at a time. It was only about
two pages of code, including all the utmp hacking. Since his brain
damaged version of Unix was also missing the crypt routine, I gave
him a copy of fdes. I can't believe passwd would be any harder to
re-implement than login...
Am I missing something, or would it really be this easy to increase
security? If this is practical, perhaps I can get my friend to
release his version of login to the net, along with a new passwd to
go with it.
---
Jef
Jef Poskanzer jef@lbl-rtsg.arpa ...well!pokey
"Who's going to believe you? You're just a talking head."gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/24/88)
In article <5289@well.UUCP> pokey@well.UUCP (Jef Poskanzer) writes: >Ok, one fix would be to keep the encrypted passwords in a non-world-readable >file, while leaving the rest of /etc/passwd readable so that nothing breaks. >Doing this would mean adding a small hack to the getpwent routines, and >recompiling login and passwd. But if you don't have source, this is a >problem. Since you wouldn't be changing the format of /etc/passwd, just its use, no hack to getpwent() is necessary. Of course the real authentication agents such as login and passwd do have to understand the new scheme. They're easy enough to write from scratch, as you suggested. (Actually, so is getpwent(), but as I said that's unnecessary.) Trying to cripple the encryption so that it runs very slowly is not adequate. A cracker could simply copy your /etc/passwd to a fast machine and crack it there. To be confident that this would take too much time for the cracker, assuming your system isn't a Cray or equivalent, you'd have to slow down the algorithm so much that logging into your system would take intolerably long. by the way, once you have the separate password file method working, it might be fun to generate random passwords and fill /etc/passwd with their encryptions. That way a cracker who doesn't know that your system uses a better method could waste a lot of his time attempting to crack and use the fake passwords!
strick@stratus.UUCP (henry strickland) (02/25/88)
In article <5289@well.UUCP> pokey@well.UUCP (Jef Poskanzer) writes: >Ok, one fix would be to keep the encrypted passwords in a non-world-readable >file, while leaving the rest of /etc/passwd readable so that nothing breaks. >Doing this would mean adding a small hack to the getpwent routines, and >recompiling login and passwd. But if you don't have source, this is a >problem. > Jef Poskanzer jef@lbl-rtsg.arpa ...well!pokey Only a very few programs use the pw_password field from /etc/passwd: 1) /???/login 2) /bin/su 3) /bin/passwd (what else?) Alter these to use another file (perhaps "/etc/Passwd") for passwords, which is not readable, and have a sed script convert this to /etc/passwd, which is readable, but with the pw_passwd field demolished. >But if you don't have source, this is a >problem. Even with a binary-only site one can poke a "P" over the "p" in the string where it appears in the binary. ( For example, I alter an instruction in /???/login from a "BLE" to a "BRA" instruction when it only lets 2 people log on a system... ) -- Henry Strickland <strick@gatech.edu> gatech!strick 404-676-1313
arosen@eagle.ulowell.edu (MFHorn) (02/25/88)
In article <5289@well.UUCP> pokey@well.UUCP (Jef Poskanzer) writes: >And so that it >doesn't take minutes to log in, use fdes instead of crypt. Unfortunately (or fortunately, depending on the color of your hat), fdes doesn't work on all machines. Say it does work on your machine, and you put it into login, but hide the source so users can't use it. The cracker can then just open a pipe to login and use it that way. It will be slower due to the added overhead, but it'll still be faster than your own program (like the one just posted) using crypt(3). Andy Rosen | arosen@hawk.ulowell.edu | "I got this guitar and I ULowell, Box #3031 | ulowell!arosen | learned how to make it Lowell, Ma 01854 | | talk" -Thunder Road RD in '88 - The way it should be
jordan@zooks.ads.com (Jordan Hayes) (02/26/88)
Andy Rosen <arosen@hawk.ulowell.edu> writes:
Say it does work on your machine, and you put it into login,
but hide the source so users can't use it. The cracker can
then just open a pipe to login and use it that way.
First of all, if you care at all about security, /bin/login will have
lots of hooks for logging failed attempts. Further, as shipped from
most vendors, /bin/login has 4755 permissions -- set-uid to root and
world-executable. When login gets exec()ed from getty, it's already
running as root, there's no need to make it set-uid.
I think there was some history leading to the ability to login from
someone else's shell, in which case you'd need to be set-uid to change
the tty permissions and write into utmp, etc., but it seems to me
there's limited utility in doing something like this.
Further, most /bin/login implementations i've seen trash the current
utmp entry when you login from the shell.
This is probably counter-productive.
This also probably belongs in comp.unix.wizards ... follow-ups
are directed there.
/jordanpokey@well.UUCP (Jef Poskanzer) (02/27/88)
In the referenced message, arosen@hawk.ulowell.edu (MFHorn) wrote: }Unfortunately (or fortunately, depending on the color of your hat), fdes }doesn't work on all machines. I assume you are talking about the byte-ordering problems? I was able to get it running on a Sun in about half an hour. It's not that big a deal. Anyway, the point of my suggestion is merely to get things back the way they were. Right now, the bad guys use fdes and the good guys don't, and so the bad guys have a 100-to-1 advantage. If the good guys start using fdes too, things will be balanced again. --- Jef Jef Poskanzer jef@lbl-rtsg.arpa ...well!pokey "And out of olde bokes, in good feyth, cometh al this newe science..." -- Geoffrey Chaucer
thompson@calgary.UUCP (Bruce Thompson) (02/27/88)
In article <5289@well.UUCP>, pokey@well.UUCP (Jef Poskanzer) writes: > Ok, one fix would be to keep the encrypted passwords in a non-world-readable > file, while leaving the rest of /etc/passwd readable so that nothing breaks. > Doing this would mean adding a small hack to the getpwent routines, and > recompiling login and passwd. But if you don't have source, this is a > problem. > > ... > > > --- > Jef > > Jef Poskanzer jef@lbl-rtsg.arpa ...well!pokey > "Who's going to believe you? You're just a talking head." This is similar to the approach taken by Apollo in their systems. I honestly don't know if the passwords are stored encrypted or not, as the account file is unreadable. This relates to Apollo's protected sub-system techniques. File(s) and/or programs can be declared as 'members' of a protected sub-system, and only 'member' programs can access 'member' files. Naturally, control of 'member'ship depends on the ACLs in effect for the subsystem. (on our system, you must be root) The /etc/passwd file is as suggested above, everything except the passwords. TTFN, Bruce Thompson ------------------------------------------------------------------------------ Bruce Thompson | Hey! What're you doing there at my University of Calgary, | terminal! (Skuffle skuffle) Computer Science Department | What is this chicken scratch? (403)220-3538 or (403)220-5017 (office) | | ^X-^C ...!alberta!calgary!vaxb!thompson |
jgp@moscom.UUCP (Jim Prescott) (03/03/88)
In article <5289@well.UUCP> pokey@well.UUCP (Jef Poskanzer) writes: >Ok, one fix would be to keep the encrypted passwords in a non-world-readable >file, while leaving the rest of /etc/passwd readable so that nothing breaks. AT&T's 386 Unix System V does this. /etc/shadow contains the encrypted password and some new info that provides useful capabilites, eg. it is possible to disable an account without messing with the password. Rather than have the password field be a random password or a '*' why not have it be a real password that the user can change. Programs that ask for your password to prove identity would still work but would use the "low security" password. Only login and su would deal with the "high security" password kept in the protected file. This would also make programs that prompt for your password slightly less of a bad idea. >Here's another idea. Change the password encryption algorithm so that >it runs through crypt a hundred times instead of once. And so that it Increasing the time taken to check a password is only a temporary solution. Machines keep getting faster. Brute force attacks are also trivial to run on multiple cpu's. A while back someone from Apollo said they had over 2000 machines on their network; being able to throw over 4000 MIPS at the problem will make short work of the hundredfold increase in processing time. In "Password Security: A Case History" they say one reason for the salt stuff Unix uses was to prevent the use of des chips which run several orders of magnitude faster than software. They add: "Obviously, the bad guy could have his own chip designed and built, but the cost would be unthinkable." Now I'm not a hardware type but I would guess that the cost of designing and implementing a "Unix des" chip is probably a lot less unthinkable now than in 1978. Does anyone have any rough idea of how hard/costly this would actually be? >doesn't take minutes to log in, use fdes instead of crypt. Yeah, that's What is fdes, a fast des algorithm? Could someone tell how to get a copy? -- Jim Prescott moscom!jgp@cs.rochester.edu {rutgers,ames,cmcl2}!rochester!moscom!jgp What the world needs now is a physical constant that differs from pi in only the hundredth decimal place.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/04/88)
In article <1149@moscom.UUCP> jgp@moscom.UUCP (Jim Prescott) writes: >Rather than have the password field be a random password or a '*' why >not have it be a real password that the user can change. Programs that >ask for your password to prove identity would still work but would use >the "low security" password. Only login and su would deal with the "high >security" password kept in the protected file. This would also make >programs that prompt for your password slightly less of a bad idea. This would encourage users to put a copy of their "high security" password (or a slight modification of it) in the "low security" file, which would compromise the security of the password. What you should have is a trusted password verifier that can be reliably used to check a user's password against the "high security" file, although with considerable delay (say, 5 seconds) imposed to make it practically useless for password-probing programs.