AGRISCS@umcvmb.missouri.edu (Don Ingli) (01/02/90)
How about this idea for passwd storage..... When the root filesystem/partition is created the UNIX machine should reserve n BYTES on the disk that is stored PHYSICALLY on the disk but not in a file. Thus, the UNIX security software would have read the passwds from sector x of disk y and de-crypt them using a crypt that uses the SOFTWARE Serial Number, Node name and a Random Code entered by the sysadm and stored like the passwds. Also, the SALT chars would be used to decrypt.... For those who want added security, look up the pwconv(1M) command. What this does is creates a file called shadow that only root can read. It contains just the encrypted passwd so non-rooters can never see the encrypted passwds: in /etc/shadow: don:ABencrypted:1010:101 in /etc/passwd: don:x:usrid:grpid:etc.... notice an x in the passwd field? That will be in EVERY entry in the passwd file! I'd like to see a hacker get the passwd out of an x!! Anyway, I guess what I am trying to say is that maybe UNIX should place the SHADOW file somewhere on the disk, but not in a file.... comments???? DON INGLI------------------------------------------------------------+ UNITED STATES DEPARTMENT OF AGRICULTURE - SOIL CONSERVATION SERVICE | bitnet: agriscs@umcvmb.bitnet internet: agriscs@umcvmb.missouri.edu | attmail: attmail!attbl!arpa!umcvmb.missouri.edu!agriscs | ALL OPINIONS IN THIS NOTE ARE OF MY OWN AND DO NOT REPRESENT THE | FEDERAL GOVERNMENT OR THE UNIVERSITY OF MISSOURI-COLUMBIA -----------+
barmar@think.com (Barry Margolin) (01/02/90)
In article <21911@adm.BRL.MIL> AGRISCS@umcvmb.missouri.edu (Don Ingli) writes: >Anyway, I guess what I am trying to say is that maybe UNIX should place the >SHADOW file somewhere on the disk, but not in a file.... It's been suggested before. What makes you think storing it on the disk is any more secure than a file? The disk can be accessed as /dev/<something>. The access control on this is no more secure than that provided for /etc/shadow -- if someone can get superuser access then they'd be able to read both of them. On the other hand, having a separate /etc/shadow allows its group permission to be used; passwd could be setgid to its group rather than setuid root. Also, taking the password database out of the file system means that it won't be backed up by current backup tools. All the backup facilities would have to be updated to dump the password partition. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
hpn@att.att.com (01/02/90)
I don't understand the meaning behind use the /etc/shadow file. All it does is holds the encrypted passwords, right? (like, AkhjfuDe2,md ) What's the use? Huy Nguyen
jik@athena.mit.edu (Jonathan I. Kamens) (01/03/90)
In article <21913@adm.BRL.MIL>, mwood!attcc!hpn@att.att.com writes: > I don't understand the meaning behind use the /etc/shadow file. All it does > is holds the encrypted passwords, right? (like, AkhjfuDe2,md ) > What's the use? I noticed that someone else gave a brief explanation of why publicly readable encrypted passwords can be a bad thing, but it wasn't very thorough, so I want to give a more detailed explanation. This is comp.unix.questions, and not comp.unix.wizards, after all. The password entries in the /etc/passwd file actually consist of two pieces of information. The first two characters are the "seed", which are fed to the crypt() library function (see the man page for it for more information) along with your plain-text password when the password is encrypte. The seed is used by the crypt() function to perturb the encryption algorithm in a way that will make different seeds produce different encrypted password string. More on the purpose of that later. The other characters (usually 11 of them) of the string in the /etc/passwd file are the encrypted password. Now, let's say that someone wants to break into your account, and since they don't know the various security holes that could allow them to become the super-user on any Unix machine :-), they want to do so by finding out what your password is. They have the following tools to help them: 1. A dictionary of commonly used passwords. 2. A very fast machine to work on at their leisure (not a mandatory thing, but good to have. 3. A program to use to break your password. What the program does it take each word in the password dictionary and encrypt it using the seed in the /etc/passwd file. Then, it checks if the encrypted string which is returned is the same as your encrypted password string, and if it is, it has found your password! Now, a few notes about this method of attack. First of all, the crypt() library routine is specifically designed to be slow, even on a fast machine. There are MUCH faster crypt() routines available, and the attacker may be using one of those routines instead of the default Unix version. Second, the seed plays an important role in making an attack on the /etc/passwd file more difficult. If the crypt() routine did not use seeds, then the attacker would have a much easier time of it -- all he would have to do is encrypt the entire dictionary once, and then store the resulting database of passwords and associated encrypted strings in a file somewhere. Then, he could compare each encrypted string to each encrypted string in the /etc/passwd file and thus find out a lot of passwords. The seed mechanism thwarts this by giving users different seeds (there are 4096 different possible seeds, although in practice it is not normal for even close to that many different seeds to actually get used -- another problem), so that each possible password must be encrypted in each user's seed in order to check if it is the correct password. So, this brings us to the question, "What is the advantage of an /etc/shadow file?" If the encrypted password strings are removed from the /etc/passwd file and placed in /etc/shadow instead, then an attacker can't use the mechanisms described above in order to figure out someone's password, since he doesn't have the encrypted password strings to work with. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-4261 Home: 617-782-0710
stripes@eng.umd.edu (Joshua Osborne) (01/03/90)
In article <21913@adm.BRL.MIL> mwood!attcc!hpn@att.att.com writes: >I don't understand the meaning behind use the /etc/shadow file. All it does >is holds the encrypted passwords, right? (like, AkhjfuDe2,md ) >What's the use? With the encrypted passwords in /etc/passwd anyone can read them and then try to hack them. When they are stored in a shadow file that file is normally readable to root, or some passwd group. That makes it mutch harder to get at. Of corse this makes it harder for both crackers, and people who want to do something useful with them (i.e. xlock- a program that locks your X display untill you type your password). Every silver lineing has its cloud... -- stripes@wam.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Mutitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. - Fred Brooks, Jr.
exspes@gdr.bath.ac.uk (P E Smee) (01/03/90)
In article <1990Jan2.222052.915@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > Now, let's say that someone wants to break into your account, and >since they don't know the various security holes that could allow them >to become the super-user on any Unix machine :-), they want to do so by >finding out what your password is. They have the following tools to help them: > >What the program does it take each word in the password dictionary and >encrypt it using the seed in the /etc/passwd file. Then, it checks if >the encrypted string which is returned is the same as your encrypted >password string, and if it is, it has found your password! Unstated, but implicit, is the fact that it is even worse if the perpetrator just wants to break *some* password(s), not necessarily yours. Having encrypted a 'trial' password once, it can then be checked against all encrypted passwords in /etc/passwd to see if it gets any hits. A few years ago a couple of our undergrads used this approach against our Multics system. (On Multics the password file was not normally readable by the public, but a change in default access settings at a new system release created a 'window' at our site during which the U/Gs grabbed a copy.) By the time we found the parties involved, they had cracked on the order of 85% of the passwords on the system using this approach. (Something like 25 users were using 'hello', sigh.) Having access to so many accounts, they were even doing their cracking on Multics -- but in 'invisibly-named' directories which appeared to belong to other people, scattered liberally throughout the system. -- 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)
jik@athena.mit.edu (Jonathan I. Kamens) (01/04/90)
In article <1990Jan3.103141.9903@gdt.bath.ac.uk>, exspes@gdr.bath.ac.uk (P E Smee) writes: > Unstated, but implicit, is the fact that it is even worse if the perpetrator > just wants to break *some* password(s), not necessarily yours. Having > encrypted a 'trial' password once, it can then be checked against all > encrypted passwords in /etc/passwd to see if it gets any hits. (I'm not sure if you already know this, but it sounds like you don't -- I may just be understanding what you're trying to say wrong.) No, that's the whole point of the seed. The seed is *different* for each encrypted password in the /etc/passwd file (or, at the very least, there are a number of different seeds), so trial passwords must be encrypted in each possible seed before they can be compared to encrypted passwords. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
mercer@ncrcce.StPaul.NCR.COM (Dan Mercer) (01/04/90)
In article <1990Jan2.222052.915@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: :In article <21913@adm.BRL.MIL>, mwood!attcc!hpn@att.att.com writes: :> I don't understand the meaning behind use the /etc/shadow file. All it does :> is holds the encrypted passwords, right? (like, AkhjfuDe2,md ) :> What's the use? : : I noticed that someone else gave a brief explanation of why publicly :readable encrypted passwords can be a bad thing, but it wasn't very :thorough, so I want to give a more detailed explanation. This is :comp.unix.questions, and not comp.unix.wizards, after all. : : The password entries in the /etc/passwd file actually consist of two :pieces of information. The first two characters are the "seed", which :are fed to the crypt() library function (see the man page for it for :more information) along with your plain-text password when the password :is encrypte. The seed is used by the crypt() function to perturb the :encryption algorithm in a way that will make different seeds produce :different encrypted password string. More on the purpose of that later. : : The other characters (usually 11 of them) of the string in the :/etc/passwd file are the encrypted password. : : Now, let's say that someone wants to break into your account, and :since they don't know the various security holes that could allow them :to become the super-user on any Unix machine :-), they want to do so by :finding out what your password is. They have the following tools to help them: : : 1. A dictionary of commonly used passwords. : 2. A very fast machine to work on at their leisure (not a mandatory thing, : but good to have. : 3. A program to use to break your password. : :What the program does it take each word in the password dictionary and :encrypt it using the seed in the /etc/passwd file. Then, it checks if :the encrypted string which is returned is the same as your encrypted :password string, and if it is, it has found your password! : : Now, a few notes about this method of attack. First of all, the :crypt() library routine is specifically designed to be slow, even on a :fast machine. There are MUCH faster crypt() routines available, and the :attacker may be using one of those routines instead of the default Unix :version. : : Second, the seed plays an important role in making an attack on the :/etc/passwd file more difficult. If the crypt() routine did not use :seeds, then the attacker would have a much easier time of it -- all he :would have to do is encrypt the entire dictionary once, and then store :the resulting database of passwords and associated encrypted strings in :a file somewhere. Then, he could compare each encrypted string to each :encrypted string in the /etc/passwd file and thus find out a lot of :passwords. The seed mechanism thwarts this by giving users different :seeds (there are 4096 different possible seeds, although in practice it :is not normal for even close to that many different seeds to actually :get used -- another problem), so that each possible password must be :encrypted in each user's seed in order to check if it is the correct password. : : So, this brings us to the question, "What is the advantage of an :/etc/shadow file?" If the encrypted password strings are removed from :the /etc/passwd file and placed in /etc/shadow instead, then an attacker :can't use the mechanisms described above in order to figure out :someone's password, since he doesn't have the encrypted password strings :to work with. : :Jonathan Kamens USnail: :MIT Project Athena 11 Ashford Terrace :jik@Athena.MIT.EDU Allston, MA 02134 :Office: 617-253-4261 Home: 617-782-0710 Check out Cliff Stoll's great book the _Cuckoo's Egg_ in which he describes how he unearthed a West German spy ring preying on the ARPANET. One of the first thing the intruder did was to steal /etc/passwd. He seemed to have no trouble at all cracking passwords using the methods you described. Of course, simply choosing intelligent passwords would have prevented this - no words appearing in dictionaries - no proper names - interspersing alphabeticals with numerics or control characters. Of course, a lot of the breakins came from no passwords assigned at all. Anyway, great book. Must read for anyone in this business. Hell, great book for anyone period. -- Dan Mercer Reply-To: mercer@ncrcce.StPaul.NCR.COM (Dan Mercer)
exspes@gdr.bath.ac.uk (P E Smee) (01/04/90)
In article <1990Jan3.204103.9684@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: >In article <1990Jan3.103141.9903@gdt.bath.ac.uk>, exspes@gdr.bath.ac.uk >(P E Smee) writes: >> Unstated, but implicit, is the fact that it is even worse if the perpetrator >> just wants to break *some* password(s), not necessarily yours. Having >> encrypted a 'trial' password once, it can then be checked against all >> encrypted passwords in /etc/passwd to see if it gets any hits. > > (I'm not sure if you already know this, but it sounds like you don't >-- I may just be understanding what you're trying to say wrong.) > > No, that's the whole point of the seed. The seed is *different* for >each encrypted password in the /etc/passwd file (or, at the very least, >there are a number of different seeds), so trial passwords must be >encrypted in each possible seed before they can be compared to encrypted >passwords. Yep, I know that but chose to ignore it in interests of simplicity. It is (still) much faster (and very effective) to encrypt each potential password (say, the spell-check dictionary plus a list of common first names) with each possible seed, and check against all encrypted passwords in /etc/passwd to see if you get any hits, than to try to crack a particular password. (There are, as I recall, only a small number of seeds -- 4k-ish, maybe?) And (as our crackers did on Multics) each time you acquire a new password, you can use that userid to take over part of the list of words to check, so you get multi-tasking cracking, without imposing a suspicious increase in resource use on any userid. (You can also somewhat cover your tracks by putting the 'smoking gun' files into the filespace of some innocent bystander whose account you've subverted.) What I'm not aware of is how the seed is chosen for a user. If it is anything other than random, then you can actually put some subtlety in the trawling algorithm to speed it up. (Multics used the password as both data-to-encrypt, and as the seed for encryption. This was *claimed* to make it harder to decrypt a particular encrypted password that you'd found, but actually made the trawling method easier.) Whether a trawl is 'acceptable' depends on why you want to crack the system. Our crackers were registered users who wanted more resources than we had allocated them. So, cracking a privileged id wasn't necessary. *Any* cracked ID would let them at more CPU and disk space. Any cracked 'academic staff' ID would get them network access. By checking 'last login date' in the greetings message each time they first logged into a newly cracked account, they could make an educated judgement as to whether the person was a frequent user, and so as to how likely he or she was to notice the illicit use. I'd add in passing that I question the wisdom of putting 'last logged in at' into the startup greeting. My experience is that (as above) it can be useful for crackers, and that it gains you next to nothing in security terms, as the vast majority of legitimate users don't pay any attention to it at all -- just part of the noise the machine spits at you when you log on, to be ignored. -- 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)
mchinni@pica.army.mil (Michael J. Chinni, SMCAR-CCS-E) (01/05/90)
In article dated <3 Jan 90 20:41:03 GMT> Jonathan Kamens writes: > In article <1990Jan3.103141.9903@gdt.bath.ac.uk>, exspes@gdr.bath.ac.uk > (P E Smee) writes: > > Unstated, but implicit, is the fact that it is even worse if the perpetrator > > just wants to break *some* password(s), not necessarily yours. Having > > encrypted a 'trial' password once, it can then be checked against all > > encrypted passwords in /etc/passwd to see if it gets any hits. > > No, that's the whole point of the seed. The seed is *different* for > each encrypted password in the /etc/passwd file (or, at the very least, > there are a number of different seeds), so trial passwords must be > encrypted in each possible seed before they can be compared to encrypted > passwords. The encryption of a trial password with all possible seeds may be required to guarentee a match, I don't think it is neccessary for a match. The way I understand the password encryption is that multiple different clear-text passwords will NEVER encrypt to the same encrypted password. Given you encrypt a trial password, and then check it against the /etc/passwd file. Doing this you are not assured of finding all accounts whose password is the same as your trial one, but you may find a match (which would mean you matched clear-text and seed). /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Michael J. Chinni Chief Scientist, Simulation Techniques and Workplace Automation Team US Army Armament Research, Development, and Engineering Center User to skeleton sitting at cobweb () Picatinny Arsenal, New Jersey and dust covered workstation () ARPA: mchinni@pica.army.mil "System been down long?" () UUCP: ...!uunet!pica.army.mil!mchinni /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
jik@athena.mit.edu (Jonathan I. Kamens) (01/05/90)
In article <21966@adm.BRL.MIL>, mchinni@pica.army.mil (Michael J. Chinni, SMCAR-CCS-E) writes: > The encryption of a trial password with all possible seeds may be required to > guarentee a match, I don't think it is neccessary for a match. The way I > understand the password encryption is that multiple different clear-text > passwords will NEVER encrypt to the same encrypted password. First of all, I think you're missing an "although" as the first word in the first sentence above, because otherwise it doesn't really make any sense. Second, I have never heard it said that multiple different clear-text passwords will never encrypted to the same encrypted password; what I have heard is that the odds of that happening are so miniscule that it is considered an impossibility from the viewpoint of practicality. That's different (although it isn't all that different :-), from saying that it'll never happen. > Given you encrypt a trial password, and then check it against the /etc/passwd > file. Doing this you are not assured of finding all accounts whose password is > the same as your trial one, but you may find a match (which would mean you > matched clear-text and seed). There are (theoretically) 4096 different possible seeds for each password in the /etc/passwd file. Therefore, any time you pick an arbitrary seed and encrypt a password in it, even if you have correctly picked the password of someone in the /etc/passwd file, the odds are (once again, theoretically only) one in 4096 that you have picked the right seed in which to encrypt that password. Given those odds, a method of attack which picks arbitrary seeds in which to encrypt the /etc/passwd and then compares encrypted words against the strings in the /etc/passwd file without taking into account individual seeds is, as I have already pointed out, stupid. HOWEVER (and this is a big however, hence the upper case), if you do have a very fast machine with a very large disk, then it becomes feasible to encrypt all word guesses in all seeds, and store the results in a dbm (or similar technology) database file using the encrypted key as the dbm key. Assuming 1000 encryptions per second (which is achievable by some machines with some crypt algorithms, a 10000 word dictionary (which is actually relatively small; the dictionary we use to check passwords here has 120000 words in it), and an /etc/passwd file with all 4096 seeds represented in it, then the time to build the database (not taking into account disk I/O, which will slow it down considerably in most cases) is: 10000 words * 4096 seeds / 1000 encryptions per second = 40960 seconds = less than 12 hours The amount of space necessary would be (I include the size of the word in the storage size for each seed because if you use the encrypted string as the key and then store the word as the value for that key you'll need to store the word for each key generated): 10000 words * 4096 seeds * (4 characters per word average length + 13 characters per seed) = about 700 meg Now, even with very bad disks, you can generate the file in less then a week on a drive like an DEC RA90 (which has over a gig of space on it). Once the file is generated, you read in the /etc/passwd file and look up each encrypted key in the dbm database; if you find a hit, you've immediately located the user's password. You're a lot better off doing things that way than picking random arbitrary strings and crossing your fingers and hoping for a match -- whatever your odds are of getting a match, they are divided by 4096 if you don't cover all the possible keys. All this goes to show you that (a) you should pick good passwords, and (b) you should use kerberos :-). Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
ccel@chance.uucp (CCEL) (01/05/90)
In article <1990Jan3.103141.9903@gdt.bath.ac.uk> exspes@gdr.bath.ac.uk (P E Smee) writes: >In article <1990Jan2.222052.915@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: >>What the program does it take each word in the password dictionary and >>encrypt it using the seed in the /etc/passwd file. Then, it checks if >>the encrypted string which is returned is the same as your encrypted >>password string, and if it is, it has found your password! > >Unstated, but implicit, is the fact that it is even worse if the perpetrator >just wants to break *some* password(s), not necessarily yours. Having >encrypted a 'trial' password once, it can then be checked against all >encrypted passwords in /etc/passwd to see if it gets any hits. Funny you should mention this, my roommate ran a program that does just this on our college's Ultrix machine (i'll leave out the names). Just as a test, he wanted to find all the users whose passwords were the same as their login names. He "cracked" about 35 passwords on the first pass, including about 25 faculty accounts (kind of disturbing that CS faculty members would be so careless with their passwords). The University ended up charging him about $2800.00, something about misuse of computer time... Randy Tidd rtidd@mwsun@mitre.org #define DISCLAIM TRUE
tanner@cdis-1.UUCP (Dr. T. Andrews) (01/06/90)
In <1990Jan4.202253.27867@athena.mit.edu>, jik@athena.mit.edu (Jonathan I. Kamens) writes...
) [ scheme to encrypt all probable passwords with all seeds ]
Given a password file for a machine with fewer than 4096 users, a
considerable savings of resources may be had by simply encrypting
all probable passwords with only the seeds actually present in
the password file.
For a system with 10 legitimate users, you should need at most
10 encryptions \(em less if two or more passwords share a seed.
For a system with 4000 legitimate users, this doesn't work out
as well. Concentrate on password-guessing for "root" or the owner
of the files in which you are interested.
--
{attctc gatech!uflorida}!ki4pv!cdis-1!tanner {bpa uunet}!cdin-1!cdis-1!tannerjoeg@polygen.uucp (Joe Gaudreau) (01/06/90)
>Jonathan Kamens: > No, that's the whole point of the seed. The seed is *different* for ... >encrypted in each possible seed before they can be compared to encrypted >passwords. True true. The set of characters for the salt & encrypted string is [a-zA-Z0-9./], which is 64 characters total. A two character salt results in 64^2 == 4096 different salts. Let's check how safe we really are. What if you know how long a password is? How do you find out? Well, maybe you *heard* them type it in? No, then worst case is to try all lengths (but check common lengths first, etc). Do you know what the salt is? No, then worst case test. So: Disclaimer: I'm not a real mathematician, so I could maybe ;-) have made a mistake. I hope not. 1) 256 element set - worst case search: Len Combinations (known salt) Combinations * 4096 --- ----------------------------------- ------------------------------ 1 256^1 = 256 1,048,576 2 256^2 = 65,536 268,435,456 3 256^3 = 16,777,216 68,719,476,736 4 256^4 = 4,294,967,296 17,592,186,044,416 5 256^5 = 1,099,511,627,776 4,503,599,627,370,496 6 256^6 = 281,474,976,710,656 1,152,921,504,606,846,976 7 256^7 = 72,057,594,037,927,936 295,147,905,179,352,825,856 8 256^8 = 18,446,744,073,709,551,616 75,557,863,725,914,323,419,136 -------------------------- ------------------------------- Total = 18,519,084,246,547,628,288 75,854,169,073,859,085,467,648 2) 96 element set - based on ascii 32-127 set, common keyboard set: Len Combinations (known salt) Combinations * 4096 --- ----------------------------------- ------------------------------ 1 96^1 = 96 393,216 2 96^2 = 9,216 37,748,736 3 96^3 = 884,736 3,623,878,656 4 96^4 = 84,934,656 347,892,350,976 5 96^5 = 8,153,726,976 33,397,665,693,696 6 96^6 = 782,757,789,696 3,206,175,906,594,816 7 96^7 = 75,144,747,810,816 307,792,887,033,102,336 8 96^8 = 7,213,895,789,838,336 29,548,117,155,177,824,256 --------------------- -------------------------- Total = 7,289,831,534,994,528 29,859,149,967,337,586,688 3) 36 element set based on single case alphabet and digits: Len Combinations (known salt) Combinations * 4096 --- ----------------------------------- ------------------------------ 1 36^1 = 36 147,456 2 36^2 = 1,296 5,308,416 3 36^3 = 46,656 191,102,976 4 36^4 = 1,679,616 6,879,707,136 5 36^5 = 60,466,176 247,669,456,896 6 36^6 = 2,176,782,336 8,916,100,448,256 7 36^7 = 78,364,164,096 320,979,616,137,216 8 36^8 = 2,821,109,907,456 11,555,266,180,939,776 ----------------- ---------------------- Total = 2,901,713,047,668 11,885,416,643,248,128 4) 26 element set set on just single case alphabet. Len Combinations (known salt) Combinations * 4096 --- ----------------------------------- ------------------------------ 1 26^1 = 26 106,496 2 26^2 = 676 2,768,896 3 26^3 = 17,576 71,991,296 4 26^4 = 456,976 1,871,773,696 5 26^5 = 11,881,376 48,666,116,096 6 26^6 = 308,915,776 1,265,319,018,496 7 26^7 = 8,031,810,176 32,898,294,480,896 8 26^8 = 208,827,064,576 855,355,656,503,296 ----------------- ---------------------- Total = 217,180,147,158 889,569,882,759,168 Well, the numbers are still pretty big even for set #4 but are they big enough? Do you have enough protection should someone know that the root password is 5 characters long and only made up of letters (a common practice as a site I visited). Fast crypt(3) routines are available. So THEY changed the constant string - it can be found out. Looks like shadow passwds are VERY convincing... YADisclaimer: I may have made some really bad mistakes here, I hope not. If you should happen to find some, let me know. Helpful criticism is quite useful. Flames without substance help nobody and don't bother someone who lives in hell =:->... --- Joe Gaudreau "Juggling, not just a way of life" ZePhone: (617)890-2888 ARPA: joeg@polygen.com UUCP: {princeton,mit-eddie,bu.edu,sunne}!polygen!joeg UsSnail: Polygen Corporation, 200 5th Ave, Waltham, MA 02254
jik@athena.mit.edu (Jonathan I. Kamens) (01/09/90)
In article <0000041@cdis-1.UUCP>, tanner@cdis-1.UUCP (Dr. T. Andrews) writes: > Given a password file for a machine with fewer than 4096 users, a > considerable savings of resources may be had by simply encrypting > all probable passwords with only the seeds actually present in > the password file. > > For a system with 10 legitimate users, you should need at most > 10 encryptions \(em less if two or more passwords share a seed. This is true. I was assuming that since the database being built is very large, it would be useful to build it with all possible seeds and then to use it to work on more than one file of passwords. After all, if you've got a machine with that much computron-power and that much disk space, you don't want to waste it by only trying to break into one machine, right :-)? Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
exspes@gdr.bath.ac.uk (P E Smee) (01/13/90)
In article <657@hepburn.UUCP> joeg@hepburn.UUCP (Joe Gaudreau) writes: > >Well, the numbers are still pretty big even for set #4 but are they big >enough? Do you have enough protection should someone know that the root >password is 5 characters long and only made up of letters (a common practice >as a site I visited). Fast crypt(3) routines are available. So THEY changed >the constant string - it can be found out. Looks like shadow passwds >are VERY convincing... Our experience when our Multics passwords were absconded with is that about 85% of users' passwords will be either (1) their username; (2) their real name -- bit harder to mechanically break; or (3) a word of between 4 and 8 characters which can be found in the system's spell-checking dictionary. Ignoring (2) and assuming you are trawling the passwords, that means that you need NUsers uses of crypt to check case (1) for all users, and at worst 4096*(wc -w dictionary) for case (3). For a dictionary size of about 20000 words, that's a mere 80,000,000 tries -- probably less since you can prbably ignore words outside the 4-8 char range. Can also take advantage of knowledge which will allow you at any point to only worry about seeds which are still in use for passwords which remain uncracked. Not intractable, specially if you can involve an integer-capable vector processor in your work. (One hopes that people responsible for privileged accounts are more clever with their passwords.) Some systems try to impose restrictions on what you can choose as a password. Sometimes these actually help break in. If you impose a 6-char minimum, for example, then the probability is that the passwords will be words between 6 and 8 chars which are in the spell-checking dictionary. You've just cut down the number of cases to check. If you require at least one uppercase letter, odds are that the user will uppercase either the First, or ALL, letters, because that's easier than shifting in mid-word. If you require at least one non-alpha, odds are that the user will take a word meeting the criteria above, and tack a digit or two on the end. Again, that's easier to type. So, a non-alpha may gain a little, but not as much as you'd expect from a simple alphabet**length calculation. (Does, though, decrease the chance that you can break multiple users by a single encryption.) Since (we'll assume) any serious privileged user will be cleverer about picking passwords, this does not particularly help if you want to crack 'root'. But, if you just want to break any passwords you can, the problem is not that difficult. -- 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)
tjo@its.bt.co.uk (Tim Oldham) (01/13/90)
In article <1990Jan4.111940.18769@gdt.bath.ac.uk> exspes@gdr.bath.ac.uk (P E Smee) writes: > >I'd add in passing that I question the wisdom of putting 'last logged >in at' into the startup greeting. My experience is that (as above) it >can be useful for crackers, and that it gains you next to nothing in >security terms, as the vast majority of legitimate users don't pay any >attention to it at all -- just part of the noise the machine spits at >you when you log on, to be ignored. Certainly that's the way I feel about most last-login messages. I rarely look at mine. However, I would say that this doesn't mean that it's useless, or that login messages per se are useless. At UKC, then the login messages (at least used to --- I guess they still do) told you *where* you last logged in from (all logins were via hardware PADs on the Cambridge ring). This was a very useful feature. Several times people changed their passwords because ``a friend of mine'' had accidentally used them from somewhere strange. I guess the social scientists whose logins had been hacked found it odd that the machine was telling them they'd last logged in from the 68000 Laboratory when they didn't even know where it was. On the grounds that it's minimal overhead, I think login messages are A Good Thing. Tim. -- Tim Oldham, BT Applied Systems. tjo@its.bt.co.uk or ...!ukc!axion!its!tjo Less is more, but not as much as more.
subbarao@phoenix.Princeton.EDU (Kartik Subbarao) (01/14/90)
I like the system messages, I think that the last login time is helpful --
Alas, there is always the dreaded .hushlogin :-|.
Anyway, as to "Giving" stuff away to crackers, the last login is easily
obtained by last (userid), so that does not make a difference really.
-Kartik Subbarao
--
subbarao@{phoenix,bogey or gauguin}.princeton.edu