brnstnd@stealth.acf.nyu.edu (Dan Bernstein) (12/07/89)
This is rather open-ended. There are hundreds of files dealing with system administration, user information, user control, and so on. There are almost as many different programs for interacting with those files, some more logical and coherently organized than others. Does /etc/utmp makes sense? Should passwords and usernames be longer? Should all login sessions be automatically recoverable? What about Steve Bellovin's session manager? Should passwords be in their own protected directory, one file per user? What features should the login program have? Should root have a secure /root directory, with all interesting files safely tucked away? How should yellow pages work? I don't know the right phrase to describe what I'm aiming at; ``user control'' is the best I've come up with. Anyway, we're all so used to a particular set of user control files and user control programs that we rarely consider entirely different, perhaps better, systems. I find myself working (not too strenuously) on a complete redesign of the user control system. Basically, what d'y'all want in it? I don't promise to take any particular suggestion, but I'll give credit for new ideas that I use. I'll try to archive all responses to this article; please stick to news, not mail. ---Dan
bri@boulder.Colorado.EDU (Brian Ellis) (12/07/89)
In article <4180@sbcs.sunysb.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes: [deleted] >I find myself working (not too strenuously) on a complete redesign of >the user control system. Basically, what d'y'all want in it? I don't >promise to take any particular suggestion, but I'll give credit for new >ideas that I use. For one thing, the unix filesystem is not all that organized. I would recommend gloming things like /bin /usr/bin /usr/local/bin You might also eliminate the historical distinction between /etc and /bin. General cleanup and unification would be great. -brian ellis (bri@boulder.Colorado.EDU)
les@chinet.chi.il.us (Leslie Mikesell) (12/08/89)
In article <4180@sbcs.sunysb.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes: >Does /etc/utmp makes sense? Should passwords and usernames be longer? >Should all login sessions be automatically recoverable? What about >Steve Bellovin's session manager? Should passwords be in their own >protected directory, one file per user? What features should the login >program have? Should root have a secure /root directory, with all >interesting files safely tucked away? How should yellow pages work? I want logging of *all* keystrokes during a failing attempt at logging in (more to allow me to help with the problem, but it would also help detect intruders). This means (a) getty has to run in raw mode (I want to see NULLs/XOFFs/backspaces/#'/@'s, et.al.), and (b) getty and login have to be a single program, since getty collects the first keystokes and doesn't know if the login is going to fail. >I don't know the right phrase to describe what I'm aiming at; ``user >control'' is the best I've come up with. Anyway, we're all so used to a >particular set of user control files and user control programs that we >rarely consider entirely different, perhaps better, systems. How about tagging files with an indication of where they came from with a little kernel support beyond the current uid/gid. I'd like to know if any particular file came straight off the commercial distribution media, some other xfer media, or was it locally created, and has it been locally modified since installation. As as side effect, you could find all of your local modifications since a system was installed and use this to reconstruct after a installing a new OS. Les Mikesell les@chinet.chi.il.us
dsg@mbunix.mitre.org (Goldberg) (12/08/89)
In article <14652@boulder.Colorado.EDU> bri@boulder.Colorado.EDU (Brian Ellis) writes: > For one thing, the unix filesystem is not all that organized. I > would recommend gloming things like /bin /usr/bin /usr/local/bin > You might also eliminate the historical distinction between > /etc and /bin. General cleanup and unification would be great. > > -brian ellis (bri@boulder.Colorado.EDU) I agree that /bin and /usr/bin could probably be combined, although I understand why they were originally separated (keep root partition small and only have enough stuff in there so you could run in single user mode) and I have no trouble putting executables from /etc into /bin, but distinguishing /usr/local/bin and /usr/bin is something I find very useful. We try to keep everything delivered from the vendor in their own filesystems, so that when we upgrade, downtime can be minimized. It makes a huge difference in our environment to be able to mount /usr/local/bin with all the previous OS version binaries in it and tell our users that some or all *may* not work until we get to recompiling them as opposed to telling them that they *all will not* work until we get around to recompiling them. I suspect we are not alone in this... -- -------------------------------------------------------------------------- Dave Goldberg ARPA: dsg@mbunix.mitre.org The Mitre Corporation UUCP: linus!mbunix!dsg MS B020 Bedford, MA 01730 617-271-2460
jbayer@ispi.UUCP (Jonathan Bayer) (12/09/89)
les@chinet.chi.il.us (Leslie Mikesell) writes: >I want logging of *all* keystrokes during a failing attempt at logging >in (more to allow me to help with the problem, but it would also >help detect intruders). This means (a) getty has to run in raw mode >(I want to see NULLs/XOFFs/backspaces/#'/@'s, et.al.), and (b) getty >and login have to be a single program, since getty collects the first >keystokes and doesn't know if the login is going to fail. This is not a good idea. If someone unauthorized sees this log file they would have a fairly good idea of some of the passwords on the system. Remember, a lot of failed login attempts are due to typing mistakes and (sometimes) bad phone connections. In these cases the user id's may be correct, or possibly one character off, and the same goes for the passwords. JB -- Jonathan Bayer Intelligent Software Products, Inc. (201) 245-5922 500 Oakwood Ave. jbayer@ispi.COM Roselle Park, NJ 07204
les@chinet.chi.il.us (Leslie Mikesell) (12/09/89)
In article <1236@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: >>I want logging of *all* keystrokes during a failing attempt at logging >>in. >This is not a good idea. If someone unauthorized sees this log file >they would have a fairly good idea of some of the passwords on the >system. If they are written to a file that can only be read by root, why should I worry about that? If someone can already get root permissions why would they want to know any other passwords? >Remember, a lot of failed login attempts are due to typing >mistakes and (sometimes) bad phone connections. In these cases the user >id's may be correct, or possibly one character off, and the same goes >for the passwords. Indeed, and when that person calls me and asks why they can't get in to the system, I'd like to be able to tell them. One aspect of security is to keep everyone happy enough that they don't *want* to damage the system. In that vein, I'd personally like to strangle the person who invented automatic password aging. My input to that "your password has expired - choose a new one" prompt (which usually comes after I notice an automated login script has been making long-distance calls and failing every 10 minutes for a day or two) invariably contains at least one predictable four-letter word. It's a good thing all the machines that have done that to me have been out of my reach... Les Mikesell les@chinet.chi.il.us
tale@cs.rpi.edu (David C Lawrence) (12/10/89)
<1989Dec9.053433.5407@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell): >>I want logging of *all* keystrokes during a failing attempt at logging >>in. >This is not a good idea. If someone unauthorized sees this log file >they would have a fairly good idea of some of the passwords on the >system. If they are written to a file that can only be read by root, why should I worry about that? If someone can already get root permissions why would they want to know any other passwords? Interesting. There was recently discussion here on just such a thing when the ftp daemon on the ACM's 3B2s was doing logging. The problem exists in that if you find out a person's password on one machine (the one for which Les point's out it wouldn't matter, because you could su to the user anyway from root) then you have often times discovered the user's password on other machines. Of course, someone with root access to a machine should have the scruples not to use this information to gain access to a user's account. This is certainly not a completely accurate assumption though -- there are obviously people out there with no such integrity. Dave -- (setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))
jfh@rpp386.cactus.org (John F. Haugh II) (12/11/89)
In article <1989Dec9.053433.5407@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >If they are written to a file that can only be read by root, why >should I worry about that? If someone can already get root permissions >why would they want to know any other passwords? will the file always be readable by root only? there is a serious difference between being able to access data and having root privilege. unix security is based on your knowing something, so the information is very valuable. -- John F. Haugh II +-Things you didn't want to know:------ VoiceNet: (512) 832-8832 Data: -8835 | In Ham lingo DEC is rot-13 for "Low InterNet: jfh@rpp386.cactus.org | Power". "CPU?" "QRP Vax-11." UUCPNet: {texbell|bigtex}!rpp386!jfh +--------------------------------------
bill@bilver.UUCP (Bill Vermillion) (12/11/89)
In article <1989Dec9.053433.5407@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1236@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: > >>>I want logging of *all* keystrokes during a failing attempt at logging >>>in. > >>This is not a good idea. If someone unauthorized sees this log file >>they would have a fairly good idea of some of the passwords on the >>system. > >If they are written to a file that can only be read by root, why >should I worry about that? If someone can already get root permissions >why would they want to know any other passwords? I have noticed that when people choose a password, the next time they choose a password it is along the same line - eg, names, cars, things, ... If there is an unscrupulous SA, and failed attempts at logging are recorded, there is a good chance that person will be able to quickly figure these user acounts on other machines, that perhaps this root user doesn't have access too. Often users have the same p'word on more than one system. I am guilty of that on one site that I has 11 machines I am semi-responsible for. (There are 6 people who have access to the list of root passwords for these machines.). They could get to any accounts, but I wouldn't like them to be able to see what I type for a password for my own login on those machines, as it would give them an indication of how I choose passwords. (Human nature being what it is we usually build passwords that we can remember.). >Indeed, and when that person calls me and asks why they can't get in >to the system, I'd like to be able to tell them. What's wrong with just noting that user xxxx was rejected for bad password? >... In that vein, I'd personally like to strangle the person who >in invented automatic password aging. I'll agree on that point. >Les Mikesell (P.S. Les - I did get the disks last year, but about 5 attempts to mail you acknowledgement and thanks - got bounced). bill -- Bill Vermillion - UUCP: {uiucuxc,hoptoad,petsd}!peora!tarpit!bilver!bill : bill@bilver.UUCP
brnstnd@stealth.acf.nyu.edu (Dan Bernstein) (12/12/89)
In article <1236@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: > les@chinet.chi.il.us (Leslie Mikesell) writes: > >I want logging of *all* keystrokes during a failing attempt at logging > >in (more to allow me to help with the problem, but it would also > >help detect intruders). My login program does this; it even records the times between keystrokes. It runs in raw mode at the moment, though I'm considering switching back to cbreak. (Why does this imply that login and getty/telnetd need to be combined?) > This is not a good idea. If someone unauthorized sees this log file > they would have a fairly good idea of some of the passwords on the > system. All password characters (except backspace and newline) are replaced by x. The information loss does not outweigh the security gain. ---Dan
les@chinet.chi.il.us (Leslie Mikesell) (12/12/89)
In article <4217@sbcs.sunysb.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes: >> >I want logging of *all* keystrokes during a failing attempt at logging >> >in (more to allow me to help with the problem, but it would also >> >help detect intruders). >My login program does this; it even records the times between keystrokes. >It runs in raw mode at the moment, though I'm considering switching back >to cbreak. (Why does this imply that login and getty/telnetd need to be >combined?) Because I only want the failing logins logged. Getty accepts the first line of input and has no way of knowing if the login will succeed. Since I want to be able to see the raw characters, the (possibly editted) line handed to login isn't good enough. Besides, I'd like to see a speedup in the login process. >> This is not a good idea. If someone unauthorized sees this log file >> they would have a fairly good idea of some of the passwords on the >> system. >All password characters (except backspace and newline) are replaced by x. >The information loss does not outweigh the security gain. This is the most reasonable suggestion so far, but when a login fails it is pretty difficult to tell which piece you are not interpreting correctly. If you pick up a couple of CR's from modem noise you could still manage to get both the login and password in the visible part. I'd be perfectly happy to encrypt the whole thing. Can someone suggest a way to handle the encryption key other than the obvious method of compiling it into the program? Now to put the problem in perspective, the machine where I would most like to see this sort of logging runs a subscription information database. There are >1K users in the passwd file, most of whom don't know anything about computers and aren't interested in learning - they just want their automated communication program script to login and grab a set of files for them. Almost no one on the machine gets a real shell - just a program that prompts for requests, logs them and hands them out. The sensible thing might be to make this program also perform the getty/login functions on the dial-up lines but it seems somehow against the unix "philosophy". Les Mikesell les@chinet.chi.il.us
meissner@dg-rtp.dg.com (Michael Meissner) (12/12/89)
In article <4217@sbcs.sunysb.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes: | In article <1236@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: | > les@chinet.chi.il.us (Leslie Mikesell) writes: | > >I want logging of *all* keystrokes during a failing attempt at logging | > >in (more to allow me to help with the problem, but it would also | > >help detect intruders). | | My login program does this; it even records the times between keystrokes. | It runs in raw mode at the moment, though I'm considering switching back | to cbreak. (Why does this imply that login and getty/telnetd need to be | combined?) | | > This is not a good idea. If someone unauthorized sees this log file | > they would have a fairly good idea of some of the passwords on the | > system. | | All password characters (except backspace and newline) are replaced by x. | The information loss does not outweigh the security gain. This seems to come up time and time again. The problem with logfiles (including /dev/console) and passwords is that often times users type passwords at the login prompt. Thus if user 'foo' has a password 'bar456', and types the password at the wrong time, a message will be sent to the logfile stating that unknown user 'bar456' tried to log on. The safest thing I've heard is to only write the username in question if you are sure it's a valid username (or possibly a name a cracker would try, such as guest). -- -- Michael Meissner, Data General. Until 12/15: meissner@dg-rtp.DG.COM After 12/15: meissner@osf.org
merlyn@iwarp.intel.com (Randal Schwartz) (12/13/89)
In article <1989Dec7.172233.10130@chinet.chi.il.us>, les@chinet (Leslie Mikesell) writes: | I want logging of *all* keystrokes during a failing attempt at logging | in (more to allow me to help with the problem, but it would also | help detect intruders). This means (a) getty has to run in raw mode | (I want to see NULLs/XOFFs/backspaces/#'/@'s, et.al.), and (b) getty | and login have to be a single program, since getty collects the first | keystokes and doesn't know if the login is going to fail. No, no, no! A log of failed logins and/or passwords and/or keystrokes is a BIG security hole. Send me mail if you weren't in on this discussion last time, and don't see why it is a BIG security hole, and want to know why. Just another legendary-wizard's-namesake, -- /== Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ====\ | on contract to Intel's iWarp project, Hillsboro, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!uunet!iwarp.intel.com!merlyn | \== Cute Quote: "Welcome to Oregon... Home of the California Raisins!" ==/
ram@attcan.UUCP (Richard Meesters) (12/13/89)
In article <398@bilver.UUCP>, bill@bilver.UUCP (Bill Vermillion) writes: > In article <1989Dec9.053433.5407@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > >In article <1236@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: > > > >>>I want logging of *all* keystrokes during a failing attempt at logging > >>>in. > > > >>This is not a good idea. If someone unauthorized sees this log file > >>they would have a fairly good idea of some of the passwords on the > >>system. > > > >If they are written to a file that can only be read by root, why > >should I worry about that? If someone can already get root permissions > >why would they want to know any other passwords? > Simply put, if you have root permission, you are in as root, and are traceable as such. You don't have access to the machine from a remote terminal unless you already have a users login. If you wanted to be an unobtrusive hack you could simply figure out from the log file what the user's password was, then keep using it for as long as the user keeps (or is allowed to keep) that password. No one would be the wiser. Personally I like the fact that even the superuser doesn't -know- my password. True, he can change it to no password, or even any password he wants, but unless he can decript the file, he couldn't possibly use *my* password. It adds a feeling of security on the user's side. > >... In that vein, I'd personally like to strangle the person who > >in invented automatic password aging. > Password aging is optional (at least on System V) and, while I don't like it any better than you, if the system administrator deems it necessary to keep proper security on his machines, then I have no choice but to go along with it. Lets face it, it is more secure than everyone using the same password over and over on a number of systems ad infinitum. Regards, Richard Meesters
peter@ficc.uu.net (Peter da Silva) (12/13/89)
In article <10650@attcan.UUCP> ram@attcan.UUCP (Richard Meesters) writes: > Password aging is optional (at least on System V) and, while I don't like it > any better than you, if the system administrator deems it necessary to keep > proper security on his machines, then I have no choice but to go along with > it. Lets face it, it is more secure than everyone using the same password > over and over on a number of systems ad infinitum. Password aging makes it more likely that a user will use the same password on a large number of machines, simply because it increases the number of things that user needs to remember. I change my passwords when *I* need to and have the leisure to. How about fropping this chain, though. It's a lot less interesting than some of the more exotic possibilties: * Stripping everything from the password file but name, password, user id, and home. * Getting rid of the GROUP concept altogether. Replace it with a set of secondary user-ids and ACLs on files. * Reading shell, long name, etc from a text file under the user's control. What else? -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
ram@attcan.UUCP (Richard Meesters) (12/14/89)
In article <7284@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > Password aging makes it more likely that a user will use the same password > on a large number of machines, simply because it increases the number of > things that user needs to remember. > Huh? Maybe I'm not reading this right. Users will naturally gravitate to using the same password on multiple systems, IMHO, for the same reasons you have listed above. If password aging is used, that forces them to at least change them once in a while. > I change my passwords when *I* need to and have the leisure to. So do I. I've even been known to use abusive passwords when the system makes me change. Somehow that makes me feel better :-}. > > How about fropping this chain, though. It's a lot less interesting than > some of the more exotic possibilties: > > * Stripping everything from the password file but name, password, > user id, and home. This looks a lot like what 386 unix already does with /etc/shadow and the password file. Regards, Richard Meesters
peter@ficc.uu.net (Peter da Silva) (12/15/89)
In article <10665@unix.UUCP> ram@attcan.UUCP (Richard Meesters) writes: > In article <7284@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > > Password aging makes it more likely that a user will use the same password > > on a large number of machines, simply because it increases the number of > > things that user needs to remember. > Huh? Maybe I'm not reading this right. Users will naturally gravitate to > using the same password on multiple systems, IMHO, for the same reasons you > have listed above. If the user is conscientious, then they will use different passwords up to some limit. The more frequently they have to switch to a new password, the fewer machines they'll be willing to have unique passwords on. If the user is not conscientious, they'll use the same password everywhere and minimise the effect of aging by using (say) "secret1" then "secret2", or toggle between two passwords, or otherwise work around the password aging. So, at the best password aging doesn't improve security. At worst, it reduces it. When the system makes *me* change, I then change back to the old one. And change passwords on my schedule. > > * Stripping everything from the password file but name, password, > > user id, and home. > This looks a lot like what 386 unix already does with /etc/shadow and the > password file. Nah, this puts *more* stuff in the password file. All the old stuff, plus password aging. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (12/15/89)
In article <7311@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: : In article <10665@unix.UUCP> ram@attcan.UUCP (Richard Meesters) writes: : > In article <7284@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: : > > Password aging makes it more likely that a user will use the same password : > > on a large number of machines, simply because it increases the number of : > > things that user needs to remember. : : > Huh? Maybe I'm not reading this right. Users will naturally gravitate to : > using the same password on multiple systems, IMHO, for the same reasons you : > have listed above. : : If the user is conscientious, then they will use different passwords up : to some limit. The more frequently they have to switch to a new password, : the fewer machines they'll be willing to have unique passwords on. We FORCE people to have the same password everywhere. Even if some users are conscientious here, it's the non-conscientious ones that are the weak link, so your argument doesn't convince me. Once a cracker gets onto one of our machines, he can get to any of the others anyway, so why have different passwords? : If the user is not conscientious, they'll use the same password everywhere : and minimise the effect of aging by using (say) "secret1" then "secret2", : or toggle between two passwords, or otherwise work around the password aging. 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. There's about 27 different kinds of bad password we disallow. We don't tell them what makes a good password since there are many ways to make a good, memorable password, but eventually they figure out their own way, and that's more secure than if we give them a single way to do it. : So, at the best password aging doesn't improve security. At worst, it : reduces it. 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. : When the system makes *me* change, I then change back to the old one. And : change passwords on my schedule. 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. : > > * Stripping everything from the password file but name, password, : > > user id, and home. : : > This looks a lot like what 386 unix already does with /etc/shadow and the : > password file. : : Nah, this puts *more* stuff in the password file. All the old stuff, plus : password aging. 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.) Nifty, eh? By the way, another reason for having the same password everywhere is that we force a person's password entry to have the same salt in every password file. If you let people have the same password on different machines but use different salts (and if the salts are different, how can you prevent people from using the same password anyway?) then your salt protection is weakened. Suppose you have your password out there with 40 different salts. Someone only has to encrypt using 1/40th of the salts to get a hit on your password. Larry Wall lwall@jpl-devvax.jpl.nasa.gov
lee@sq.sq.com (Liam R. E. Quin) (12/16/89)
les@chinet.chi.il.us (Leslie Mikesell) writes: >I want logging of *all* keystrokes during a failing attempt at logging >in (more to allow me to help with the problem, but it would also >help detect intruders). This means (a) getty has to run in raw mode >(I want to see NULLs/XOFFs/backspaces/#'/@'s, et.al.), and (b) getty >and login have to be a single program, since getty collects the first >keystokes and doesn't know if the login is going to fail. This of course poses a considerable security risk. Consider the case that you typed "rot" instead of "root" and gave the correct root password. It gets logged, and anyone who can look at the log can see the root password. Your system is now *less* secure, because you have to protect the log file. Recent trends such as keeping the encrypted passwords in /etc/shadow where only root can see them are an improvement completely defeated if all I have to do is read the raw disk to find the root password. So, if you do this, it has to be done in hardware, ad the record kept somewhere not on line. See the ACM paper on `tracking the wily hacker' for an example of where someone did just this, logging all keystrokes. Some banks use laser cards to store keystroke logs. >How about tagging files with an indication of where they came from >with a little kernel support beyond the current uid/gid. I'd like >to know if any particular file came straight off the commercial >distribution media, some other xfer media, or was it locally created, >and has it been locally modified since installation. There was an interesting paper at the EUUG (European Unix User Group) meeting in London a year or two ago given by Doug McIlroy of Bell Labs [is there more than one? :-)]. He described work done on the research machines to do exactly what you describe, as an experimental method of introducing security without hurting the way Unix works/feels. I have not seen anything more on this since -- does anyone at alice.or.research.what.ever know any more? > As as side > effect, you could find all of your local modifications since a system > was installed and use this to reconstruct after a installing a new OS. Hard of one of them was "mail /dev/rdsk/0s2 < /etc/termcap" (don't try this on your V7 systems, people :-).. You need also to keep track of the changes made to disk files at the raw disk level, which is very expensive. I'd rather use rcs to do source control or my system, and keep a notbook! [0.5 :-)] Lee -- Liam R. Quin, lee@sq.com Until Dec. 20th (visiting sq, not an employee) After Dec 20, Unixsys (UK) Ltd, Knutsford, UK -- +44 565 50021 At home: +44 925 831084 (0830 GMT to midnight GMT only please...) rn: .signature: cannot open: no such fire or dirigible
peter@ficc.uu.net (Peter da Silva) (12/16/89)
> 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.) > Nifty, eh? Nope. Whether it's in another field or hidden in the password is a difference that makes no difference. And besides, that's not the point. The subject is... what should the system security system include? I have four main points: (a) Files should use ACLs, rather than user/group/other. (b) Groups are a bad idea and should be abandoned. All they are is secondary user ids. Why not put them in the same name space as the rest of the user ids? (c) The password file should just contain: login name password password aging user id home directory secondary user-ids (d) All other information should be in an easily editable/processable format in ~user/.something: default shell full name office telephone number I'd recommend a format like RFC-822: Shell: /bin/csh Mailer: /usr/local/lib/deliver Name: Peter da Silva Office: 2419 Phone: 5180 Plan: Replacing MS-DOS with UNIX throughout the company. Favorite-pizza: Pepperoni and Pineapple -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
les@chinet.chi.il.us (Leslie Mikesell) (12/16/89)
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)? >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? >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? 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... >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? Les Mikesell les@chinet.chi.il.us
jfh@rpp386.cactus.org (John F. Haugh II) (12/16/89)
In article <7311@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >If the user is conscientious, then they will use different passwords up >to some limit. The more frequently they have to switch to a new password, >the fewer machines they'll be willing to have unique passwords on. I don't know where you come up with these blanket statements. In an ideal world, yes, the ideal user would use 8 character random generated passwords. However, studies show that more difficult passwords tend to be written down, and once people start writing down passwords, security goes out the window. >If the user is not conscientious, they'll use the same password everywhere >and minimise the effect of aging by using (say) "secret1" then "secret2", >or toggle between two passwords, or otherwise work around the password aging. No, real world users use the same password on all their machines so they won't have to remember 30 or 40 different passwords. Larry Wall mentioned using the same salt on all of the machines as well. Great idea, now when is he going to write the passwd program to do that for me ;-) >So, at the best password aging doesn't improve security. At worst, it >reduces it. > >When the system makes *me* change, I then change back to the old one. And >change passwords on my schedule. Then you need a new passwd program. Real world [ read: really secure ] passwd programs don't permit trivial changes in passwords, don't let you recycle the old ones, and don't let you use mostly-words like "secret1". [ See the obscure passwd detector which detects English tri-grams for more information ] -- John F. Haugh II +-Things you didn't want to know:------ VoiceNet: (512) 832-8832 Data: -8835 | In Ham lingo DEC is rot-13 for "Low InterNet: jfh@rpp386.cactus.org | Power". "CPU?" "QRP Vax-11." UUCPNet: {texbell|bigtex}!rpp386!jfh +--------------------------------------
warner@twg.com (Warner Losh) (12/17/89)
In article <10650@attcan.UUCP> ram@attcan.UUCP (Richard Meesters) writes: >Personally I like the fact that even the superuser doesn't -know- my password. >True, he can change it to no password, or even any password he wants, but >unless he can decript the file, he couldn't possibly use *my* password. It >adds a feeling of security on the user's side. If I'm root, why can't I just say "su ram" and use your account like that? You would be none the wiser and I'd still get access to your account as you, without any body bothering to log that fact anywhere. Or am I, as usual, missing something terribly fundamental? Warner P.S. Don't go yelling at me that you use the same password on all machines, so you don't want the sysadmin to see it on one. If you are doing this, then you have created a large security hole. Same thing with .rhosts files. -- -- Warner Losh warner@twg.com (formerly warner@hydrovax.nmt.edu) My views and spelling are my own. Only the letters have been changed.
les@chinet.chi.il.us (Leslie Mikesell) (12/17/89)
In article <1989Dec15.182256.5912@sq.sq.com> lee@sq.com (Liam R. E. Quin) writes: >les@chinet.chi.il.us (Leslie Mikesell) writes: [logging failed login attempts] >This of course poses a considerable security risk. >Consider the case that you typed "rot" instead of "root" and gave the >correct root password. It gets logged, and anyone who can look at the log >can see the root password. A). I'm only interested in the dialup lines. If someone has trouble locally, I'll walk over and help them. This means that there won't be anyone logging in as root. B). I would only log completely failing attempts (i.e. the line drops before they get in), not every typo. This doesn't happen often unless there is a real problem. Anyone who knows what they are doing would change their password after this happens on the chance that they were typing into a trojan login program anyway. C). The logfile would (of course) only be readable by root. I'd be happy to encrypt it, but how do I pass the encryption key to the login program? >Your system is now *less* secure, because you have to protect the log file. >Recent trends such as keeping the encrypted passwords in /etc/shadow where >only root can see them are an improvement completely defeated if all I have >to do is read the raw disk to find the root password. Can you read the raw disk if you don't already have the root password? If you can do stuff like that, why not just watch the clist buffers and catch them on the fly? Our alternative is to keep a monitor terminal available to bridge onto the modem lines, which is not particularly secure either. It is also not very handy, since the calls mostly come in to a single number that the phone switch rolls over as needed so we don't know ahead of time where a particular call is going to land. Les Mikesell les@chinet.chi.il.us
jfh@rpp386.cactus.org (John F. Haugh II) (12/17/89)
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)? No, you only need to keep the already-encrypted passwords laying around. You then take the trial password and encrypt it using the salt for the old password and compare the result of the encryption. If they match, reject the new password. -- John F. Haugh II +-Things you didn't want to know:------ VoiceNet: (512) 832-8832 Data: -8835 | In Ham lingo DEC is rot-13 for "Low InterNet: jfh@rpp386.cactus.org | Power". "CPU?" "QRP Vax-11." UUCPNet: {texbell|bigtex}!rpp386!jfh +--------------------------------------
exspes@gdr.bath.ac.uk (P E Smee) (12/18/89)
In article <1989Dec7.172233.10130@chinet.ch> les@chinet.chi.il.us (Leslie Mikesell) writes: >I want logging of *all* keystrokes during a failing attempt at logging >in (more to allow me to help with the problem, but it would also >help detect intruders). DO MAKE SURE not to make your logfile publicly readable, or you'll have created an even bigger security hole. Even if you only collect the response to the login: prompt, one of the favourite user errors is to get out of sync with login, and to type their password when the system is expecting their login name. In that case, they usually get back into sync, and so the response to the next login: prompt is usually the username which belongs to that password. -- Paul Smee, Univ of Bristol Comp Centre, Bristol BS8 1TW, Tel +44 272 303132 Smee@bristol.ac.uk :-) (..!uunet!ukc!gdr.bath.ac.uk!exspes if you MUST)
jfh@rpp386.cactus.org (John F. Haugh II) (12/18/89)
In article <88@gollum.twg.com> warner@twg.com (Warner Losh) writes: >In article <10650@attcan.UUCP> ram@attcan.UUCP (Richard Meesters) writes: >>Personally I like the fact that even the superuser doesn't -know- my password. >>True, he can change it to no password, or even any password he wants, but >>unless he can decript the file, he couldn't possibly use *my* password. It >>adds a feeling of security on the user's side. > >If I'm root, why can't I just say "su ram" and use your account like >that? You would be none the wiser and I'd still get access to your >account as you, without any body bothering to log that fact anywhere. >Or am I, as usual, missing something terribly fundamental? You won't be logged in as the user. System logs will show that 'root' logged into that terminal and su'd to 'ram'. You would have to screw with a half dozen log files, the process accounting files, and a few things I've not thought of just yet. You would be able to make those changes, since you are root, but are you sure you aren't going to forget one record somewheres? -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
ram@attcan.UUCP (Richard Meesters) (12/18/89)
In article <1989Dec17.032435.5042@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: > In article <1989Dec15.182256.5912@sq.sq.com> lee@sq.com (Liam R. E. Quin) writes: > >This of course poses a considerable security risk. > >Consider the case that you typed "rot" instead of "root" and gave the > >correct root password. It gets logged, and anyone who can look at the log > >can see the root password. > > A). I'm only interested in the dialup lines. If someone has trouble > locally, I'll walk over and help them. This means that there won't > be anyone logging in as root. > OK, but I wouldn't be as concerned with a hack having just the root password unless he has access to the console (or a remote console), but now if he is able to get a user's login, AND knows the root password, you are in real trouble. He can now get access from anywhere... > B). I would only log completely failing attempts (i.e. the line drops > before they get in), not every typo. This doesn't happen often > unless there is a real problem. > Anyone who knows what they are doing would change their password > after this happens on the chance that they were typing into a > trojan login program anyway. > So this limits the scope of the logfile, but everyone makes mistakes at one time or another, and you still will have the possibility of single character failures on passwords, or someone using the wrong username/password combo. > C). The logfile would (of course) only be readable by root. I'd be > happy to encrypt it, but how do I pass the encryption key to the > login program? > > >Your system is now *less* secure, because you have to protect the log file. > >Recent trends such as keeping the encrypted passwords in /etc/shadow where > >only root can see them are an improvement completely defeated if all I have > >to do is read the raw disk to find the root password. > > Can you read the raw disk if you don't already have the root password? > If you can do stuff like that, why not just watch the clist buffers and > catch them on the fly? I agree with Liam, you still have to protect the file. Perhaps you can't read raw disk without being root, but if you get to see the file somehow, now you can log in as any user and presto, you are in the system basically undetected. If I'm a hacker, and I want to log in as root on some system remotely, I have to have a user's account to get in (not on system console). If I can get a user account, it makes things a lot easier for me. If the sysadmin doesn't know I'm not the real user, all the better. This type of log file has the potential to be a MAJOR security hole. Regards, Richard Meesters
peter@ficc.uu.net (Peter da Silva) (12/19/89)
In article <17451@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: > In an ideal world, yes, the ideal user would use 8 character random > generated passwords. However, studies show that more difficult > passwords tend to be written down, and once people start writing > down passwords, security goes out the window. Isn't that implied by what I just said? I don't know where you get these ideas. It's certainly not by reading what I wrote, and if it's by reading my mind you've obviously got a noisy connection. For "machine" read "administrative unit". Sure, use the same password on all the workstations in your department, or all he computers at your computer center. How many people have 30 or 40 accounts under different umbrellas? Unless you mean BBSes... if you're worried about BBS security I suggest you start by burning the floppies and fire a 45 through the hard disk... Security and convenience are orthogonal considerations. The more secure your system, the less convenient it is to use. Outside of the paranoid reality inhabited by the DoD and IBM, the sort of fascist tactics you're suggesting (such as forcing people to choose new passwords that don't match any old ones and avoid certain patterns) just aren't worth it. And within it, they just make it harder for people to remember their passwords. So they write them down. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. 'U` Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>. "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (12/19/89)
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
reschly@BRL.MIL (Robert J. Reschly Jr.) (12/19/89)
Michael,
Yes, what and when to log has been an interesting topic of discussion
here as well. We have been working with some of the software likely to
be in 4.4BSD; login and friends in particular. The code for login as it
comes from Berkeley is a bit forgiving for our tastes. Comments in the
code imply it is supposed to allow a user to make one mistake (if the
mistake is not a valid username) without generating a log entry.
Reading between the lines leads us to conclude this code is there to
reduce the chance of accidentally catching a password in the logs --
something which happens more frequently than we would like in our
experience. We protect our authorization failure logs, and shred old
console printouts because of this, by the way. The code as received
also allows 10 login attempts before aborting, delaying the next
"login:" prompt by 5 additional seconds for each new prompt after the
third failed attempt -- or so the comments indicate.
In actuality, both code segments are flawed. First, the prompting
delays do not kick in until after the fourth failed attempt -- a classic
"off by one" bug. And the log suppression code is flawed in that it
will allow any number (up to 10) of different attempts to be made
without logging any of them as long as each of the failing attempts does
not match any username or the (yes 'the', not 'any') previous attempt.
If the final attempt is successful and the failing attempts meet the
above restrictions, login will not generate any log entry at all.
Before discussing our modifications, it is also worth noting that
getty will hand login a username longer than login is willing to accept
when it prompts for a username itself. I don't recall whether the stock
login protects itself from overrun, but even if it does, I don't think
allowing this mismatch is good practice (we found this one by just
mashing a handful of keys while testing our mods :-)).
After batting various options around for a while, we settled on having
the login process store each failed attempt (reasonable since this is
bounded by both username length and number of attempts) and calling
badlogin() on each exit path -- including timeouts and hangups. Badlogin()
itself expects to be handed a string. If this string is non-null, the
string is the username associated with a successful login. If there were
any failures badlogin() generates a syslog message listing each of the
failures, and if there was ultimately a successful login, that username
is included in parentheses at the end. Log entries now look like this:
Dec 4 20:23:25 sem login: 4 FAILED from spark: this is a test (reschly)
Note that this entry keeps all attempts from a session on a single
line, giving a count of the number of failures, listing them ('this',
'is', 'a', and 'test') and finally listing the successuful login attempt
in parentheses. Absent is the terminal information for network
connections (this one came from host "spark" -- who cares if it came
from ttyp0 or ttyp1?), and the amount of SHOUTING in the logfile has
been reduced. The count of failures is included as a check on the list
of failures -- since failures may contain any character including space,
we just printed what we captured space separated and did not worry about
it too much.
The rationale for logging the successful login along with the
failures is to allow us to catch someone "escaping" in a suspicious
manner. For example, on many systems there are one or more "safe"
passwordless accounts (e.g. a "sync" account which runs /bin/sync).
It is easy to envision someone trying one or two usernames followed by
"sync". If the unmodified login is run, no log entry will be made if
the username is invalid; and the failed attempt count will not get high
enough to trip the delays.
Our changes do have their disadvantages as well. In the current
implentation, all attempts are buffered up until login exits. This
means we have no indication of an ongoing attempt. Since this seems
like it may be useful information, but it is not normally needed in
our environment, we will probably add code to syslog attempts at some
lower level as they occur (auth.debug is the current favorite).
In addition, we can now match passwords with a vengeance, since
failures are all nicely lined up in a single log entry (and the log
entry may even include the successful attempt). Given the contortions
in the code as shipped aimed at avoiding logging passwords, we will give
Berkeley back code to deal with this. Since the successful login
proceeded by failures is the case we are concerned about, our current
thinking involves running crypt over the failures and comparing the
result against the successful login. If there is a match, badlogin()
would not list that attempt in the log entry. In the event of a match,
the log entry will probably still give an indication of how many matches
occurred (or said another way, how many failed attempts were not
listed).
Finally -- and I mention these only for completness -- we also made
minor modifications to some of the user messages. Army regulations do
not permit us to return responses which would allow a user to determine
the reason access was denied. This means that we have to return the
same "Login incorrect" message for expired passwords or accounts, and
for things like attempts to log in as "root" on non-secure terminals and
invalid shells. We then added syslog's indicating the true reason for
failure to preserve the system administrator's sanity.
Later,
Bob
--------
Arpa: reschly@BRL.MIL (or BRL.ARMY.MIL) Phone: (301)278-6808 AV: 298
UUCP: ...!{{cmcl2,nlm-mcs,husc6}!adm,smoke}!reschly
Postal: Robert J. Reschly Jr.
U.S. Army Ballistic Research Laboratory
Systems Engineering and Concepts Analysis Division
Networking and Systems Development Team
ATTN: SLCBR-SE-A (Reschly)
APG, MD 21005-5066 (Hey, *I* don't make 'em up!)
**** For a good time, call: (303) 499-7111. Seriously! ****les@chinet.chi.il.us (Leslie Mikesell) (12/21/89)
In article <6629@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: >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. But, the whole purpose of the machine in question (i.e. the original topic of logging bad logins), is to collect and store data to be retreived on demand. A typical session is about 2 minutes of on-line time, and most of the data is updated at least daily, some every 10 minutes (it's an agricultural-related database with commodity futures and options listings, market reports from the USDA wire service, advice from various sources, etc.). Thus, even if someone breaks in, they have to keep doing it to keep getting current information. We expect people to use automated scripts to log in since it would be pretty boring to do it yourself several times a day. We also broadcast this stuff over a couple of satellite links - if someone wants to steal it they would probably try to get it that way instead. Still, we have contractual requirements with the information providers to limit access (getting serious now that we are going to offer live tick-by-tick stuff from the commodity exchanges) and I don't want to do anything foolish. However, I do have to deal with the problem of users being unable to log in, and a log of the failed attempts would be most helpful. Users don't get a real shell on this machine - just something that asks for requests and doles them out. Based on some magic stuff in the comment field in the password file (most don't get a HOME directory) they may be able to access mail and a few other things, but they can't go wandering around reading files at random. Les Mikesell les@chinet.chi.il.us