Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!jpl-devvax!lwall From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) Newsgroups: comp.unix.wizards Subject: Re: What should the password/security/userinfo/login system include? Message-ID: <6629@jpl-devvax.JPL.NASA.GOV> Date: 19 Dec 89 01:02:06 GMT References: <4180@sbcs.sunysb.edu> <1989Dec7.172233.10130@chinet.chi.il.us> <7284@ficc.uu.net> <1989Dec16.054850.5881@chinet.chi.il.us> Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) Distribution: usa Organization: Jet Propulsion Laboratory, Pasadena, CA Lines: 82 In article <1989Dec16.054850.5881@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: : In article <6602@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: : : >We disallow both of these. The new password must be sufficiently different : >from the old one. You can't EVER reuse a password on our system, period. : : Does this mean that you keep a file containing the old passwords around : (like everyone has been saying is a security risk)? Only old encrypted passwords. And when was everyone saying anything about old passwords? I recall some discussion of logging failed attempts on current passwords... : >Password aging definitely improves security here. I don't like it any : >more than the users do, since I have to change their forgotten passwords : >more often than they forget them (me being one and them being many). : >But passwords do have a habit of leaking out from non-conscientious : >users occasionally, so we have to punish the innocent with the guilty : >in order to get the level of security we require. : : I'm sure your requirements are a bit different than most systems, but : has this really been demonstrated to be true? Won't users be more : likely to keep written copies of their password if they are required : to change often? It doesn't seem to happen much here. Partly because we let people come up with their own system of generating good passwords. People naturally prefer to come up with passwords they can remember. At least on our project, people wander from terminal to terminal, so they'd have to have it in their wallet, or some such. Dragging out your wallet every time you want to log in is not *that* much fun. And you may be right that our requirements are different than most systems-- we're currently much more worried about someone hacking their way in from the outside, and such people probably wouldn't have physical access to a written-down password anyway. If someone within the project discovered someone else's password, it wouldn't be a big deal, since most files are shared within the project anyway. : >You get a whole week's warning by mail here so you aren't suddenly forced : >to think up a new password at an importune moment. : : That would help, but only if you work on that system consistantly. What : if you need to connect to 5 or 6 different machines a few times a month? Generally, there's someplace that you receive e-mail regularly, and you can just forward you messages there. : What if you want to make a machine connect and retreive something for : you via an automatic login script? I take it that you don't have any : uucp logins on these machines... If I did, do you think I'd tell you? :-) The straight answer is that we don't have to age every account. And we don't run much uucp. And automatic retrieval with rcp is unrestricted within the project. (We expire external hostnames in .rhosts files regularly.) We don't WANT people writing automatic retrieval scripts from outside. That, in my mind, is a very good argument *for* expiring passwords. : >We have no extra stuff in our password file for aging. The age in weeks, : >modulo 64, is encoded into one of the salt characters (perturbed by the : >first two characters of the login name so that salts are still randomly : >distributed; also, the other salt character is still totally random.) : : So you don't see any need to make the encrypted password unreadable? There's some small value in that, but it's certainly not on the top of the priority list, for us anyway. There's nothing in our scheme that would prevent the use of a shadow password file. We're very serious about security here. If someone's account is broken into because of a lousy password, he can be fired. If a machine is broken into because of negligence on the part of the SA, he can be fired. Gulp. So we do a lot of stuff, security-wise, that I'm not even going to tell you about. If you bust security here, you can be sure I'm gonna try my best to make sure it's not MY hide that gets nailed to the outhouse. Larry Wall lwall@jpl-devvax.jpl.nasa.gov