cracraft@venera.isi.edu (Stuart Cracraft) (11/20/87)
The 60-second timeout in Unix login is not long enough. When accessing Unix via various networks or combinations of networks, particularly when either the remote machine or the local machine is heavily loaded, the 60-second timeout will consistently prevent login. Has anyone else encountered this? Are there any others out there who would vote to increase the timeout from 60 seconds to 180 seconds? Stuart
kyle@xanth.UUCP (Kyle Jones) (11/22/87)
In article <4139@venera.isi.edu>, cracraft@venera.isi.edu (Stuart Cracraft) writes: > The 60-second timeout in Unix login is not long enough. > > When accessing Unix via various networks or combinations > of networks, particularly when either the remote machine > or the local machine is heavily loaded, the 60-second > timeout will consistently prevent login. If the remote machine is so loaded that login can't exec your shell before timing out then you weren't going to get much done anyway. If the local machine is so loaded that you can't type your login name and password within 60 seconds, you still weren't going to get much done. If the network between the local host and the remote host is so clogged that you can't get your login name and password to remote machine within 60 seconds, you certainly shouldn't be loading the net any further. And you weren't going to get much done until the network activity died down, anyway. 60 seconds is a LONG time.
chris@mimsy.UUCP (Chris Torek) (11/22/87)
In article <4139@venera.isi.edu> cracraft@venera.isi.edu (Stuart Cracraft) writes: >The 60-second timeout in Unix login is not long enough. The timeout in the 4.2/4.3BSD login program is stored in a global variable called `timeout'; it can be altered with adb. If you are using a 4.2 or 4.3 derivative system, and the vendor has stripped the /bin/login binary, without providing some alternate means of changing the timeout, you have cause for complaint. If you are using 4.2 or 4.3 BSD, you have sources, and can do anything you like. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
loverso@encore.UUCP (John LoVerso) (11/23/87)
In article <3516@xanth.UUCP> kyle@xanth.UUCP (Kyle Jones) writes: > If the network between the local host and the remote host is so > clogged that you can't get your login name and password to remote > machine within 60 seconds, you certainly shouldn't be loading the net > any further. And you weren't going to get much done until the network > activity died down, anyway. You probably haven't used the ARPAnet much, lately. With some packets getting up to 15 second (or more) turnaround times, I sometimes get burnt buy a 60 second login period. However, once logged in, telnet in line-at-a-time mode makes getting something useful done on the remote machine no that hard. John
lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (11/24/87)
In article <4139@venera.isi.edu>, cracraft@venera.isi.edu (Stuart Cracraft) writes: > The 60-second timeout in Unix login is not long enough. > > When accessing Unix via various networks or combinations > of networks, particularly when either the remote machine > or the local machine is heavily loaded, the 60-second > timeout will consistently prevent login. > > Has anyone else encountered this? Are there any others > out there who would vote to increase the timeout from 60 > seconds to 180 seconds? > > > Stuart If you are going to increase the 60 second time limit you should also limit the number of login attempts, (with 60 seconds and fast hands you can get about 15 attempts). For example, login could kick you out after N attempts or M seconds, whichever occurs first. If you don't do something like this, then you are giving a cracker more time to pound on your system with password guesses, of course they can get right back in so its not a great help. To make this even better, allow login only in the first N attempts, after that just keep prompting but don't let them in. Exit after M seconds too. Does anyone have other suggestions for making login more secure?
robert@johnny.cs.unlv.edu (Robert Cray) (11/24/87)
In article <3516@xanth.UUCP> kyle@xanth.UUCP (Kyle Jones) writes: >In article <4139@venera.isi.edu>, cracraft@venera.isi.edu (Stuart Cracraft) writes: >> The 60-second timeout in Unix login is not long enough. >> >If the network between the local host and the remote host is so >clogged that you can't get your login name and password to remote >machine within 60 seconds, you certainly shouldn't be loading the net >any further. And you weren't going to get much done until the network >activity died down, anyway. Often its not a case of getting a lot done, but getting just a little done, perhaps making a single change in a file, creating a directory or some such. This is usually the case for me when I end up on a slow network link to do something. Also, the net may not be overly loaded -- I go via decnet across the country through 3 links, then telnet to the unix machine. In and of themselves the links are not overloaded, but combined they tend to make things a bit slow... --robert
wolfgang@mgm.mit.edu (Wolfgang Rupprecht) (11/24/87)
In article <2167@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: >For example, login could kick you out after N attempts or M >seconds, whichever occurs first. [...] >Does anyone have other suggestions for making login more secure? If you wanted to "play with" the hacker a bit, you could (say after 10 to 20 bad login attempts), give them ish(l) as a login shell! Ish is a hack "shell" that was posted to the net 3-4 years ago. It is really just a C program that mimics a normal sh. The thing is, it *never* does any Unix system calls (other than printing to the terminal). You could use this to waste the hackers time, and with a bit of logging, maybe even find out what they are up to. Ish is fairly amusing. It responds to 'ls' with a canned list of "files". You can now 'cat' the files. It also knows about shell builtins like 'for' 'while' etc. I forget some of the other things that it does. Anyway, the best defense seems to be to not let the would-be intruder know that they've been spotted. Just watch them and let them expose themselves more. -- Wolfgang Rupprecht UUCP: mit-eddie!mgm.mit.edu!wolfgang (or) mirror!mit-mgm!wolfgang ARPA: wolfgang@mgm.mit.edu (IP addr 18.82.0.114)
jfh@killer.UUCP (11/24/87)
In article <2167@tut.cis.ohio-state.edu>, lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: > In article <4139@venera.isi.edu>, cracraft@venera.isi.edu > (Stuart Cracraft) writes: > > The 60-second timeout in Unix login is not long enough. > > > > When accessing Unix via various networks or combinations > > of networks, particularly when either the remote machine > > or the local machine is heavily loaded, the 60-second > > timeout will consistently prevent login. > > > > Stuart > > If you are going to increase the 60 second time limit you > should also limit the number of login attempts, (with 60 > seconds and fast hands you can get about 15 attempts). > [ stuff deleted ] > Does anyone have other suggestions for making login more secure? I have considered (and once did) hacking the login sources to log failed attempts. This helped us find out that someone was attempting to crack the root account, my account, and the system managers account. I created a little structure, which was indexed by uid in a file with the number of unsuccessful logins and the date of the last unsuccessful one, plus the tty name of the port the last attempt was made on. When you successfully logged in, it gave you a report. If you saw too many of these things, it might be a wise idea to change your password. This is not a new idea of mine, I stole it from VMS ... - John. -- John F. Haugh II SNAIL: HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 ...!ihnp4!killer!rpp386!jfh Dallas, TX. 75243 "Don't Have an Oil Well? Then Buy One!" (214) 231-0993
kai@uicsrd.csrd.uiuc.edu (11/25/87)
You can increase the login timeout on 4.2BSD by simply adding a field to the
dialup terminals gettytab entry. Add ":to=180" to whatever entry you use for
dialups, or even better, make a new gettytab entry that includes the new
timeout field, and then change your /etc/ttys file entry for your dialup
line(s) to use your new gettytab entry.
I use this on our system because we have some beginner level folks dialing
in, who often take a long time to type in their login and password
correctly. This change simply increases the time between the first login
attempt and when the phone is hung up. The number of login attempts doesn't
need to be changed on our system, a Sequent Balance 8000 running DYNIX
V3.0.4. After each three login attempts, login quits, and getty takes over
again. The timeout never recycles, so after n seconds, the phone hangs up no
matter how many times you try to login.
See GETTYTAB(5) and TTYS(5), or send Email for more info.
Patrick Wolfe
Internet: pwolfe@kai.com
UUCP: ...!{uunet,ihnp4}!uiucuxc!kailand!pwolfe
The opinions expressed here are my own, NOT my employers.marcos@caus-dp.UUCP (Marcos R. Della) (11/26/87)
In article <1878@bloom-beacon.MIT.EDU>, wolfgang@mgm.mit.edu (Wolfgang Rupprecht) writes: > If you wanted to "play with" the hacker a bit, you could (say after 10 > to 20 bad login attempts), give them ish(l) as a login shell! Ish is a > hack "shell" that was posted to the net 3-4 years ago.... If you could, can you post the source code to such a program or finger its location where we can pester someone else for a copy? That would be something that would help a security problem that we have going on here at our location... Marcos Della -- ...!lll-crg -> !csustan -\ | Whatever I said doesn't ...!sdsu ----->->!polyslo!caus-dp!marcos | mean diddly as I forgot ...!ihnp4 -> !csun ----/ | it even before finishing ...!dmsd ---/ | typing it all out!!!
rick@svedberg.bcm.tmc.edu (Richard H. Miller) (11/26/87)
Another approach to hacker frustration is to pause between prompts for
userid and as a user enters an unsuccessful userid/password, double the
wait time. Thus as a person attempts to crack you system, it will take
longer and longer to have Unix prompt for the userid after a bad guess.
This is one of the methods that OS-1100 plans to implement for their B1
security EXEC.
Richard H. Miller Email: rick@svedburg.bcm.tmc.edu
Head, System Support Voice: (713)799-4511
Baylor College of Medicine US Mail: One Baylor Plaza, 302H
Houston, Texas 77030lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (11/26/87)
In article <2206@killer.UUCP>, jfh@killer.UUCP (The Beach Bum) writes: ... > > I have considered (and once did) hacking the login sources to log failed > attempts. This helped us find out that someone was attempting to crack > the root account, my account, and the system managers account. > [neat idea deleted] > John F. Haugh II SNAIL: HECI Exploration Co. Inc. I also have changed login to log failed attempts, but there are some hazards here. The user name, tty number, date, and time are logged. But, if the user name is invalid a ? is logged. Sometimes users accidentally enter a password at the login: prompt, so you don't want to log it. Some security changes I am considering now are to 1) if someone tries to login as root on other than the console, immediately start spinning (and never print a message about root being able to login only on the console) (just an annoyance really), and 2) prohibit passwords that are a) letters followed by numbers, b) numbers followed by letters, or c) contain the user login name. For example, Larry99 99Larry and lvc.tut are all poor passwords.
jc@minya.UUCP (John Chambers) (11/29/87)
In article <440@uni2.bcm.tmc.edu>, rick@svedberg.bcm.tmc.edu (Richard H. Miller) writes: > Another approach to hacker frustration is to pause between prompts for > userid and as a user enters an unsuccessful userid/password, double the > wait time. Thus as a person attempts to crack you system, it will take > longer and longer to have Unix prompt for the userid after a bad guess. > This is one of the methods that OS-1100 plans to implement for their B1 > security EXEC. A couple years back, I worked on a system where the getty did this. The trouble was, the dial-in ports got quite a few random "characters" coming in, which looked to getty like invalid attempts to log in, so it slowly jacked up the delay. When a real user connected, it took forever to get any prompts. I had to subvert this "feature" in order to alleviate the users' frustration. Eventually, I solved it better by installing my own logger and doing away with getty, but that's another tale. Without the source, I probably would have been forced to replace getty right away. -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
bzs@bu-cs.bu.EDU (Barry Shein) (11/30/87)
>When you successfully logged in, it gave you a report. If you saw too >many of these things, it might be a wise idea to change your password. > >This is not a new idea of mine, I stole it from VMS ... > >- John. And it's certainly not a new idea with VMS... Is there really any good basis for changing one's password in the face of repeated failed attempts to login by a cracker? This assumes of course that the cracker has not been successful and the password you are using is not obvious (so the change is not simply justified by increasing the security level of the password choice itself.) Given that, aren't you as likely as not to change your passwd to the crackers *next* guess? Even password aging, which seems to be based upon similar logic (?) I assume relies on the assumption that the would be cracker is "closing in" so changing it throws him/her off course. I thought we all rely on the massive combinatorics (assuming good passwd choice) involved? Changing the passwd doesn't change that. I could definitely see changing your login name. If the cracker moves to that new login name (new failed login attempt messages) you know s/he is specifically after you and not just a random hit. What you do next is not obvious, but that's off the topic. Alternately it might just force the cracker to continue to try the old acct and waste his or her time (assuming you've rendered the old account name inert.) I never saw any logic to the reply "change your password" when someone notices repeated failed attempts (we can monitor this on our systems also.) Changing your account name is not of much use if the person is the slightest bit interested in you unless you don't run finger or leave clues in outgoing mail and news postings (fat chance) etc, internal people can obviously just grep passwd, it's not much of a response but might give a hint that it's worth worrying about if the cracker does follow you to your new account name. The only possible reasons I can see are: 1. You had a bad passwd to begin with so this is a good time to change to a good one (maybe that's what sysadmins hope for.) 2. You think the cracker has cracked your passwd but for some reason you cannot detect this (eg. by viewing lastlog.) Changing the passwd would at least block this possibility (that they've already got you.) 3. You fear that somehow the cracker is persisting because they have part of your password and just need a few more tries to break it (possible, unlikely, no feedback, unless they got it from some other method, like looking over your shoulder while you typed it in.) -Barry Shein, Boston University
dave@lsuc.uucp (David Sherman) (12/03/87)
cracraft@venera.isi.edu (Stuart Cracraft) writes: >The 60-second timeout in Unix login is not long enough. > ... >Has anyone else encountered this? Are there any others >out there who would vote to increase the timeout from 60 >seconds to 180 seconds? I changed it to 120 seconds on this (v7-based) system some years ago. We have computer-naive students (law students) using this system, often with no-one around to help them and not a lot of instruction on how to log in (they get a login/password sheet and a set of access instructions and that's it; once they log in the CAI system leads them by the hand). I was reluctant to change the traditional UNIX "login:" and "Password:" prompts, but I found that students would sometimes get confused about what they should be typing, when they were first starting. (Since we have 1100 new students a year, in only takes a small percentage of people who can't follow instructions...) With a 120-second delay, they usually have enough time to figure it out by trial and error. David Sherman The Law Society of Upper Canada Toronto -- { uunet!mnetor pyramid!utai decvax!utcsri ihnp4!utzoo } !lsuc!dave Pronounce it ell-ess-you-see, please...
robert@stevie.cs.unlv.edu (Robert Cray) (01/21/88)
In article <10578@brl-adm.ARPA> bzs@bu-cs.bu.EDU (Barry Shein) writes: >Even password aging, which seems to be based upon similar logic (?) I >assume relies on the assumption that the would be cracker is "closing >in" so changing it throws him/her off course. I thought we all rely on >the massive combinatorics (assuming good passwd choice) involved? >Changing the passwd doesn't change that. > I think password aging assumes that many users will have poorly chosen passwords, and if a cracker gets it, it will only be for a short time until it is changed next. I've run ``password guessing'' programs on a number of varying machines, typically 40% will have normal words as passwords. I hear that in the next (4.7?) version of vms, it will remember the last 6 passwords so that a->b->a (which is what I always do) will be more painful. Another (bad) thing that vms can be set up to do is log ``intrusion'' records. It will log the username *and* password that was attempted, so if you log on over a noisy line, and have 3 failed attempts, maybe *thats* the time to change your password. --robert
greg@xios.XIOS.UUCP (Greg Franks) (02/08/88)
In article <721X@jimi.cs.unlv.edu> robert@jimi.cs.unlv.edu (Robert Cray) writes: >...I hear that in the next (4.7?) version of vms, it will >remember the last 6 passwords so that a->b->a (which is what I always do) >will be more painful. Do what everyone else does - change your password at the beginning of the month to the name of the month :-). -- Greg Franks XIOS Systems Corporation, 1600 Carling Avenue, (613) 725-5411 Ottawa, Ontario, Canada, K1Z 8R8 utzoo!dciem!nrcaer!xios!greg "There's so much to sea in Nova Scotia"
jc@minya.UUCP (John Chambers) (02/15/88)
In article <465@xios.XIOS.UUCP>, greg@xios.XIOS.UUCP (Greg Franks) writes: > In article <721X@jimi.cs.unlv.edu> robert@jimi.cs.unlv.edu (Robert Cray) writes: > >...I hear that in the next (4.7?) version of vms, it will > >remember the last 6 passwords so that a->b->a (which is what I always do) > >will be more painful. > > Do what everyone else does - change your password at the beginning of > the month to the name of the month :-). > Nah, I just change it to what it was before. That's much easier to remember, and since Unix encrypts it differently each time, the administrators have no way of knowing that I'm doing it. If VMS can actually determine that you have used the same password, then it is either keeping your unencrypted password somewhere, or it encrypts it the same each time. Either is a major security hole, of course, and you should refuse to use the system (on security grounds) until they correct the problem. (Actually, there is a third possibility, that it is unencrypting the encrypted passwords for comparison, but not even VMS hackers would do that routinely! :-) [[I sure hope that's a joke! ;-]] -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
ron@topaz.rutgers.edu (Ron Natalie) (02/16/88)
Actually at BRL, it remembers all past passwords that everyone used and won't ever let you reuse them (or use the "passwd" program to set too accounts to the same password). -Ron
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/17/88)
In article <18083@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: >Actually at BRL, it remembers all past passwords that everyone used and >won't ever let you reuse them (or use the "passwd" program to set too >accounts to the same password). Huh? How could it do this when the passwords are never stored in the clear? I just changed my password on VGR.BRL.MIL to the same one that I was already using, and it let me. The same password is also used for two other accounts that I know of. I think your memory is failing you in your old age, Ron..
mikel@codas.att.com (Mikel Manitius) (02/17/88)
In article <468@minya.UUCP>, jc@minya.UUCP (John Chambers) writes: > > If VMS can actually determine that you have used the same password, then it > is either keeping your unencrypted password somewhere, or it encrypts it the > same each time. Either is a major security hole, of course, and you should > refuse to use the system (on security grounds) until they correct the problem. Not nessecerily. The system could keep an encrypted list of all passwords used durring the past N days (weeks, months), indexed per user. Any time you try to change your password, it encrypts it once for every remembered password, using that salt, if the two encrypted passwords match (note: same salt), then there is a reuse, and the password is not accepted. This would be just as "secure" as the UNIX password file, only adding the burden of maintaining such as list. -- Mikel Manitius mikel@codas.att.com
mikel@codas.att.com (Mikel Manitius) (02/17/88)
In article <468@minya.UUCP>, jc@minya.UUCP (John Chambers) writes: > > If VMS can actually determine that you have used the same password, then it > is either keeping your unencrypted password somewhere, or it encrypts it the > same each time. Either is a major security hole, of course, and you should > refuse to use the system (on security grounds) until they correct the problem. Not nessecerily. The system could keep an encrypted list of all passwords used durring the past N days (weeks, months), indexed per user. Any time you try to change your password, it encrypts it once for every remembered password, using that salt, if the two encrypted passwords match (note: same salt), then there is a reuse, and the password is not accepted. If the password is accepted, then it is re-encrypted with a random salt (ie: UNIX "makekey") and then stored. This would be just as "secure" as the UNIX password file, only adding the burden of maintaining such as list. -- Mikel Manitius mikel@codas.att.com
jrl@anuck.UUCP (j.r.lupien) (02/17/88)
In article <18083@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) writes: > Actually at BRL, it remembers all past passwords that everyone used and > won't ever let you reuse them (or use the "passwd" program to set too > accounts to the same password). Oh really? This means that if you get a reject, and you know it isn't one of your previous passwords, it >MUST< be someone else's! Then you just try each login on the system until you hit the one who's password you have just "guessed". This seems rather bogus. The passwd program should not give out ANY information about other users' passwords, even to the extent of "you have just used a word nobody else is using". Security is YOUR job, too!
rjd@occrsh.ATT.COM (02/17/88)
>Nah, I just change it to what it was before. That's much easier to remember, >and since Unix encrypts it differently each time, the administrators have >no way of knowing that I'm doing it. Ah, but there is a way of knowing without storing un-encrypted passwords around. Since the "seed" used for the permutation algorithm is the first two characters of the encrypted password, all you need to do is encrypt your new password using the seed of each of the old ones, and then compare the encryption to the encrypted password whose seed you are using. The passwd() command uses some mumbo-jumbo on the system clock to generate a pseudo-random seed each time you set or change your password. For that matter, though it would be in bad faith of the administrator, it is a simple thing to change the one program (or more?) to record the password un-encrypted somewhere.... All that you need is to modify source to passwd(). Randy
preece%fang@gswd-vms.gould.com (Scott E. Preece) (02/18/88)
From: "j.r.lupien" <jrl@anuck.uucp> > > Actually at BRL, it remembers all past passwords that everyone used and > > won't ever let you reuse them (or use the "passwd" program to set too > > accounts to the same password). > > Oh really? This means that if you get a reject, and you know it isn't > one of your previous passwords, it >MUST< be someone else's! Then > you just try each login on the system until you hit the one who's > password you have just "guessed". This seems rather bogus. > The passwd program should not give out ANY information > about other users' passwords, even to the extent of > "you have just used a word nobody else is using". ---------- I think you're misinterpreting the quote. I don't think they meant you could never use a password that ANYONE had every used, only that you couldn't use one that YOU had used before. The language is ambiguous -- either interpretation could be right, but since the "never use a password that anyone had ever used" interpretation would require storing the passwords in clear (or something not salted by user), I suspect the "never reuse one of your old passwords" interpretation is what was meant. -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@Gould.com
ag@portnoy.CTS.COM (Keith Gabryelski) (02/19/88)
Posting-Front-End: GNU Emacs 18.41.10 of Mon Feb 15 1988 on portnoy (sco-xenix-v)
Actually at BRL, it remembers all past passwords that everyone used and
won't ever let you reuse them (or use the "passwd" program to set too
accounts to the same password).
Ack! BOGUS. So what does it return when two people use the same
password:
"Uhhh.. I'm sorry, that password is used by root, please
choose another."
pax, Keith
--
[ Keith ] UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!portnoy!ag
[Gabryelski] INET: ag@portnoy.cts.com ARPA: crash!portnoy!ag@nosc.milruiu@tic.UUCP (Dragos Ruiu) (02/19/88)
In article <18083@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) writes: > Actually at BRL, it remembers all past passwords that everyone used and > won't ever let you reuse them (or use the "passwd" program to set too > accounts to the same password). > > -Ron Assuming 'two' for 'too'. Isn't this rather a large security hole if someone stumbles across another password. He will then know that there is an account with that password, and a breach would be short work. Comments ? -- Dragos Ruiu UUCP:<backbone>!alberta!edson!tic!dragos!work Hey, remember the one who pretended to be a super-villain to get beaten ? Whatever happened to him ? He pulled it on Rorshach and Rorshach dropped him down an elevator shaft.
ron@topaz.rutgers.edu (Ron Natalie) (02/20/88)
Kingston wrote the code, I guess that it wasn't bothered to be installed. -Ron
richard@aiva.ed.ac.uk (Richard Tobin) (02/22/88)
In article <7267@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <18083@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: >>Actually at BRL, it remembers all past passwords that everyone used and >>won't ever let you reuse them (or use the "passwd" program to set too >>accounts to the same password). > >Huh? How could it do this when the passwords are never stored in the >clear? The same way it checks you've typed the correct one when you log in, I should think. Of course, comparing two encrypted passwords for equality is trickier, as the "salt" may be different. BTW, does knowing two different encryptions of a password (ie encrypted with different salts) make decrypting easier? -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
richard@aiva.ed.ac.uk (Richard Tobin) (02/22/88)
In article <470@anuck.UUCP> jrl@anuck.UUCP (j.r.lupien) writes: >In article <18083@topaz.rutgers.edu>, ron@topaz.rutgers.edu (Ron Natalie) writes: >> Actually at BRL, it remembers all past passwords that everyone used and >> won't ever let you reuse them (or use the "passwd" program to set too >> accounts to the same password). > >Oh really? This means that if you get a reject, and you know it isn't >one of your previous passwords, it >MUST< be someone else's! Yes, but you can do this anyway. Just try logging in as each person in turn. Or more likely, write a program that tries the word for each person. The whole point of a good encryption algorithm is to make this sort of thing hard by making it slow. (That didn't stop them using register variables in crypt(3), however. I guess it's hard to overcome such habits...) -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
trt@rti.UUCP (Thomas Truscott) (02/24/88)
In article <260@aiva.ed.ac.uk>, richard@aiva.ed.ac.uk (Richard Tobin) writes: > ... The whole point of a good encryption algorithm is to make > this sort of thing hard by making it slow. (That didn't stop them > using register variables in crypt(3), however. ...) A good encryption method must be more than slow, it must be *inherently* slow, to reduce the payoff from brute force attacks. crypt(3) achieves inherent slowness by iterating DES 20 times (and by using a modified DES to thwart most chip implementations). Non-inherent slowness is not a benefit, as the Bad Guy can simply use a faster implementation for the brute force attack. As it happens, crypt(3) is extremely inefficient. Bob Baldwin (baldwin@mit-xx.arpa) has written a plug-compatible equivalent that is sixty times faster. Using it, our Gould 9050 can trial-encrypt all of /usr/dict/words in *one minute* (for a given salt). Slowing down *other* versions of crypt() does not change this! For improved security one can use the fast version of crypt() and iterate 1200 times so that it remains slow. In summary: An encryption method should be implemented as efficiently as possible, yet still be slow. Adding algorithmic inefficiencies is no better (indeed is worse) than adding "sleep(1);" Tom Truscott
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/24/88)
In article <259@aiva.ed.ac.uk> richard@uk.ac.ed.aiva (Richard Tobin) writes: >Of course, comparing two encrypted passwords for equality is trickier, >as the "salt" may be different. That was my whole point. With something like 4K salts, you would have to keep a LOT of encrypted previous-password data around. >BTW, does knowing two different encryptions of a password (ie encrypted >with different salts) make decrypting easier? In theory, yes, but in practice decryption of such short samples of DES- encrypted data by analysis is generally considered too difficult. Thus the emphasis on "practical cyrptanalysis", such as is done by the program that was posted to sci.crypt recently.
jay@splut.UUCP (Jay Maynard) (02/26/88)
In article <468@minya.UUCP>, jc@minya.UUCP (John Chambers) writes: > If VMS can actually determine that you have used the same password, then it > is either keeping your unencrypted password somewhere, or it encrypts it the > same each time. Either is a major security hole, of course, and you should > refuse to use the system (on security grounds) until they correct the problem. Not necessarily. The method IBM uses in RACF to keep track of passwords is beguilingly simple: They store the password as the encrypted value. I can hear it now: "Security hole!" Well, almost. You're right in that using the same encryption method (algorithm and key) would allow a known-plaintext attack on the encryption key. IBM gets around this by using the simple trick of using the password itself (possibly permutated somehow - they don't distribute RACF source microfiche files :-) as the encryption key. To determine if it's the same, they simply encrypt it and compare the encrypted values. If this does allow an attack on the encrypted passwords, let me know so I can APAR it... > John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) -- Jay Maynard, EMT-P, K5ZC...>splut!< | GEnie: JAYMAYNARD CI$: 71036,1603 uucp: {uunet!nuchat,academ!uhnix1,{ihnp4,bellcore,killer}!tness1}!splut!jay Never ascribe to malice that which can adequately be explained by stupidity. The opinions herein are shared by none of my cats, much less anyone else.
rbj@icst-cmr.arpa (Root Boy Jim) (03/01/88)
From: Doug Gwyn <gwyn@brl-smoke.arpa> In article <259@aiva.ed.ac.uk> richard@uk.ac.ed.aiva (Richard Tobin) writes: >Of course, comparing two encrypted passwords for equality is trickier, >as the "salt" may be different. That was my whole point. With something like 4K salts, you would have to keep a LOT of encrypted previous-password data around. What Richard Tobin says is correct, but I don't think relevant. You don't have to keep *all* possible encryptions of the password `foobar' to reject a future attempt to use foobar as a password. Just use the salt that is used in the encrypted password. Assuming all attempts to use a given password are rejected, it is possible for only one of the 4096 encryptions of a given password to be in the encryption file. On the other hand, if one were to collect all previous passwords ever used at a site from backup tapes (or rather, their encrypted versions), there is a way to pare the equal ones down. First collect all unique encrypted passwords and put them in a file which I will refer to as the raw file. Create an empty file which I will call the unique file. Whenever a password is entered, check for all matches in the unique file. If a match is found, one need look no further. Otherwise, search all entrys in the raw file. If matches are found, pick one and enter it in the unique file. Delete all matches from the raw file. It is interesting that people's ideas on security are often wrong. For example, some people around here think that having different passwords on different machines provides better security than using the same one for all machines! It just ain't so. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 YOW!!! I am having fun!!!