dave@sea375.UUCP (David A. Wilson) (12/25/88)
With all the concern for control of access to passwords, even when encrypted, why now make passwords more integral to the kernel? The kernel could maintain passwords encrypted somewhere on the disk, but not directly accessible thru filesystem access. Special system calls would exist to store/retrieve encrypted passwords. The system calls could be restricted to root, and use would be recorded in an audit log(handle like process accounting logs) to detect password breakin attempts. The only security hole to fill would then be the prevention of obtaining passwords by direct access to the system disk. Perhaps the kernel could also audit any access to the disk blocks containing the passwords using the disk drivers directly(system backups must be able to backup these blocks although the audit log would record this). Single-user mode should support an optional password(separate from root) to control single-user access to the system. These changes should incur very little system overhead, some kernel code, some changes to disk drivers and few changes to existing admin programs. I think this would be more secure than current password file or the shadow password file. Any comments? Think about it, -- David A. Wilson uw-beaver!tikal!slab!sea375!dave
bzs@Encore.COM (Barry Shein) (12/28/88)
>With all the concern for control of access to passwords, even when encrypted, >why now make passwords more integral to the kernel? The kernel could maintain >passwords encrypted somewhere on the disk, but not directly accessible thru >filesystem access. Special system calls would exist to store/retrieve encrypted >passwords. The system calls could be restricted to root, and use would be >recorded in an audit log(handle like process accounting logs) to detect >password breakin attempts. > >I think this would be more secure than current password file or the shadow >password file. Any comments? Yes, somewhere and at some time we are going to have to do the hard work of analyzing whether or not hiding encryptions improves security as a general principle (as opposed to coming up with new ways to hide them before doing the ground work.) Hiding something indicates that it is dangerous if revealed. It says, basically, that encryption technology is inadequate and cannot be made to work, the only reasonable protection is secrecy. Do we honestly believe this? Or, worse, do we believe that security is attained by layering anything we can think of onto the system? -Barry Shein, ||Encore||
schwartz@cs.swarthmore.edu (Scott Schwartz) (12/29/88)
>Hiding something indicates that it is dangerous if revealed. It says, >basically, that encryption technology is inadequate and cannot be made >to work, the only reasonable protection is secrecy. Do we honestly >believe this? Or, worse, do we believe that security is attained by >layering anything we can think of onto the system? At least in terms of the current UNIX password scheme, I have the uncomfortable feeling that it is NOT adequate. I'll bet that 99% of the people reading this have either used or seen a program that finds a substantial number of passwords on a given system by encrypting the dictionary against /etc/passwd. Put it this way: every other part of unix has evolved, why not allow the password protection scheme to evolve too? As it happens, I think that Barry has a good point here. I think one answer is to admit that 8 character passwords (and user id's, for that matter!) are too small. Someone who knows a lot about encryption (not me!) should suggest a better number. -- Scott Schwartz <schwartz@cs.swarthmore.edu> <psuvax1!vu-vlsi!swatsun!schwartz>
heilpern@ibd.BRL.MIL (Mark A. Heilpern ) (12/29/88)
In article <2271@pompeii.cs.swarthmore.edu> schwartz@pompeii.UUCP (Scott Schwartz) writes: }>Hiding something indicates that it is dangerous if revealed. It says, }>basically, that encryption technology is inadequate and cannot be made }>to work, the only reasonable protection is secrecy. Do we honestly }>believe this? Or, worse, do we believe that security is attained by }>layering anything we can think of onto the system? > }At least in terms of the current UNIX password scheme, I have the }uncomfortable feeling that it is NOT adequate. I'll bet that }99% of the people reading this have either used or seen a program }that finds a substantial number of passwords on a given system by }encrypting the dictionary against /etc/passwd. } }Put it this way: every other part of unix has evolved, why not allow }the password protection scheme to evolve too? > }As it happens, I think that Barry has a good point here. I think }one answer is to admit that 8 character passwords (and user id's, }for that matter!) are too small. Someone who knows a lot about }encryption (not me!) should suggest a better number. >-- }Scott Schwartz <schwartz@cs.swarthmore.edu> <psuvax1!vu-vlsi!swatsun!schwartz> I do not believe the size of the password has to be the matter of importance here. A password which exists in /usr/dict can be decoded in a liberal 80 hours, IF the cpu is so tied up that it takes a complete second to test one word, and only testing the 290,232 words [on my machine] that are longer than 5 characters. If the 2-letter key used in encryption were not known, this boosts the 80 hour upper end to ~37 years. (80 hours * 4096 methods of encryption) Why not store the key in an unreadable file? Newsgroups: comp.unix.wizards Subject: Re: Password security - Another idea Summary: Expires: References: <228@sea375.UUCP> <4497@xenna.Encore.COM> <2271@pompeii.cs.swarthmore.edu> Sender: Reply-To: heilpern@brl.arpa (Mark A. Heilpern (IBD) <heilpern>) Followup-To: Distribution: Organization: Ballistic Research Lab (BRL), APG, MD. Keywords: In article <2271@pompeii.cs.swarthmore.edu> schwartz@pompeii.UUCP (Scott Schwartz) writes: >>Hiding something indicates that it is dangerous if revealed. It says, >>basically, that encryption technology is inadequate and cannot be made >>to work, the only reasonable protection is secrecy. Do we honestly >>believe this? Or, worse, do we believe that security is attained by >>layering anything we can think of onto the system? > >At least in terms of the current UNIX password scheme, I have the >uncomfortable feeling that it is NOT adequate. I'll bet that >99% of the people reading this have either used or seen a program >that finds a substantial number of passwords on a given system by >encrypting the dictionary against /etc/passwd. > >Put it this way: every other part of unix has evolved, why not allow >the password protection scheme to evolve too? > >As it happens, I think that Barry has a good point here. I think >one answer is to admit that 8 character passwords (and user id's, >for that matter!) are too small. Someone who knows a lot about >encryption (not me!) should suggest a better number. >-- >Scott Schwartz <schwartz@cs.swarthmore.edu> <psuvax1!vu-vlsi!swatsun!schwartz> Newsgroups: comp.unix.wizards Subject: Re: Password security - Another idea Summary: Expires: References: <228@sea375.UUCP> <4497@xenna.Encore.COM> <2271@pompeii.cs.swarthmore.edu> Sender: Reply-To: heilpern@brl.arpa (Mark A. Heilpern (IBD) <heilpern>) Followup-To: Distribution: Organization: Ballistic Research Lab (BRL), APG, MD. Keywords: In article <2271@pompeii.cs.swarthmore.edu> schwartz@pompeii.UUCP (Scott Schwartz) writes: >>Hiding something indicates that it is dangerous if revealed. It says, >>basically, that encryption technology is inadequate and cannot be made >>to work, the only reasonable protection is secrecy. Do we honestly >>believe this? Or, worse, do we believe that security is attained by >>layering anything we can think of onto the system? > >At least in terms of the current UNIX password scheme, I have the >uncomfortable feeling that it is NOT adequate. I'll bet that >99% of the people reading this have either used or seen a program >that finds a substantial number of passwords on a given system by >encrypting the dictionary against /etc/passwd. > >Put it this way: every other part of unix has evolved, why not allow >the password protection scheme to evolve too? > >As it happens, I think that Barry has a good point here. I think >one answer is to admit that 8 character passwords (and user id's, >for that matter!) are too small. Someone who knows a lot about >encryption (not me!) should suggest a better number. >-- >Scott Schwartz <schwartz@cs.swarthmore.edu> <psuvax1!vu-vlsi!swatsun!schwartz> Newsgroups: comp.unix.wizards Subject: Re: Password security - Another idea References: <228@sea375.UUCP> <4497@xenna.Encore.COM> <2271@pompeii.cs.swarthmore.edu> Reply-To: heilpern@brl.arpa (Mark A. Heilpern (IBD) <heilpern>) Organization: Ballistic Research Lab (BRL), APG, MD. In article <2271@pompeii.cs.swarthmore.edu> schwartz@pompeii.UUCP (Scott Schwartz) writes: >>Hiding something indicates that it is dangerous if revealed. It says, >>basically, that encryption technology is inadequate and cannot be made >>to work, the only reasonable protection is secrecy. > >At least in terms of the current UNIX password scheme, I have the >uncomfortable feeling that it is NOT adequate. I'll bet that >99% of the people reading this have either used or seen a program >that finds a substantial number of passwords on a given system by >encrypting the dictionary against /etc/passwd. > >Put it this way: every other part of unix has evolved, why not allow >the password protection scheme to evolve too? > >As it happens, I think that Barry has a good point here. I think >one answer is to admit that 8 character passwords (and user id's, >for that matter!) are too small. Someone who knows a lot about >encryption (not me!) should suggest a better number. >Scott Schwartz <schwartz@cs.swarthmore.edu> <psuvax1!vu-vlsi!swatsun!schwartz> I do not believe the size of the password has to be the matter of importance here. A password which exists in /usr/dict can be decoded in a liberal 80 hours, IF the cpu is so tied up that it takes a complete second to test one word, and only testing the 290,232 words [on my machine] that are longer than 5 characters. If the 2-letter key used in encryption were not known, this boosts the 80 hour upper end to ~37 years. (80 hours * 4096 methods of encryption) Why not store the key in an unreadable file? -- |\/| | | | _ |< / \_(_(_)\_/ \______
jobusch@atanasoff.cs.iastate.edu (David L. Jobusch) (12/30/88)
In article <2271@pompeii.cs.swarthmore.edu> schwartz@pompeii.UUCP (Scott Schwartz) writes: >As it happens, I think that Barry has a good point here. I think >one answer is to admit that 8 character passwords (and user id's, >for that matter!) are too small. Someone who knows a lot about >encryption (not me!) should suggest a better number. >-- >Scott Schwartz <schwartz@cs.swarthmore.edu> <psuvax1!vu-vlsi!swatsun!schwartz> Part of a project I am working on now uses a technique my major professor describes in a paper to compress an ARBITRARY length password (or better, a pass-phrase) into the 56 bit DES key. The goal is to allow the arbitrary length passwords to "fit" into the current password mechanisms without breaking too much software (uses /etc/passwd, field sizes stay the same, staying away from "shadow" files, etc...). I, too, would be interested in hearing arguments for and against various restrictions on passwords. User frustration with picky mechanisms (must use a ... ) around my office usually leads to root setting the person's password to "hi" or something equally secure. (I would appreciate replies through email; will post summary if needed.) Dave Jobusch, Iowa State University Telecommunications jobusch@atanasoff.cs.iastate.edu j1.dlj@isumvs.bitnet (ick) ^^^^^^^^^ As in John Vincent Atanasoff, the creator of the world's first electronic digital computer, built at ISU. Spread the news.
bzs@Encore.COM (Barry Shein) (12/30/88)
Ok, this is getting ridiculous... Can we assume that before we make exotic changes like shadow passwords we can make simple changes (some Unix's already have these) to the passwd changing programs like: 1. Some mixture of upper case, lower case, digits and/or punctuations. 2. No dictionary words (even mixed case.) 3. Can't use login name, system name and a bunch of other easily checked words or patterns (3 digits, dash, 4 digits.) 4. Must be eight chars (or 7 if you're not that paranoid.) 5. Finally, will educate users about how to choose a good password (maybe we can group-write a document about just that, that would be a useful outcome of this conversation.) This is trivial and can be enforced relatively easily without changing all sorts of system software, only one program needs to be modified. Something has to be tacit, every time someone says that eight chars from a 64 or 100 char set should be sufficient someone else jumps up and says "not if they're all lower-case!", assume when we say "from 100 chars" we mean we'll make it hard to search less, not "from 100 chars or any number less down to one". And let's let the conversation about more exotic methods (password aging, shadow password files, anything beyond influencing a reasonable choice of a good password in the first place which some of us claim is sufficient) proceed from there instead of going round and round in circles. *Think*, people, how in the world can password aging protect against choosing a word from the dictionary (as one poster just claimed.) I can crack that looooong before your password ages (unless it ages every few minutes.) It's a worthwhile topic, let's not let it degenerate due to thoughtlessness. -Barry Shein, ||Encore||
heilpern@ibd.BRL.MIL (Mark A. Heilpern ) (12/30/88)
Here's an interesting idea: Let's assume a users password is: physics This would most likely be solved in a routine dictionary search. Now let's assume his (her) password is: pHysIcs [I know, too hard to remember, please put flames on hold.] I don't know of any simple way to do a dictionary search on this and come up successful in a "short" amount of time. Now, the issue of remembering case: Suppose, among the standard dot files in the home directory, there was to be a new one: .case . The login program is to check this file, and if it has any permissions other than for owner, login is disabled. Once through this check, when the password is read from the user, it is converted to lower case, the .case file read [example .case below] and where appropriate, the case of a letter changed, before excryption for comparison to the /etc/passwd password. Of course, the passwd change program would also have to incorperate this. Flames can be sent to me personally at heilpern@brl.mil .case: lUllUll this is how the file would read for my pHysIcs example. it is not hard to see how this follows, l meaning lower and U meaning upper. ATTN: Would be flames: If you have a comment about the additional time required for the login process, I challenge you to come up with a quick and SECURE method. Mark A. Heilpern These are MY opinions only. If you like them, great. If you don't, great. -- |\/| | | | _ |< / \_(_(_)\_/ \______
bostic@ucbvax.BERKELEY.EDU (Keith Bostic) (12/31/88)
In article <4523@xenna.Encore.COM>, bzs@Encore.COM (Barry Shein) writes: > 5. Finally, will educate users about how to choose a good > password (maybe we can group-write a document about just > that, that would be a useful outcome of this conversation.) > > This is trivial and can be enforced relatively easily without changing > all sorts of system software, only one program needs to be modified. I find educating users to be a lot more than "trivial". And no matter how stringent your attempt to make the criteria, users will find a way to get a stupid password into the machine. I like some form of shadow passwords as a solution. Once they're in place, you no longer care what the user picks for a password, as long as it's N characters long and not the account name. Keith Bostic
paradis@maxzilla.Encore.COM (Jim Paradis) (12/31/88)
In article <4497@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: >Hiding something indicates that it is dangerous if revealed. It says, >basically, that encryption technology is inadequate and cannot be made >to work, the only reasonable protection is secrecy. Do we honestly >believe this? Or, worse, do we believe that security is attained by >layering anything we can think of onto the system? Hi, Barry! I think there's a subtle point that you're missing here: there's a difference between keeping a piece of information SECRET, and restricting ACCESS to it. It just so happens that on computers, we tend to use the same mechanisms to accomplish both. So keeping a password database inaccessible (by protections or shadowing or making it into a kernel object or what-have-you) does NOT imply that the information contained therein is necessarily a SECRET that must be hidden, but rather it implies that we need to restrict access to the information to prevent someone from taking it away and fiddling with it long enough to eventuall break it (by whatever means -- brute-force cracking, blind luck, sophisticated cryptanalysis, whatever). Here's an analogy: Suppose there's a room containing classified files. To prevent unauthorized access to the files, a lock is installed on the door. Now, if I (unauthorized) wanted to access the information, I could try to pick the lock. If I were allowed to sit in front of the door for as long as I wished, fiddling with the lock and trying various attacks on it, there's a chance that eventually I'd be able to pick the lock and access the information. It may be a very GOOD lock and require a long time to pick, but eventually I might get lucky. This is analogous to the current situation with UNIX password files: since the file is world-readable, I can conceivably make a copy of the file, take it home with me, load it onto my PeeCee, and hack on it at leisure. I might, by blind luck, stumble onto some useful passwords that way. In the case of the locked door, if we want to keep people from hacking on the lock and restrict the use of the lock to being opened with a proper key, we can post a guard at the door. Assuming that the guard cannot be bribed or otherwise made an accessory to an attack, s/he will prevent random hackery on the lock. Similarly, by burying the password information and restricting access to it, one can prevent random hackery on the password file. Oh, all right, I'll admit that it's probably possible to subvert the guard mechanism as well; HOWEVER, consider the following: each "hurdle" that we place in the way of a cracker has a probability P of being compromised. I submit, though, that in a useful system there's no such mechanism where P=0 (proof left as exercise to the reader 8-) ) Therefore, the best we can do is come up with a mechanism where P is (hopefully) quite small. If there are TWO hurdles to be overcome, then the probability of the composite mechanism being compromised is P1 * P2. Thus, by choosing an appropriate set of mechanisms, we can (hopefully) make the probability of compromise arbitrarily small. Recognize, though, that the smaller you make the probability, the more difficult the system becomes to use. Therefore, striking a balance between ease of use and security is a decision that each individual system adminstrator must make. Jim Paradis (paradis@encore.UUCP) 508-460-0500 Devout Secular Humanist and Worshipper of Bacchus in Vintage Years
tim@scsmo1.UUCP (12/31/88)
One thing to keep in mind is that a valid password may not be the same one the user set. For example the passwords iopwwe and wer4543 may encrypt to the same string. The is becuase of the DES method is nonreversable, you can find a valid password but you can't be sure it is the correct one. If you generate a 56 bit key from a phrase, all that happenes is that you generate more strings that will work. I think that the number of strings I like the idea of a 6+ char password with a non-alpha character in it works better as there are about 6.63e15 combinations with about 2.2e14 that most users might pick. The string approach has more combinations 7.1e139 but most people have a <20k word vocabulary, will use a common phrase, and 2^56 is 7.2e16. I would guess that the number of real strings to search is around 100,000. The other drawback is that the string is easy to watch someone type. tim hogard tim@scsmo1.uucp Soil Conservaion Service USDA
res@cbnews.ATT.COM (Robert E. Stampfli) (12/31/88)
Can anyone think of a good reason why either of the following should not be done on systems that employ a shadow password file: 1. Provide a program which returns the encrypted version of the password for the uid (or euid) that invokes it. 2. Provide a program, similar to "passwd", which modifies the encrypted password in the /etc/passwd file, like the original version of the passwd command did. You might, if you were really paranoid, restrict this so that the same password can not be used for both the /etc/passwd and shadow password file. Both if these, it would seem to me, would be useful in writing things like terminal lock programs (case 1), or programs that run set-uid to one account to allow users the ability to do something with files owned by that account, provided they possess the "public" password (case 2). Rob Stampfli att!cblpe!res (work) osu-cis!n8emr!kd8wk!res (home)
bzs@Encore.COM (Barry Shein) (01/01/89)
Re: using a .case file which shows the lower/upper case pattern for a password.... But this means that login will now accept the dictionary word in lower case? Seems to reopen that attack (ie. going thru the dictionary) as login is correcting case for me as I go. Worse, it relies on the unreadability of these .case files in every user's directory, I don't think that's a good thing to rely on, if users are sloppy about password choosing and too lazy to remember the case shifts why do you believe they'll be careful about protecting this .case file? Besides, holes to read unreadable files are a little too easy to come by (also, I assume that the length of the file tells me how many chars in your passwd?) I don't think this idea goes very far. -Barry Shein, ||Encore||
bzs@Encore.COM (Barry Shein) (01/01/89)
>I like some form of shadow passwords as a solution. Once they're in place, >you no longer care what the user picks for a password, as long as it's N >characters long and not the account name. > >Keith Bostic Round and round, and you're not disturbed at the fact that you're now relying on the unreadability of the shadow file? How many ways are there to read a read-protected file? How do you know it has been read by an unauthorized person (or a disgruntled employee)? If you suspect it has been read what is the appropriate action (I can answer that, change every password on the system, wotta nuisance.) I still contend we're all jumping at this shadow password idea because it's easy to implement and *seems* to improve security, not because it necessarily does improve security, it just changes the target slightly without solving the real problem (easy to crack password encryptions.) I honestly view shadow password files as a wonderful example of sweeping a problem under the rug. Note that /usr/lib/uucp/L.sys uses read protection to protect its passwords, how many people out there know who exactly has obtained a copy of their L.sys file? (who cares, it's other folks' systems, right? rrrriiight...) I say if you use encryption then use encryption, why not just store the passwords in the clear in this shadow file if we're all so sure it's secure? Uh huh, just as I thought... We're setting ourselves up for a fall cause even mediocre hackers will figure out ways to get a copy of this shadow file. -Barry Shein, ||Encore||
bzs@Encore.COM (Barry Shein) (01/01/89)
From: paradis@maxzilla.Encore.COM (Jim Paradis) >In the case of the locked door, if we want to keep people from hacking >on the lock and restrict the use of the lock to being opened with a proper >key, we can post a guard at the door. Assuming that the guard cannot be >bribed or otherwise made an accessory to an attack, s/he will prevent >random hackery on the lock. Similarly, by burying the password information >and restricting access to it, one can prevent random hackery on the >password file. It's more like burying it in your back yard hoping no one knows how to dig... That's the whole point really, positing an incorruptible guard makes it *sound* good, but of course no guard is incorruptible (or can be guaranteed to be 100% reliable.) Similarly with file systems. At least encryption algorithms are mathematical objects and, although one cannot prove 100% reliable they can measure confidence under a given set of conditions, and can modify those conditions if need be (eg. demand longer keys or larger character sets.) Just as a "guard" is subject to all sorts of unpredictable circumstances such as being late for work or sleeping on the job you can have similar attacks on something as complicated as a file system, like leaving a setuid program around for a while accidently (did anyone walk away with a copy of the shadow file while that program was there?) If we can posit a completely uncorruptible file system then hey, I'll agree with you. And as I mentioned before, let's just store the passwords in the clear in an unreadable file. The other problem of course is that all I need to do is photograph your lock to have compromised your security and there's no way for you to know if your lock has been photographed, that's another flaw in the analogy. I claim you'd be better off spending your money (guards cost money, no?) on a better door and lock rather than having to worry about the door, the lock and the guard too now. -Barry Shein, ||Encore||
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/02/89)
In article <4523@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: >Can we assume that before we make exotic changes like shadow passwords >we can make simple changes (some Unix's already have these) to the >passwd changing programs like: ... NO! The "easy-to-guess password" checks are not sufficient, and the accompanying restrictions are a royal pain in the user's ass. It has been argued that they result in REDUCED security! Exposing the encrypted password for anyone to see is FOLLY; it was barely excusable in the first place and is inexcusable now. The shadow password file (which is NOT "exotic"; in fact JHU/BRL PDP-11 UNIX had something of the sort many years ago) has already been implemented; so long as UNIX sticks to the general modified DES encryption scheme, hiding the encrypted passwords is a necessary security measure.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/02/89)
In article <4547@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: >I claim you'd be better off spending your money (guards cost money, >no?) on a better door and lock rather than having to worry about the >door, the lock and the guard too now. Quite apart from the dangers of reasoning by analogy, you miss some of the points about locks and encryption that are understood by professionals (both good guys and bad guys) in those fields. Locks serve a number of functions. Ordinary residence locks should be part of an overall residence security design sufficient to convince the typical random burglar to go elsewhere where there are easier pickings. Prime targets, say for industrial espionage, should impose a net expected cost/difficulty/risk of access in excess of the value beIng protected; combining several defenses that individually aren't quite good enough generally will suffice. On other occasions, it is more important (perhaps for insurance reasons) to obtain concrete evidence of entry than to make entry harder but undetectable when it does occur. All these examples provide useful analogies for points that could be made with regard to password security. Note also that the layman, and even many locksmiths, are poor judges of what constitutes a "better" lock. I've been known to "waltz through" supposedly maximum-security locks; in one case, simply rapping a highly-rated padlock in the right spot with a piece of wood would cause it to pop open! Similarly, laymen and even the "professionals" in the open cryptological community often cannot properly evaluate the strength of a proposed cryptosystem. When I hear discussion of how long a "brute force" search would take, I tune out; sure, the system needs to be good enough under a brute-force attack, but that is by no means sufficient. In fact actual cryptanalysis normally reserves brute-force searches for those cases where more clever analytical methods have managed to drastically narrow the space to be searched. Time and time again, "proven secure" cryptosystems have been cracked by good cryptanalysis. The moral, if there is one, is that it is hard to reliably judge matters of security, and one should enlist the aid of experienced security defeaters in the process (preferably professionals). The other major point is that combination of several good defenses can result in an excellent defense. Thus, making the encrypted passwords unreadable is much better than either leaving them readable or using a shadow file of unencrypted passwords.
piet@ruuinf (Piet van Oostrum) (01/02/89)
In article <230@ibd.BRL.MIL>, heilpern@ibd (Mark A. Heilpern ) writes: `If the 2-letter key used in encryption were not known, this boosts the 80 hour `upper end to ~37 years. (80 hours * 4096 methods of encryption) In article <1988Dec26.151208.19016@ziebmef.uucp>, mdf@ziebmef (Matthew Francey) writes: `In article <12750@bellcore.bellcore.com>, karn@ka9q.bellcore.com (Phil Karn) writes: ` A 56-bit search space is well beyond the brute-force `> abilities of most crackers (though perhaps not the NSA) **IF** the keys are `> widely and evenly distributed within it. ` ` A possible solution is to have each site pick its own secret encryption `method (for example, start with a non-zero block). Could it remain secret `for a long long time (years... it would be a major pain changing it)? `Probably not, since anyone could disassemble passwd... In article <13022@bellcore.bellcore.com>, karn@ka9q (Phil Karn) writes: ` The point is that to be maximally effective, the UNIX password `algorithm should be given keys with 56 bits of entropy. That is, the `distribution of actual user keys should be uniformly distributed over `all 2^56 possible values. In article <614@rufus.math.nwu.edu>, john@rufus (John Franks Dept. of Math. Northwestern Univ.) writes: ` `Question: Why are we limited to 56 bits? Surely not for effi- `ciency or to save space. This is an instance where we *want* to `be slow. I've heard that NSA lobbied for smallish keys in com- `mercial DES rather than larger ones (the implication being they `wanted a size they could handle easily). Does anybody know if `there is any truth to this? ` Actually, it wouldn't be difficult to get a search space of more than 2^56: First, force the user to use long passwords, from a reasonable set of characters (like a minimum percentage from each of [a-z],[A-Z],[0-9] and [!"$%^&*()_+{}<>?:@]). Now the input to the encryption algorithm consists of: 12 bits 'salt' 56 bits DES-key 64 bits constant to be encrypted. that makes a total of 132 bits. If you take each of the above 3 parts from various bits of the password, then we could accommodate 19 character passwords. -- Piet van Oostrum, Dept of Computer Science, University of Utrecht Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands Telephone: +31-30-531806 UUCP: ...!mcvax!hp4nl!ruuinf!piet
dc@gcm (Dave Caswell) (01/03/89)
Barry Shein) writes:
Hiding something indicates that it is dangerous if revealed. It says,
basically, that encryption technology is inadequate and cannot be made
to work, the only reasonable protection is secrecy. Do we honestly
believe this? Or, worse, do we believe that security is attained by
layering anything we can think of onto the system?
If people have no reason to look at encrypted passowrds and it is easy to make
sure they can't look, why not have hidden passwords? There are plenty of
computer systems that don't show users encrypted passwords and I don't
automatically think they are hiding something or they have inadequate
technology. Secrecy isn't a fair word; if everyone is the neighborhood
has curtains do you call them practicing secrcy or do you call the person
dressing in front of the open window an exhabitionist. I don't consider
it layering anything onto the system; I consider it almost free protection
of material that people don't need to look at anyway. Or to look at it
another way; if all systems had shadow password files could you imagine
yourself arguing to show people the encrypted passwords to prove that
you had adequate technology? Are you fighting change just for sake
of preserving the status quo?
--
Dave Caswell (former EMU student)
Greenwich Capital Markets uunet!philabs!gcm!dcbzs@Encore.COM (Barry Shein) (01/03/89)
Doug Gwyn responding to my note >>Can we assume that before we make exotic changes like shadow passwords >>we can make simple changes (some Unix's already have these) to the >>passwd changing programs like: ... > >NO! please dont shout, i have a headache. > The "easy-to-guess password" checks are not sufficient, and >the accompanying restrictions are a royal pain in the user's ass. >It has been argued that they result in REDUCED security! I suppose one can say I'm being hoisted on my own petard. Because they're not sufficient they're useless? They're only a regal malady if you sit there trying to type in pw's it won't accept (that is, you don't know what a good approximation of a reasonable password is and you decide to type in /usr/dict/words as it rejects anything in /usr/dict words), no? This is what I meant by user education, how to choose a password that's both secure and acceptable to the software, both, not only the first. The reduced security argument I assume you are referring to generally is the claim that if you force people to use hard to remember passwords they will write them down etc. No one is advocating hard to remember passwords, just not pw's in the dictionary and a few other easy guesses (like your login name), monocase, stuff like that. That's not that monarchically grimacious, is it, really? Doesn't SYSV enforce this sort of thing right now out of the can? Or at least mixed case and/or punct/digits. If that's not what you meant then I need a phrase worth of recap. >Exposing the encrypted password for anyone to see is FOLLY; it was >barely excusable in the first place and is inexcusable now. The >shadow password file (which is NOT "exotic"; in fact JHU/BRL PDP-11 >UNIX had something of the sort many years ago) has already been >implemented; so long as UNIX sticks to the general modified DES >encryption scheme, hiding the encrypted passwords is a necessary >security measure. Ok, fine, it's folly. When the ftpd bug was discovered a few weeks ago and the possibility existed that all of BRL's pw files, protected or not, were read, what was done? The shadow pw file offered no protection against this and being as you seem to believe in allowing users to choose easy passwords and just hide the encryptions you had to acknowledge a major security breach, no? Any time you have discover a hole (even a badly installed piece of software, like vendor stuff which installs itself setuid dangerously) that's been around for more than (I dunno, an hour?) you have to assume someone walked off with your shadow password file, no? It's such an easy and obvious target. See, I can *almost* buy the argument that given a set of security measures they can be treated as the product of the probabilities of each being broken IFF they are truly independent. Once one relies on the other then that reasoning collapses and you tend towards a weakest link probability. I will point out that I consider the possibility of moving from the current general modified DES an intriguing area. Making it much more expensive to spin passwords (esp given the higher average MIPS today), reliably, should be more secure than relying on read permissions in the file system, and more transparent also (and heck, maybe it can even be exported...) -Barry Shein, ||Encore||
wisner@killer.DALLAS.TX.US (Bill Wisner) (01/03/89)
> Doesn't SYSV enforce >this sort of thing right now out of the can? Or at least mixed case >and/or punct/digits. Yes. Passwords must be at least six characters with at least two letters and at least one digit or symbol. (System V 3.2.1)
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (01/03/89)
In article <2803@cbnews.ATT.COM>, res@cbnews.ATT.COM (Robert E. Stampfli) writes: > Can anyone think of a good reason why either of the following should not be > done on systems that employ a shadow password file: > > 1. Provide a program which returns the encrypted version of the password > for the uid (or euid) that invokes it. I see no reason to make this available; provide a server which checks for a match instead. > 2. Provide a program, similar to "passwd", which modifies the encrypted > password in the /etc/passwd file, like the original version of the > passwd command did. > > Both if these, it would seem to me, would be useful in writing things like > terminal lock programs (case 1), terminal lock programs are a great way for me to break into your account. > or programs that run set-uid to one account > to allow users the ability to do something with files owned by that account, > provided they possess the "public" password (case 2). in which case I may just crack on your ``public'' password. Besides, if I need that I can implement my own file which will be private as well, and even allow me to have different ``public passwords'' for different users. I don't see the benefit of a system-level version. And if your setuid program that lets me ``do something'' to your files isn't good enough....
jfh@rpp386.Dallas.TX.US (The Beach Bum) (01/03/89)
In article <946@ruuinf.UUCP> piet@ruuinf (Piet van Oostrum) writes: [ nice, long description ... ] >Now the input to the encryption algorithm consists of: > 12 bits 'salt' > 56 bits DES-key > 64 bits constant to be encrypted. > >that makes a total of 132 bits. If you take each of the above 3 >parts from various bits of the password, then we could accommodate 19 >character passwords. No - you are still only storing 56 bits of password data. What you are doing is providing a multi-way encryption algorithm, you are not expanding the key space. Since there are only 2^56 possible outputs, and 2^132 inputs, some of them must map onto other encrypted passwords - a multi-way encryption. This reminds me - old VAX/VMS used CRC16 to encrypt their passwords. Which is about as multi-way as it gets ... This would mean, if correct, that only 65,536 different passwords would have to be generated to break the system. The successful cracker pre-encrypts several times this many passwords using the CRC16 instruction to generates a complete dictionary of all possible output values. -- John F. Haugh II +-Quote of the Week:------------------- VoiceNet: (214) 250-3311 Data: -6272 |"Anything on the road which can be InterNet: jfh@rpp386.Dallas.TX.US | hit, will be ..." UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
jfh@rpp386.Dallas.TX.US (The Beach Bum) (01/03/89)
In article <11056@ulysses.homer.nj.att.com> smb@ulysses.homer.nj.att.com (Steven M. Bellovin) writes: >In article <2803@cbnews.ATT.COM>, res@cbnews.ATT.COM (Robert E. Stampfli) writes: >> Can anyone think of a good reason why either of the following should not be >> done on systems that employ a shadow password file: >> >> 1. Provide a program which returns the encrypted version of the password >> for the uid (or euid) that invokes it. > >I see no reason to make this available; provide a server which checks >for a match instead. Agreed. The encrypted password should not be made available, and the encryption method should be selectable from a variety of methods, or the internal key [ constant portion ] should be readily modifiable. Let's not make things any easier than need be. On the similiar vein - It would appear that AT&T is playing with a new version of shadow passwords with yet another file layout. This version includes password expiration warning information and login administration fields in one big mess of an entry in a completely new file - /etc/privates. There is a command - rdpriv - which provides user access to the privates file, but does not return the user's encrypted password, only the password aging information. This now leaves us with three completely incompatible formats in the USG universe ... -- John F. Haugh II +-Quote of the Week:------------------- VoiceNet: (214) 250-3311 Data: -6272 |"Anything on the road which can be InterNet: jfh@rpp386.Dallas.TX.US | hit, will be ..." UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
friedl@vsi.COM (Stephen J. Friedl) (01/03/89)
In article <6634@killer.DALLAS.TX.US>, wisner@killer.DALLAS.TX.US (Bill Wisner) writes: > Passwords must be at least six characters with at least two letters > and at least one digit or symbol. (System V 3.2.1) This has been the case since at least Sys V Rel 2, and in all cases, root is permitted to bypass these rules. Steve -- Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com V-Systems, Inc. I speak for me only attmail!vsi!friedl Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl -------Nancy Reagan on Usenix in San Diego: "Just say *go*"-------
heilpern@ibd.BRL.MIL (Mark A. Heilpern ) (01/03/89)
In article <4545@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: > >Re: using a .case file which shows the lower/upper case pattern for >a password.... > >But this means that login will now accept the dictionary word in lower >case? Seems to reopen that attack (ie. going thru the dictionary) as >login is correcting case for me as I go. The time a dictionary search THRU THE LOGIN PROGRAM would be astronomical. The danger in the ability of a dictionary search is in the user writing a C program which uses the crypt() command, etc. > >Worse, it relies on the unreadability of these .case files in every >user's directory, I don't think that's a good thing to rely on, if >users are sloppy about password choosing and too lazy to remember the >case shifts why do you believe they'll be careful about protecting >this .case file? Besides, holes to read unreadable files are a little >too easy to come by (also, I assume that the length of the file tells >me how many chars in your passwd?) 1) The login program should NOT allow entry if the .case file is readable, and since /bin/login is setuid to root, I THINK .case's attributes could be unreadable to the user. 2) There is nothing wrong with a .case file with, say, 10 characters when the password is only seven characters long! Additionally, the user does not even have to be aware of what his case's are! /bin/passwd could randomly create a new one when evoked, maybe making all of them 10 or 15 characters. [ Allthough I don't know of a way ] if there is a way to make a file invisible to /bin/ls, the user would not have to be aware of the file's existance. Have a nice Day :) -- |\/| | | | _ |< / \_(_(_)\_/ \______
rogerc@ncrcae.Columbia.NCR.COM (Roger Collins) (01/03/89)
In article <4546@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: > > >I like some form of shadow passwords as a solution. Once they're in place, > >you no longer care what the user picks for a password, as long as it's N > >characters long and not the account name. > > > >Keith Bostic > > Round and round, and you're not disturbed at the fact that you're now > relying on the unreadability of the shadow file? How many ways are > there to read a read-protected file? How do you know it has been read > by an unauthorized person (or a disgruntled employee)? If you suspect > it has been read what is the appropriate action (I can answer that, > change every password on the system, wotta nuisance.) > > -Barry Shein, ||Encore|| Same reasoning: Conventional door locks are not perfect. So, rather than let myself be lulled into complacency by locking the door, I will just wait till newer technology makes a perfect lock. Hell, I better start research now so my house can be safe once and for all. Now, seriously: o Almost every C programmer knows how to write a brute force program to crack passwords in a readable password file. o Only a very small percentage of Unix users (experts) know about holes and such to read unreadable files. (And a knowledgeable administrator can decrease this percentage by plugging these holes as they are made known by other experts.) o Shadow password file DOES NOT encourage people to use sloppy passwords. Your passwd program or /etc/motd can be just as annoying as it ever was :). o Security will still improve. I'm sure that all security development will NOT just stop because shadow passwording solves all the problems. The problem is not being "swept under the rug." Enough. What ever happened to the campaign for comp.security or comp.unix.security or whatever? -- Roger Collins rogerc@ncrcae.Columbia.NCR.COM
jal3495@ultb.UUCP (Jeff Leyser) (01/04/89)
In post <4497@xenna.Encore.COM>, bzs@Encore.COM (Barry Shein) says:
!>I think this would be more secure than current password file or the shadow
!>password file. Any comments?
!
!Yes, somewhere and at some time we are going to have to do the hard
!work of analyzing whether or not hiding encryptions improves security
!as a general principle (as opposed to coming up with new ways to hide
!them before doing the ground work.)
!
!Hiding something indicates that it is dangerous if revealed. It says,
!basically, that encryption technology is inadequate and cannot be made
!to work, the only reasonable protection is secrecy. Do we honestly
!believe this?
! -Barry Shein, ||Encore||
The encryption techology currently used is adequate. What is not
adequate are the users. The recent Internet worm proves this.
The author of the worm didn't really 'break' the encryption on
passwords, he just looked for 'obvious' passwords, and he found more
than a few.
As we all know, this has prompted endless discussion on the best way to
get users to avoid 'obvious' passwords. But, in all practicality,
this may be next to impossible. So, either instead or in tandem, we
_do_ need to take a good hard look at the current practice of Unix
passwords being world readable. Frankly, if it comes down to a choice
between changing technology and changing human behavior, I'll change the
technology.
--
Jeff Leyser, Professional Student {WCS}!rochester!ritcv!ultb!jal3495
a[b] == b[a] -- The Ultimate in Job Security
I can't have opinions, I didn't pay my opinion fee this term.tjr@ihnet.ATT.COM (Tom Roberts) (01/04/89)
Several people have indicated that complicated, "difficult to remember" passwords may create more exposure than they eliminate. I beg to differ. I believe that in most computer environments today, the MAJOR access security exposure is due to "password guessing"; I believe that the exposure due to writing down passwords is, or can be made to be, much less dangerous. Example: Create a password from 8 randomly-selected ASCII characters, and write it down (be very careful about how you perform this random selection!). DO NOT write it down on a paper clipped to your terminal, but on a piece of paper that you keep with you at all times inside your wallet. Analysis: The range of security exposures has been changed significantly; you will no longer be open to password guessing attacks, because such attacks will be using a dictionary, not your random password. Your exposure is now similar to the exposures you routinely subject your house keys and credit cards to. Is your computer account more valuable than your house or bank account? With this method you also have a very good likelihood of detecting a breach of your password (e.g. your wallet was stolen), and can take corrective measures (change your password). I suggest that in most computer environments (e.g. networks) this method is far superior to having users attempt to imagine passwords that are both hard to guess and easy to remember. Clearly, having the computer system generate the password is also possible, but the method of generation must be very carefully chosen (computers cannot easily generate random numbers). The only difficulty I know of in this method is that users may not protect the paper as well as they protect their keys and credit cards. I do not know how to address this problem. Tom Roberts att!ihnet!tjr AT&T Bell Laboratories
dlm@cuuxb.ATT.COM (Netnews Administrator) (01/04/89)
In article <4547@xenna.Encore.COM> bzs@Encore.COM (Barry Shein)
writes: more comments trying to prove a shadow password file is a
"bad idea".
As I seem to have triggered this latest debate, I have a couple
of points:
1). Shadow password files contain the passwords encrypted.
Hence offer better protection from cracking on a properly
administered machine. They do give an illusion of more security
but in no case do they give less security.
2). Shadow passwords have been around since 1976 since I
implemented them at NSA after Ken and Morris major told us about
their activities. Pass phrases were implemented shortly
thereafter by either Dan Edwards or Howie Weiss.
3). Password choice validation has been independently invented
by several people and I worked on a scheme in 1983.
4). Automatic password generation has been invented
independently several times. Human factors tend to make it fail
to work.
5). I still find customers who have no root password. Or, whose
root password for November was turk3y or in June was b1rds [think
Baltimore and baseball].
6). All the ideas stated are good. All of them combined improve
security. Short of a kernel managed password system, we should
try to merge them.
7). The key space for the password is woefully small compared to
the space available. Because of the getty nonsense about case
senstive terminals [some still around - IBM 3270 for example],
capital letters are still not useable in a password. Pass
phrases are the best single improvement to the password scheme
around that hasn't been implemented by a major vendor such as
Berkeley or ATT.
8). Relying on the work factor for an encrytion for the major
protection is foolish. There will be a cracker who is smart
enough to figure out how to beat the encrytion. Remember that if
/bin/login or /bin/passwd is publicly readable on your system one
can reverse engineer the whole protection system. After which
optimize, optimize. A serious cracker will have serious help, a
non-serious one will try elsewhere.
9). If one can become sys, one can become bin. If once can
become bin, one can become root. In many systems if one can
become uucp one can become sys. If one can become lp [line
printer spooler] one has the keys to the kingdom. Trojan horses
provide less work than password cracking -- they are just less
certain.
Finally, Human factors will still govern all of the above points.
Non-technical people still will insist on having their own way.
--
=Dennis L. Mumaugh
Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.comastieber@csd4.milw.wisc.edu (Anthony J Stieber) (01/04/89)
-- internet:astieber@csd4.milw.wisc.edu |\|BeingNet: Tony Stieber bitnet :astieber%csd4.milw.wisc.edu@INTERBIT |/|BustedUpNet: 414-529-2663 uucp :att!uwmcsd1!uwmcsd4!astieber |\|Terranet: 8858 Garden Lane csnet :astieber%csd4.milw.wisc.edu@uwm.CSNET|/| Greendale WI 53129
piet@ruuinf (Piet van Oostrum) (01/04/89)
In article <10629@rpp386.Dallas.TX.US>, jfh@rpp386 (The Beach Bum) writes:
`
`No - you are still only storing 56 bits of password data. What you
`are doing is providing a multi-way encryption algorithm, you are not
`expanding the key space.
`
`Since there are only 2^56 possible outputs, and 2^132 inputs, some of
`them must map onto other encrypted passwords - a multi-way encryption.
`
You are right, only it is 2^64 (the key for DES is 56 bits, but the output
is 64 bits), so this still gives an 8 bit improvement, making it 128 times
as hard.
--
Piet van Oostrum, Dept of Computer Science, University of Utrecht
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands
Telephone: +31-30-531806 UUCP: ...!mcvax!hp4nl!ruuinf!pietgreywolf@unisoft.UUCP (The Grey Wolf) (01/05/89)
In article <2338@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes:
# 7). The key space for the password is woefully small compared to
# the space available. Because of the getty nonsense about case
# senstive terminals [some still around - IBM 3270 for example],
# capital letters are still not useable in a password. Pass
# phrases are the best single improvement to the password scheme
# around that hasn't been implemented by a major vendor such as
# Berkeley or ATT.
# --
Small point here: Getty doesn't even look at the password. Login is
the one that takes it.
I am also a bit shaky on how you mean "pass phrases" -- does this entail
enforcing very long strings or what?
Another idea: Why do we not advance our technology to make use of
larger password salt/key strings (instead of using 8 chars and returning
13, why not try for 16 chars and return 26)? Backwards compatibility,
sure, but once you have a decent system, are you really going to give a
flying f?ck through a rolling donut about that particular avenue of
backward compatibility?
I think that people are reluctant to explore the above possibility because
they are (mentally) comfortable to remain where they are. So long as this
condition exists, passwords will be restricted in usable length (I have
often wished for passwords on the order of 12+ characters, but gave up
on them since only the first 8 were used), and we will have this problem.
(I am probably missing something here, but that's okay; this news group
is better than any C compiler I have ever seen -- not only will it tell
me I made an error, but it will point out the error and ram it down my
throat! :-)
Explanations welcomed; send flames to /dev/null.
# =Dennis L. Mumaugh
# Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.com
Roan Anderson, Software Engineer and resident half-elf
UniSoft Corporation, 6121 Hollis St., Emeryville, CA 94608
--
...TheysaidDoyouseethebiggreenglowinthedarkhouseuponthehill?andIsaidYesIseethebiggreenglowinthedarkhouseuponthehillTheresabigdarkforestbetweenmeandthebiggreenglowinthedarkhouseuponthehillandalittleoldladyonaHoovervacuumcleanersayingIllgetyoumyprettyandyourlittledogTototoo
I don't even *HAVE* a dog Toto...jfc@athena.mit.edu (John F Carr) (01/05/89)
In article <4523@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: >Can we assume that before we make exotic changes like shadow passwords >we can make simple changes (some Unix's already have these) to the >passwd changing programs like: [a list of 4 common suggestions like no dictionary words/username] > 5. Finally, will educate users about how to choose a good > password I think this alone is both necessary and sufficient for security. I see no reason to believe that a user who is inclined to choose "easy" passwords (i.e. chosen from a small, predictable fraction of all legal passwords) will stop doing so when restrictions are applied. He will just have to choose from a different set of strings. On the other hand, an educated user will choose "good" passwords with current, unrestricted systems. (As long as we are talking of what makes an "easy" password, I know of a system that compares old & new passwords to make sure than no number in the new password is the same as a number in the old +/- 1. It also checks the new password and refuses to allow any three letter month abbreviation ("jan", "feb",...) or the current year as a substring.) -- John Carr "When they turn the pages of history, jfc@Athena.mit.edu When these days have passed long ago, bloom-beacon! Will they read of us with sadness athena.mit.edu!jfc For the seeds that we let grow?" --Neil Peart
marc@ucbvax.BERKELEY.EDU (Marc Teitelbaum) (01/05/89)
In article <4546@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: > >Round and round, and you're not disturbed at the fact that you're now >... The first problem I have with your argument is essentially this. You assume that file system security is weak enough that an average hacker can gain access to the shadow password file. I contend that if the average hacker can accomplish this, then he doesn't *need* to crack any passwords because he can *just* as easily gain access to any other file in the filesystem. And, after all, isn't that what the hacker is after anyway. Most of the interesting information is contained in *files*, isn't it. Then, if the average hacker is so facile at finding and gaining access to random files (shadow password or otherwise), who the hell needs to crack passwords. The second problem with your argument is that you overlook Henry's point that no security is perfect, just that the more secure system makes it that much *harder* to break in. Puts up more road blocks. Leaves more trails for the careless. - Your argument is that the perceived security of shadow password files will make the system administrator more complacent, therefore it's undesireable. Poppy cock. That's a system administrator issue, and educating a system administrator is a heck of a lot easier than educating the entire user community. I could just as easily argue that since the file system protection is so insecure (to the point that any hacker can access the shadow password file), then setting file permissions is really a waste of time and just a delusion that your files are secure. Therefore, you're fooling yourself if you have your umask set to anything other than 000. I don't buy this - do you? Marc ------------------------------- Marc Teitelbaum +1-415-643-6448 457 Evans Hall Computer Systems Research Group, CSRG / DEC University of California Berkeley, CA 94720
jfh@rpp386.Dallas.TX.US (The Beach Bum) (01/05/89)
In article <949@ruuinf.UUCP> piet@ruuinf (Piet van Oostrum) writes: >In article <10629@rpp386.Dallas.TX.US>, jfh@rpp386 (The Beach Bum) writes: >`Since there are only 2^56 possible outputs, and 2^132 inputs, some of >`them must map onto other encrypted passwords - a multi-way encryption. >` >You are right, only it is 2^64 (the key for DES is 56 bits, but the output >is 64 bits), so this still gives an 8 bit improvement, making it 128 times >as hard. If you obtain the salt from the password, rather than clock(), then you are correct. This would be an inexpensive way to increase the password beyond 8 characters. It is, unfortunately, incompatible with current password files. At what price progress? [ How about - an extra field in /etc/privates giving the encryption method ;-) ] -- John F. Haugh II +-Quote of the Week:------------------- VoiceNet: (214) 250-3311 Data: -6272 |"Anything on the road which can be InterNet: jfh@rpp386.Dallas.TX.US | hit, will be ..." UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
peter@ficc.uu.net (Peter da Silva) (01/05/89)
In article <654@white.gcm>, dc@gcm (Dave Caswell) writes: > If people have no reason to look at encrypted passowrds and it is easy to make > sure they can't look, why not have hidden passwords? Because open passwords let users write utility programs that verify who you are. If the password file is hidden, you need to provide a password verification server. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. `-_-' Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net. 'U` Opinions may not represent the policies of FICC or the Xenix Support group.
rob@inmos.co.uk (Robin Pickering) (01/06/89)
In article <232@ibd.BRL.MIL> heilpern@brl.arpa (Mark A. Heilpern (IBD) <heilpern>) writes: >Here's an interesting idea: > >Let's assume a users password is: physics >This would most likely be solved in a routine dictionary search. > >Suppose, among the standard dot files in the home directory, there was to be >a new one: .case . The login program is to check this file, Why stop with case, why not specify a more general per-user password pre- munging mechanism. This seems quite an effective way to increase the password search space to any party without access to the private munging factor used. Rob Pickering (JANET only: ROB@UK.CO.INMOS) | Software Group, Inmos Bristol. ARPA/UUCP: rob@inmos.co.uk (...uunet!mcvax!ukc!inmos!rob) (... any opinions expressed are my own.)
dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (01/06/89)
In article <1687@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >Small point here: Getty doesn't even look at the password. Login is >the one that takes it. True, but getty looks at the logname: if it is all UPPER CASE it sets tty modes to map upper case to lower. Then login will only see lower case input [unless one uses escapes]. Hence for true concern one can't allow upper case characters when older/obselete terminals [e.g. TTY33 or IBM3270] are used. > >I am also a bit shaky on how you mean "pass phrases" -- does this entail >enforcing very long strings or what? Perhaps. My work with that had a requirement that the password be a MINIMUM of 8 characters and a MAXIMUM of 64, blanks and control characters [and case] significant. > >Another idea: Why do we not advance our technology to make use of >larger password salt/key strings (instead of using 8 chars and returning >13, why not try for 16 chars and return 26)? > We should but the details of implementation are a bit tricky and it isn't a glamorous project so some developers haven't proposed it. The encryption really ought to use Cipher Block Chaining, or encryption of each 64 byte chunk independently. The strength of the technique must be analyzed cryptologically and shown to be properly secure. As a developer, do that and sign your name. Hope that you are right. Perhaps a half dozen people in comp.unix.wizards could feel safe in their implementation [outside of current NSA employees]. >I think that people are reluctant to explore the above possibility because >they are (mentally) comfortable to remain where they are. So long as this >condition exists, passwords will be restricted in usable length (I have >often wished for passwords on the order of 12+ characters, but gave up >on them since only the first 8 were used), and we will have this problem. > See above. It's easy in theory to solve a security problem. But do the implementation and then explain to your senior vice-president or general counsel why you think that it will GUARENTEE solving the problem. Despite all security discussion and theory and provable systems, etc. it all comes down to what I call the "comfort factor". Just how comfortable the boss is in signing the paper work. When I was the one that originated the DoD rules on declassification of magnetic tapes and memories [extended to disks now] the document said do this and that and then the tape is declassified. I said "Then that means I can deliver it to the Russian Embassy without worry." The answer was "Well, it isn't really *that* unclassified." I.e. the comfort factor wasn't too high on the decision. >(I am probably missing something here, but that's okay; this news group >is better than any C compiler I have ever seen -- not only will it tell >me I made an error, but it will point out the error and ram it down my >throat! :-) > Not much. Anything to do with security is reminiscent of the Dutch boy and the dike philosophy, patching up known holes and anxiously looking for new ones. The NSA people have said for years that this is a bad way of doing things. Design and prove a secure system, implement it and prove the implementation is mathematically correct. It might be possible, but then convince the boss that it is so correct that he can put his job on the line. Ne c'est paix? -- =Dennis L. Mumaugh Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.com
heilpern@ibd.BRL.MIL (Mark A. Heilpern ) (01/06/89)
In article <2629@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >Because open passwords let users write utility programs that verify who you >are. If the password file is hidden, you need to provide a password >verification server. 1) Why must "normal" users implement this function? Surely, in the case of a Shadow password file, a setuid-to-root program will have the needed access, no? 2) Assuming a shadow password file boosts security to the Nth degree, the getuid() call should be verification enough. Additionally, if there is no increase in security, the password will have been breeched, and the fraudulent user will already know the password. 2a) Unless the real user just walks away from a logged in terminal, but that is another issue. -- |\/| | | | _ |< / \_(_(_)\_/ \______
friedl@vsi.COM (Stephen J. Friedl) (01/06/89)
In article <2343@cuuxb.ATT.COM>, dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) writes: > Perhaps a half dozen people in comp.unix.wizards could feel > safe in their implementation [ of Cipher Block Chaining ]. So, outside of Dennis and me, who are you other four? :-) Steve P.S. - *gasp*, no, I'm not serious. -- Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com V-Systems, Inc. I speak for me only attmail!vsi!friedl Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl -------Nancy Reagan on Usenix in San Diego: "Just say *go*"-------
bstrand@woods.unix.eta.com (Brad Strand) (01/07/89)
The recent discussions regarding Unix password security (and the lack
thereof) got me wondering about other authentification schemes. One
such scheme that I haven't seen mentioned here, is replacing the password
with a 'pass-function'. By that I mean that instead of having a
password such as "xyzzy", each user would have his/her own personal
function F, perhaps like
F(C) = 4C + 3
The idea would be for the system to replace the "password:" prompt
with a prompt more like, "How about C?", where C is some reasonably
small (maybe 16-bit) random "Challenge" number generated by the system.
The user must then apply his/her pass-function to this particular C,
and enter the resulting F(C). Example:
login: <bstrand>
How about 1204? <4819>
Welcome, Brad! ... etc.
Some advantages of something along these lines:
1. Since the required response is non-constant, brute-force attacks (trying
all possible passwords) would not be likely to succeed. In other
words, if there were p possible passwords, I am guaranteed of finding
the correct one in at most p trials. If, however, there were f possible
responses to the system's challenge, I am NOT guaranteed of succeeding
in f trials, since all trials are (in a sense) independent of one another.
2. People "sneaking-a-peek" at you logging on would not (most probably)
be able to log in as you later.
3. Same as (2) for people using a network monitor or "Trojan Horse" login
program.
4. Intuitively, mathematical functions seem more "uniformly distributed"
than passwords...Hence, it seems more likely that someone would use
N = 3C^2 + 1331 as a pass-function, than it would be for
someone to use "Bn&@v8}?" as a password. (Intuitively, there seems
to be far more easy-to-remember functions than easy-to-remember passwords,
but I could very well be wrong here.)
Some Disadvantages:
1. People might tend to pick simple 'pass-functions' (N = C + 3)
because more difficult ones might be either harder to remember, or
harder to calculate in one's head.
2. Would need to come up with a standard method of representing and/or
encrypting the pass-functions for use in the '/etc/passfunc' file.
This is probably non-trivial.
Questions:
1. Am I really missing the boat here? Would something like this be
a stupid waste of time? Or might something along these lines
actually be useful?
2. Has anyone tried something along these lines on a per-user
basis? (Quite a while back, I remember using a
pass-function on a "system-wide" basis. It was a program
used to screen access to a dial-in line. The user had to
respond correctly to a Challenge before a "shell" would be
created...I say "shell" because it was non-Unix system...)
3. Obviously, I've greatly oversimplified the implementation in
this description, but what improvements (if any) could be
added to strengthen this sort of scheme? Example: the
system could issue two Challenges, C1 and C2. Now we have
two variables to use in the function...would this help? Etc.
Brad Strand, ETC-03J bstrand@woods.unix.eta.com
ETA Systems, Inc. "Racing to Win"
1450 Energy Park Drive
St. Paul, MN 55108 "So it goes." bzs@Encore.COM (Barry Shein) (01/07/89)
From: jal3495@ultb.UUCP (Jeff Leyser) >The encryption techology currently used is adequate. What is not >adequate are the users. The recent Internet worm proves this. >The author of the worm didn't really 'break' the encryption on >passwords, he just looked for 'obvious' passwords, and he found more >than a few. GET NEW USERS...ok, ok...I know... The humorous thing about this oft-repeated line of reasoning is that "obvious" passwords were only tried AFTER THE WORM HAD BROKEN INTO YOUR SYSTEM! To try to propagate to other systems. And it wasn't all that successful when compared to the other major methods of attack used (the bug in sendmail, the evil finger DAEMON as the papers called it and .rhosts files.) Attacking passwd files was its last resort when all that failed, which apparently wasn't very often. It really is like buying a better lock for the front door because the thieves keep breaking in through the glass... It shouldn't be that hard to have the password changing program nudge people towards better password choices so the rest of the argument ("to get users to avoid obvious passwords...may be next to impossible") seems unfounded founded. -Barry Shein, ||Encore||
msf@prandtl.nas.nasa.gov (Michael S. Fischbein) (01/07/89)
In article <2629@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <654@white.gcm>, dc@gcm (Dave Caswell) writes: >> If people have no reason to look at encrypted passowrds and it is easy to make >> sure they can't look, why not have hidden passwords? > >Because open passwords let users write utility programs that verify who you >are. If the password file is hidden, you need to provide a password >verification server. And, if you want compatability with the programs already written and those to be written with a view towards the existing documentation, you provide compatability with the getpwent(3) routines, and access to the encrypted passwords is trivial. Thus, to have a shadow passwd file you give up a significant amount of com- patability with existing documented routines. Perhaps making the crypt(3) call have some knowledge of the number of times it has been recently called and having it slow down would help. This requires the system's encryption routine to be publicly unknown, of course, otherwise the algorithm could simply be reimplemented more quickly. Rewriting crypt(3) would lose for people setting up new systems and trying to transfer passwords from old ones; a much rarer situation than trying to port programs. I'd guess the tradeoff involves how much non-vendor supplied (not just freeware) software you use that requires password verification, what sort of attacks you anticipate on the system, and how much effort you can put into customizing stuff. mike Michael Fischbein msf@prandtl.nas.nasa.gov ...!seismo!decuac!csmunix!icase!msf These are my opinions and not necessarily official views of any organization.
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (01/07/89)
In article <900@eta.unix.ETA.COM> bstrand@woods.unix.eta.com (Brad Strand) writes: |The idea would be for the system to replace the "password:" prompt |with a prompt more like, "How about C?", where C is some reasonably |small (maybe 16-bit) random "Challenge" number generated by the system. |The user must then apply his/her pass-function to this particular C, |and enter the resulting F(C). Example: | | login: <bstrand> | How about 1204? <4819> | Welcome, Brad! ... etc. A similiar sort of program was posted to the net some time last year by Phil Karn [ KA9Q ]. It was V10i031 in comp.sources.unix and should be available from your nearest comp.sources.unix archive. -- John F. Haugh II +-Quote of the Week:------------------- VoiceNet: (214) 250-3311 Data: -6272 |"Now with 12 percent less fat than InterNet: jfh@rpp386.Dallas.TX.US | last years model ..." UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
bzs@Encore.COM (Barry Shein) (01/08/89)
Dennis Mumaugh writes (lots of points, most good, some irrelevant to the issue at hand like that some systems don't have root passwds which I fail to see how *any* system will protect against once allowed.) >8). Relying on the work factor for an encrytion for the major >protection is foolish. There will be a cracker who is smart >enough to figure out how to beat the encrytion. Remember that if >/bin/login or /bin/passwd is publicly readable on your system one >can reverse engineer the whole protection system. After which >optimize, optimize. A serious cracker will have serious help, a >non-serious one will try elsewhere. Here you've hit on the absolute, critical, nut of the problem. We completely disagree (although I don't think either of us can yet prove the other wrong) on this one point and everything else discussed can be reduced to this one disagreement. In fact, it's a presentation of tautological proof of the need for shadow password files (shadow password files are necessary to prevent decrypting of passwords because without them passwords can be decrypted.) I don't accept this a priori. I am willing to consider the need for a change in encryption algorithms used, and I certainly see a use for password changers which reject easy to crack choices (eg. anything short, of only lower case chars, in /usr/dict/words, equal to the login name, system name etc.) Such password checkers are not the only defense, if someone is absolutely determined to use a simple password (such as an anagram of their last name) which the checker doesn't check for and someone else happens to use that in their attack it doesn't much matter what method you use, so education is important also, regardless of any other consideration. With a last name like mine they could practically type in all the anagrams in a few hours thru the login program, if you narrow that down to CVC patterns even longish names become pretty easy (for example.) You can put the absolute best locks on your doors but if your staff fails to close those doors and lock those locks then it's futile. Basically, I claim you have just rested your argument on the proposition that such systems as RSA and other public-key data encryption methods are completely useless and fundamentally flawed, even in the casual sense (ie. without presupposing teraMIPS computers.) Is that a fair summary? Is that where you want to stand? -Barry Shein, ||Encore|| P.S. This is *NOT* a flame war or any such thing, I honestly believe this whole issue needs to be shaken out and this list is a fine place to do that, INMHBCO.
bzs@Encore.COM (Barry Shein) (01/08/89)
Marc Teitelbaum writes...well, first, quotes... In article <4546@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: > >Round and round, and you're not disturbed at the fact that you're now >... Uh, is this supposed to be a fair summary of my article? (quote quoted in entirety.) Anyhow... >The first problem I have with your argument is essentially this. You >assume that file system security is weak enough that an average >hacker can gain access to the shadow password file. I contend that >if the average hacker can accomplish this, then he doesn't *need* >to crack any passwords because he can *just* as easily gain access >to any other file in the filesystem. Excellent point, deserves an answer. Most importantly I claim that a shadow password file only requires READ access to the file system while cracking a password (particularly system passwords) gives one WRITE access to the system. We must distinguish those two concepts, particularly in this case since all we're claiming is that a shadow password affects the readability of password encryptions. In that context I make two claims: 1. That read access breaches are easier to come by than write access breaches and much harder to detect. The reason they're easier to come by is mere practice, I can't prove it. Programs which only read files seem to be less thoroughly checked for holes and I know of a few such programs which I've seen reported. The typical pattern is a program running priv'd which reports some sort of system or user status and can be made, via a symlink or hard link, to be fooled into reading a different file and dumping it to the user's terminal (for capture) or redirected to a file (same thing.) As a hypothetical example one could imagine linking a $HOME/.netrc to this /etc/shadow file and then the encryptions pouring out of a program trying to read the .netrc as syntax errors, that kind of thing. It's one of the oldest tricks in the book (I remember years ago on a Multics system someone getting a file for me, inadvertantly left unreadable [I had a note from the author telling me to come by for a tape of the program, he wasn't around] by simply including it in a mail file indirectly and mailing it to myself.) Those holes usually don't work for write access. 2. If you get write access to the file system you have to change something. Although it's a major problem and can be exploited mercilessly it can be generally checked for by compares with backup copies, how do you check for unauthorized reading? On the current system you can't (access times don't help since legitimate accesses keep updating that every few minutes anyhow.) You have absolutely no way of telling me at any point in time whether someone has walked away with a copy of the shadow file today. At best you can hem and haw and say it doesn't matter. You can tell me (assuming some sort of backup) whether someone changed the pw file today. I suppose the real problem I am alluding to is you've admitted a way to turn global read access into global write access as a target. I think we'd better off closing the original hole than simply moving it down a level in the hierarchy, temporarily. After all, if you don't believe you've left the danger present then why bother protecting it? So, the answer, put simply, is because read access can now get me write access. >The second problem with your argument is that you overlook Henry's >point that no security is perfect, just that the more secure >system makes it that much *harder* to break in. Puts up more road >blocks. Leaves more trails for the careless. - Your argument is >that the perceived security of shadow password files will make the >system administrator more complacent, therefore it's undesireable. Agreed, but my point is not that it makes the sysadmin complacent, it's that it makes the system DESIGNER complacent. Put another way, if you have a way planned that makes passwords secure even if someone (eg. a stupid employee) manages to walk out with a copy of your pw file then let's trashcan the shadow password file in the first place and just use that. If you don't then I have to claim that the system designers are in fact complacent (almost by definition) and my argument stands. Or, in one sentence, let's deal with the real problem and stop trying to sweep it under the rug. -Barry Shein, ||Encore||
heilpern@ibd.BRL.MIL (Mark A. Heilpern ) (01/09/89)
In article <669@brwa.inmos.co.uk> rob@inmos.co.uk (Robin Pickering) writes: -->In article <232@ibd.BRL.MIL> heilpern@brl.arpa (Mark A. Heilpern (IBD) <heilpern>) writes: -->>Suppose, among the standard dot files in the home directory, there was to be -->>a new one: .case . The login program is to check this file, --> -->Why stop with case, why not specify a more general per-user password pre- -->munging mechanism. This seems quite an effective way to increase the -->password search space to any party without access to the private munging -->factor used. --> --> Rob Pickering Rob, You've won my approval! Mark -- |\/| | | | _ |< / \_(_(_)\_/ \______
whh@pbhya.PacBell.COM (Wilson Heydt) (01/10/89)
In article <900@eta.unix.ETA.COM>, bstrand@woods.unix.eta.com (Brad Strand) writes: > The recent discussions regarding Unix password security (and the lack > thereof) got me wondering about other authentification schemes. One > such scheme that I haven't seen mentioned here, is replacing the password > with a 'pass-function'. By that I mean that instead of having a > password such as "xyzzy", each user would have his/her own personal > function F, perhaps like > > F(C) = 4C + 3 > > The idea would be for the system to replace the "password:" prompt > with a prompt more like, "How about C?", where C is some reasonably > small (maybe 16-bit) random "Challenge" number generated by the system. > The user must then apply his/her pass-function to this particular C, > and enter the resulting F(C). Example: > > login: <bstrand> > How about 1204? <4819> > Welcome, Brad! ... etc. I've seen two implementations of this sort of scheme. They both use a physical device to do the function--thus avoiding the problem of users picking simple functions. (And also permitting turning access off easily at need.) The first one is called "Gordian Key" and the token is a gray block of plastic about 1-1/2 by 2-1/2 by 3/8 inches. It has 4 photodiodes on one end and a 6-character LCD in the top. The system generates the challenge code and displays it on the terminal both as text and as a pattern of @s to be read by the photodiodes. There is an auxilliary device available that has a keypad and a set of LEDs so the user can key the challenge and it generates the scan pattern for the key, instead of hold the key to the terminal screen. The other device is called "SecurId" and looks rather like a credit- card sized calculator. The passcode is continuously displayed. In both these systems the challenge and passcode change every 30 seconds and the key function is specific to the user. It is *supposed* to be impossible to take either of them apart without destroying critical parts of the circuitry. --Hal ========================================================================= Hal Heydt | "Hafnium plus Holmium is Analyst, Pacific*Bell | one-point-five, I think." 415-645-7708 | --Dr. Jane Robinson {att,bellcore,sun,ames,pyramid}!pacbell!pbhya!whh
jik@athena.mit.edu (Jonathan I. Kamens) (01/10/89)
In article <674@ihnet.ATT.COM> tjr@ihnet.ATT.COM (Tom Roberts) writes: >Analysis: The range of security exposures has been changed significantly; >you will no longer be open to password guessing attacks, because such attacks >will be using a dictionary, not your random password. Your exposure is now >similar to the exposures you routinely subject your house keys and credit >cards to. Is your computer account more valuable than your house or bank >account? With this method you also have a very good likelihood of detecting a >breach of your password (e.g. your wallet was stolen), and can take corrective >measures (change your password). There is one major problem (that i can see) with this scenario. If I have chosen a password on my own, one that I can remember easily, then the only time I think about it is when I type it when I login, and at that point it is completely invisible to me and to anyone else looking over my shoulder (unless they watch my fingers type it -- a good reason to type quickly and pick a password that can be typed quickly :-). However, if I select a complete random password and then write it down on a slip of paper which I keep in my wallet, then I'm not likely to remember the password (especially if I'm a casual user, which is what many of the people who don't select secure passwords are), so I have to take that paper out of my wallet and look at it every time I login. How long do you think it's going to be before someone surreptitiously glances over my shoulder when I take it out to look at it and therefore gets my password? >The only difficulty I know of in this method is that users may not protect >the paper as well as they protect their keys and credit cards. I do not >know how to address this problem. There is no question about this. People will *not* protect their password the way you are claiming they will. This has been proven time and time again. I consider it much more secure to have an easy-to-remember password in the computer than to have a hard-to-remember password in someone's wallet. Just my two cents worth.... Jonathan Kamens MIT Project Athena
dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (01/10/89)
In article <900@eta.unix.ETA.COM> bstrand@woods.unix.eta.com (Brad Strand) writes: >The recent discussions regarding Unix password security (and the lack >thereof) got me wondering about other authentification schemes. One >such scheme that I haven't seen mentioned here, is replacing the password >with a 'pass-function'. By that I mean that instead of having a >password such as "xyzzy", each user would have his/her own personal >function F, perhaps like > > F(C) = 4C + 3 > >The idea would be for the system to replace the "password:" prompt >with a prompt more like, "How about C?", where C is some reasonably >small (maybe 16-bit) random "Challenge" number generated by the system. >The user must then apply his/her pass-function to this particular C, >and enter the resulting F(C). Your idea is good except that most of the users will be mathematically illiterate. Hence their choice of function will be rather limited. A better ideas I have heard of a long time ago was that of challenge response using a sequence of words pre-established by the user: Computer: mumble You: zark Then: Computer: hurkle You: twongly After exhausting the challenges: Computer: mumble You: quark The major problem is that the list of challenge/response groups must be kept, and the computer has to remember each response for the last challenge. And whether for a given challenge what the correct response out of many it should be. Of course human factors being what they are most people won't remember which of the responses the challenge wants next so we have to accept any of the valid, but a monitor or person watching your typing may figure out what's going on soon enough. Thus the /etc/shadow might be: dlm:mumble;zark,quark,feeble/hurkle;twongly,ungly/snark;agony,fit: Of course one should still encrypt and hide the file. -- =Dennis L. Mumaugh Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.com
dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (01/10/89)
In article <4612@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: Dennis Mumaugh writes and Barry argues and then Basically, I claim you have just rested your argument on the proposition that such systems as RSA and other public-key data encryption methods are completely useless and fundamentally flawed, even in the casual sense (ie. without presupposing teraMIPS computers.) Is that a fair summary? Is that where you want to stand? No, this is NOT my position. The encryption used for passwords is not *fundamentally* flawed! It is restricted so that the work-factor is much too low. Work-factor is a cryptologic word that defines the amount of resources of a postulated type needed to break an encryption and either recover the plain text and/or the key. It assumes various factors such as message size, change of crypto variables and the technical means to do the breaking. In the case at hand, the V7 encryption was adequate at the time it was designed 10 years ago. With good password management methods it is adequate (barely) right now. It is currently within the state-of-the-art to break passwords by brute force using the current scheme. {Based on human nature and clever crackers.} The password encryption alogithm needs strenghtening! RSA or DES or any other encryption scheme will work if the key space is expanded much more. An 8-character password as currently implemented with UNIX is getting to be too short. Increasing the length of the password (and hence the encrypted result) will make it much harder to break. The salt is a specious argument. Its original purpose was to disguise the fact that a given user used the same pasword on different systems. Ken Thompson and Bob Morris made a hobby in the early day [1974-77] of cracking all the systems/passwords they could. In the LA area they discovered several people had accounts on diverse machines: RAND, UCLA, USC-ISI, etc. and it was easy to see if the passwords were the same on different machines. I agree with Barry that it is sometimes possible to trick programs to give read access to protect files: I know a couple of programs that will. But shadow passwords are an extra precaution, not the only precaution. Consider typical cracker like a burglar -- they are snatch and grab, get in and get out before you get caught. Consider breaking /etc/shadow being more like the house guest rummaging in your desk while you are sleeping or a house sitter while you are on vacation. In a properly secured system only authorized users will get logged-in. Hence the crackers are usually an authorized user. If the password is in a read-protected shadow, most amateur crackers will try other methods first. Unless they are really sophisticated or have a lot of time to break the system. In almost any system there are a lot easier ways to breakin rather that try to read /etc/shadow. Trojan horses and trapdoor programs provide a faster and more productive way. Few of the typical system administrators have cleaned-up their system so well that password cracking is the fastest way. Smart people use trusted programs for password changing and are always careful not to type stupid things like "chmod +r *" while in /etc. Inexperienced systems adminstrators are the most serious threat to a system's integrity second only to a complacent administrator. Of course the possibility that a shadow password file can give a false sense of security needs to be addressed. One could have a cron job to ensure that critical files are always kept secure -- nice place to attack the system though. One could also keep the password outside of the file system in a raw partition that is known to the system. The flaw there is how one does a back-up of the passwords [what if the disk gets corrupted?]. Implementing system calls for password change and password verify is a good start but then the bute force attack is just to have a C program feed the kernel a lot of stuff. In short for each attack there is a defense and for each defense there is an attack. Also the best computer security expert is an ex-cracker. The best cracker is one who has done software support! Short of physical security the only safe approach is to do everything possible and layer the defenses. But one must design the defenses so they add not merely inclusive or the protections. In reality a vigilant person ought to suspect penetration and think along the lines of damage assessment. -- =Dennis L. Mumaugh Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.com
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/10/89)
In article <8705@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: >How long do you think it's going to be before someone surreptitiously >glances over my shoulder when I take it out to look at it and >therefore gets my password? As you mentioned, but apparently didn't take seriously, they are likely to watch you type your password, which is easier than peeking at the paper. I don't think having to refer to the paper is appreciably less secure than having to enter the password. The problem lies in GUARDING the paper. For example, do you burn or shred it when discarding it? Worse yet, many users write the password on their deskpad calendars or pull-out shelves, for "convenience". That make the password available to anyone who wanders by while the desk is unattended. No matter how much you tell users not to do this, so long as the password is one they cannot easily remember sooner or later some of them are going to compromise it this way. Your personal use of paper in your wallet is not the worst security problem in such an environment.
jik@athena.mit.edu (Jonathan I. Kamens) (01/10/89)
In article <9326@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >No matter how much you tell users not to do this, so long as the >password is one they cannot easily remember sooner or later some >of them are going to compromise it this way. Your personal use of >paper in your wallet is not the worst security problem in such an >environment. I think we're sort of agreeing with each other :-). We both agree that the use of passwords that are hard to remember causes a decrease in security. I feel this way (and I think you will agree with my reasoning) for the following reasons: 1. A harder to remember password is typed more slowly by the user. When a password is typed more slowly, it is easier to read what the user is typing off of his fingers as he types it. 2. A harder to remember password is written down by the user. Forcing the user to write down his/her password is a problem because no matter where he writes it down and how securely he treats that piece of paper (or whatever), it is still more likely that someone will see it and get his password. Furthermore, users are known not to be careful (as you pointed out), so it is more likely that the password will be written down in an insecure location (taped to the terminal, pull-out desk, etc.) than that it will be written in a secure location. There is a third reason why hard-to-remember passwords are a problem: 3. Users will forget hard-to-remember passwords more often and/or lose the paper on which the password is written, so system administrators will have to put up with people coming to them and asking, "Can you change my password to something simple because I forgot what it is?" much more often. So, are we arguing the same side, or what? Jonathan Kamens MIT Project Athena
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/11/89)
In article <2362@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes: >The password encryption alogithm needs strenghtening! RSA or DES >or any other encryption scheme will work if the key space is >expanded much more. That's too generous -- the cryptosystem must also be inherently "strong". Certainly if the key space is small enough, exhaustive search is possible, but the converse is not necessarily true! In reality, crackers are as unlikely to cryptanalyze the password encryption system as burglars are to pick your lock. They will use force instead.
astieber@csd4.milw.wisc.edu (Anthony J Stieber) (01/11/89)
How about this: Each account has several passwords only one is active at a time. On each login the next password (or phrase) is activated. An alternative would be that at logout a password would randomly be chossen and message refering to that password would be printed for the user. The advantage to this is that a user would know the moment they tried to login that some one has used their account (unless all passwords were broken).
heilpern@ibd.BRL.MIL (Mark A. Heilpern ) (01/11/89)
In article <329@csd4.milw.wisc.edu> astieber@csd4.milw.wisc.edu (Anthony J Stieber) writes: .>How about this: .> Each account has several passwords only one is active .> at a time. On each login the next password (or phrase) .> is activated. An alternative would be that at logout .> a password would randomly be chossen and message .> refering to that password would be printed for the .> user. The advantage to this is that a user would .> know the moment they tried to login that some one .> has used their account (unless all passwords were .> broken). Too many people are complaining that their users can not remember 'complicated' passwords like "bad!memory", so how can we expect them to remember what the computer said (eluded) their next password will be? Also, when it came time to change the password, would he have to change all of them, or just the one last used? -- |\/| | | | _ |< / \_(_(_)\_/ \______
flint@gistdev.UUCP (01/12/89)
I really don't see why the encrytion can't allow you to use longer phrases as your password: When limited to 8 characters, you have to do weird things to it (include punctuation, strange vowel combinations, etc.) to make it secure because if you just type in an 8 character English language word it is too easy to crack it. People can remember phrases just as easily as words: if my password could be "The quick brown fox Jumped over the lazy dog" I could type it quickly so onlookers couldn't match it, I could remember it a lot easier than "qw12;Vwe", and with that length I could get a secure result: all I have to remember is the phrase and one or two quirks like that the J is capitalized.
astieber@csd4.milw.wisc.edu (Anthony J Stieber) (01/12/89)
In article <244@ibd.BRL.MIL> heilpern@brl.arpa (Mark A. Heilpern (IBD) <heilpern>) writes: >In article <329@csd4.milw.wisc.edu> astieber@csd4.milw.wisc.edu (Anthony J Stieber) writes: >.>How about this: >.> Each account has several passwords only one is active >.> at a time. On each login the next password (or phrase) >.> is activated. An alternative would be that at logout >.> a password would randomly be chossen and message >.> refering to that password would be printed for the >.> user. The advantage to this is that a user would >.> know the moment they tried to login that some one >.> has used their account (unless all passwords were >.> broken). > > >Too many people are complaining that their users can not remember >'complicated' passwords like "bad!memory", so how can we expect them to >remember what the computer said (eluded) their next password will be? >Also, when it came time to change the password, would he have to change >all of them, or just the one last used? Well, if remembering is a problem, the first method can be used. Each password is used in turn. The passwords themselves might be an easily rememberd phrase. One problem that I see now is that this will only keep out intruders over the long term. Most problems occur however, with the very first illicit login. For maximum security each password would have to be changed one at a time on each login. If this were not done, an intruder could just successfully login once then attempt to change each password one at a time. A less secure way would be to require all passwords to be changed by typing them all as a single string to replace them with another string containing the new passwords. The latter method would be the easiest mnemonicly. Of course all of this could be worthless. ...comments? -- Tony Stieber astieber@csd4.milw.wisc.edu Postscript programmers do it on the sheets.
roth@macom1.UUCP (Dennis Paul Roth) (01/13/89)
In article <8705@bloom-beacon.MIT.EDU>, jik@athena.mit.edu (Jonathan I. Kamens) writes: ( I deleted some stuff - DPR ) > so I have > to take that paper out of my wallet and look at it every time I login. > How long do you think it's going to be before someone surreptitiously > glances over my shoulder when I take it out to look at it and > therefore gets my password? That's a security problem of a different sort. Now your talking about some one at the job site, in your office, looking over your shoulder. There is no protection against an insider. An insider doesn't need to steal your password, he can steal your backup tapes or printouts. The insider may already have an account on the computer and doesn't need your account. In high security installations the most serious security breaches come not from outsiders breaking in but from insiders selling out! If you can't trust the people you work with your working with the wrong people. -- Dennis Roth ...grebyn!macom1!roth Centel Federal Systems roth@macom1.UUCP 11400 Commerce Park Drive Reston, VA 22091-1506 A posting a day keeps the boredom away. 703-758-7000
roth@macom1.UUCP (Dennis Paul Roth) (01/13/89)
In article <329@csd4.milw.wisc.edu>, astieber@csd4.milw.wisc.edu (Anthony J Stieber) writes: > How about this: > Each account has several passwords only one is active > at a time. On each login the next password (or phrase) > is activated. An alternative would be that at logout > a password would randomly be chossen and message > refering to that password would be printed for the > user. (stuff deleted - DPR ) Naw, I don't like this idea at all. Too much memory power is required from the user. There is no way I'm going to remember which password in the sequence of passwords I used last. I'll end up having to try them all. I can see myself now, talking to some irate customer over the phone and trying time after time to get logged on so I can get at the information he needs. Logins failing and me not knowing if it was because I typed in the wrong password in the sequence, or the right password with a typo. If we make the login procedure tough enough we'll have the ultimate in security, all the info nice and safe because no one can get logged on to get at it! -- Dennis Roth ...grebyn!macom1!roth Centel Federal Systems roth@macom1.UUCP 11400 Commerce Park Drive Reston, VA 22091-1506 703-758-7000
tim@scsmo1.UUCP (01/15/89)
The idea of a pass phrase is nice but I'm not going to start hacking on my system to impliment it until I see some proof that it is better. Currently on my system I have: passwords must be at least 6 char. passwords must have a non alpha char. using this I have about 400,000 passwords for the typical user. Must users will pick a password like pencil1. They pick a digit (typicaly 1) and a word. I figure 20,000 words * 20 digit combinations = 400,000 passwords. Now if I were to use phrases I would bet that at least one passphrase would be "mary had a little lamb." If I saw that a user typed "little" it would be easy to to guess. I have asked users to come up with a pass phrase and most will come up with something predictable. So far the common ones are "mary had a ..." "Soil Conservation Service" and "I don't want to type this much" I think that all it would take to break this approach is to log the phrases and make users change them weekly. You would have a nice big list to crypt for craking purposes. The only ideas that I have seen that I think will be a great improvment will change the salt perturb table in a machine independant way. (like prompt the sysop for a key when setting up or use the serial no.) Or check the time between keystrrokes. This won't work over dialup lines if you set the timeing at work but how about more than one dataset. I have seen an example of useing a timed passwd() and it works, I could not get it to accept the correct password and the only one that could was the one who set it. -tim@scsmo1.uucp tim hogard usda-scs