gordon@sneaky.TANDY.COM (Gordon Burditt) (11/21/88)
The DES algorithm used in password encryption takes 56 bits of key information from the user's typed in password, and uses this key to encrypt a constant some number of times. (What constant and how many times aren't relevant here.) The 56 bits are taken as the 7 low-order bits of each of 8 characters of the password. A brute-force exhaustive search would seemingly require up to 2**56 encryptions. However, the number of likely 56-bit keys is reduced considerably for various reasons: - Certain characters are untypable in passwords: nul, newline, backspace, and line-kill characters, and possibly ^S, ^Q, and ^M. - Users tend not to like to type control characters and shifted characters. - Users tend to choose passwords that make sense and are easy to remember. Assuming for the moment that DES is kept, security would be increased if more of the 2**56 bit combinations were generated by "obvious" passwords that users can easily remember. So, I propose the following change to the password algorithm. It can be implemented by someone having the source to login (see alt.sources for a recently posted one), passwd, su, and related programs, and the object code to crypt(3). - Change the length of the password to 28 characters minimum, 512 characters maximum. - Map this password into an old-style 8-character password that crypt(3) takes. - Call crypt(3) to get an encrypted password. The mapping algorithm works like this: First, shorten the password to 28 characters. Break the entered password into 28-character blocks, with the last one padded out to 28 characters with nulls. Combine the 28-character blocks by adding the corresponding characters in each block to generate a sum 28-character block. This isn't supposed to be hard to crack, but it does mean that whether the user finishes the word that ran over 28 characters or not DOES make a difference. Next, derive TWO BITS from each of the 28 characters. I suggest using the low-order bit and the parity. Map the 56 bits into the 7 low-order bits of 8 characters of a conventional password. Since crypt(3) ignores the high-order bits (8-bit-character chauvenism here), set all of them, so if one character happens to be all zeros, it won't terminate the string. Add a null as the 9th character to terminate the string. I can hear the arguments now: "But...But...But...there are millions of ways to type the user's password, and one of them might be easy to guess!" Yep. Each password has a "canonical representation" consisting of a 28-character string containing only the characters "0", "1", "2", and "3". There are millions of times more ways to type a given correct password than there are canonical wrong passwords. There is even a 25% chance that if you type your password in with one character wrong, you will get in anyway. This mapping scheme should be explained to users so they don't lose confidence in the system (at least not for the wrong reason). Now, what about attacks? Dictionary attacks are greatly complicated. Let's suppose that all passwords are 4 words from /usr/dict/words. The number of combinations went from 24,000 (single word) to 24,000**4, or about 3.3 * 10**17. This is about 4 times the number of canonical passwords, or worse than brute force. How about pre-computed encryption dictionaries? Well, it's no longer safe to assume that only printable characters appear in the 8-character password fed to crypt(3), so the size goes up by a factor of about 10. If the assumption was being made that passwords are lower-case alphanumeric, the size goes up by a factor of about 25,000. You know the guy and he's in love with his car? Well, his license plate number, pet name for his car, make, and model are all under 28 characters, so they can't be the whole password. Even if you think he used 3 of these together, that's 24 orders, times lots of combinations of with and without spaces, capital letters, etc. And who says his dealer's phone number isn't in there? Things like license plate numbers, phone numbers, social security numbers, first names, etc. can no longer be a whole password. Well, what does anyone think? Does having multiple correct passwords scare anyone off? Some other suggestions: if possible, use shadow password files. In spite of arguments that they aren't totally secure (theft of backup tapes, for instance), they do provide some protection. The recent Internet Worm COULD HAVE sent back copies of password files for every system it infected. It couldn't have gotten at shadow password files. There is also no risk from a badly-configured or buggy uucp allowing a uucp neighbor to grab the encrypted passwords, since uucp doesn't have access to them. If you have the expertise to fool with crypt(3) and be sure you aren't weakening the encryption, make the salt bigger. 4096 combinations isn't enough. Gordon L. Burditt ...!texbell!sneaky!gordon
mesard@bbn.com (Wayne Mesard) (11/22/88)
From article <4449@sneaky.TANDY.COM>, by gordon@sneaky.TANDY.COM (Gordon Burditt): > Assuming for the moment that DES is kept, security would be increased if more > of the 2**56 bit combinations were generated by "obvious" passwords that users > can easily remember. So, I propose the following change to the password > algorithm. [...] > - Change the length of the password to 28 characters minimum, 512 characters > maximum. Whether or not your proposal makes technical sense, you have forgotten an important element of this equation: human nature. Yes, the very same thing that you're trying to circumvent by coercing people into using an absurdly combersome mechanism. What would happen if this procedure were enacted? I'll tell you: o More people would stay logged in overnight and when they go to lunch, becuase it's become such a pain to login again. o More people would write their passwords on slips of paper taped to their desk because it's become such a pain to remember. o More people would choose easy passwords (e.g. 28 "a"s, or the alphabet plus their initials) to try to make memorization easier. o More people would use the same password for the various machines on which they have accounts. The people who are security conscious, will select non-obvious passwords, just like they always have, but if you want to have an impact on the rest of us, coersion is not the way. Your efforts will be best spent in making sure that those who most need to be "security literate," are. This includes sys-admins (I could list some root passwords that would make an NSC staffer pull his hair out), and those working on proprietary information (corporate or national). > > Gordon L. Burditt > ...!texbell!sneaky!gordon -- unsigned *Wayne_Mesard(); "He sounds like a really weird guy. What's MESARD@BBN.COM he doing for Thanksgiving?" BBN, Cambridge, MA -DB.
root@conexch.UUCP (Larry Dighera) (11/25/88)
In article <4449@sneaky.TANDY.COM> gordon@sneaky.TANDY.COM (Gordon Burditt) writes: [...] >- Certain characters are untypable in passwords: nul, newline, backspace, > and line-kill characters, and possibly ^S, ^Q, and ^M. [...] This is incorrect. Virtually any character can be used in passwords as well as lognames. The mechanism which controls this is the stty options in the initial and secondary flags located in the /etc/gettydefs entry currently in effect on the port being accessed. Use of stty to enable literal interpretation of control characters can be very useful in numerous circumstances. Larry Dighera -- USPS: The Consultants' Exchange, PO Box 12100, Santa Ana, CA 92712 TELE: (714) 842-6348: BBS (N81); (714) 842-5851: Xenix guest account (E71) UUCP: conexch Any ACU 2400 17148425851 ogin:-""-ogin:-""-ogin: nuucp UUCP: ...!uunet!turnkey!conexch!root || ...!trwrb!ucla-an!conexch!root
guy@auspex.UUCP (Guy Harris) (11/26/88)
>>- Certain characters are untypable in passwords: nul, newline, backspace, >> and line-kill characters, and possibly ^S, ^Q, and ^M. > >This is incorrect. Virtually any character can be used in passwords >as well as lognames. The mechanism which controls this is the stty >options in the initial and secondary flags located in the /etc/gettydefs >entry currently in effect on the port being accessed. Yeah, but most people tend to consider it rude to leave the tty in "raw" mode once "login" is fired up, so it's generally in cooked mode when the password is being read in, and thus unless you have a character like the "literal-next" character, certain characters *are*, in fact, untypable in passwords, including all the ones listed above. Yes, Virginia, there are UNIX systems that don't have "literal-next". Of course, NUL is typable, even in cooked mode on systems without "literal-next"; however, since the password is, in general, a C-language string, NUL is obviously not a valid character in a password....
ok@quintus.uucp (Richard A. O'Keefe) (11/27/88)
In article <517@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: > >>- Certain characters are untypable in passwords: nul, newline, backspace, > >> and line-kill characters, and possibly ^S, ^Q, and ^M. > >This is incorrect. Virtually any character can be used in passwords >certain characters *are*, in fact, untypable >in passwords, including all the ones listed above. Yes, Virginia, there >are UNIX systems that don't have "literal-next". System V has back-slash, which will quote the character-delete and line-kill characters. When I use a V.3 system here, I have erase=^h, kill=^u, eof=^z. A test program which calls getpass(3) and prints the result in hex shows that I can use all three of these characters. But I can't use my intr or quit characters. I do not know whether this will work in V.2, but I expect it will.
gordon@sneaky.TANDY.COM (Gordon Burditt) (11/27/88)
In article <32582@bbn.COM> mesard@bbn.com (Wayne Mesard) writes: >From article <4449@sneaky.TANDY.COM>, by gordon@sneaky.TANDY.COM (Gordon Burditt): >> can easily remember. So, I propose the following change to the password >> algorithm. >[...] >> - Change the length of the password to 28 characters minimum, 512 characters >> maximum. > >Whether or not your proposal makes technical sense, you have forgotten >an important element of this equation: human nature. Yes, the very same >thing that you're trying to circumvent by coercing people into using an >absurdly combersome mechanism. What would happen if this procedure were You do have a point that user education and ease-of-use is an important consideration. I think the annoying feature of a longer password is outweighed by the ability to use English words without restricting the choices so much that a dictionary attack is feasable. No, I don't expect anyone to use 512-character passwords, especially since every possible password in the scheme I described can map into a 28-character string containing only the digits 0, 1, 2, and 3. >enacted? I'll tell you: > o More people would stay logged in overnight and when they go to lunch, > becuase it's become such a pain to login again. Which is easier to type, "x5Ybn$1'" or "bicycle pumps fly north in June"? For people who are used to typing words, the second can be easier even if it's longer. I remember one 8-character password I had that seemed to be pretty secure against penetration even when it was dictated over the phone, slowly, to another person trying to use it. He still couldn't get it after 6 dictations and 12 tries. I had no trouble remembering it because it meant something to me. There are some people who think it's a real pain to log in again. The ones I know seem to prefer typing something like "interviewing at the Kremlin" ("interviewing" is a terminal lock program with about 50 other links to it, including "sleeping", "hiding", and "gone") and then their password when they come back. Typing "interviewing at the Kremlin" is obviously much easier than typing control-D and a 2-character login name. > o More people would write their passwords on slips of paper taped to > their desk because it's become such a pain to remember. I disagree that 28-character passwords consisting of English words are harder to remember than 8-character random garbage. And because of the greater number of combinations, they can be more secure. Guessing 4 randomly chosen words out of /usr/dict/words is about 8 times harder than guessing all possible 8-character passwords. > o More people would choose easy passwords (e.g. 28 "a"s, or the > alphabet plus their initials) to try to make memorization easier. No, I think they would choose words and phrases. Even if the 28-character password is taken to be "9 consecutive 4-letter cusswords", or "7 consecutive 4-letter cusswords and the sysadmin's name" there are still lots of combinations. Gordon L. Burditt ...!texbell!sneaky!gordon
scs@athena.mit.edu (Steve Summit) (11/28/88)
>> >>- Certain characters are untypable in passwords: nul, newline, backspace, >> >> and line-kill characters, and possibly ^S, ^Q, and ^M. >>Yes, Virginia, there are UNIX systems that don't have "literal-next". >System V has back-slash, which will quote the character-delete and line-kill >characters. And, in fact, using devious combinations of backslash and/or the erase character can make for rather secure passwords, especially if what you're worried about is people looking over your shoulder as you type. I once had a root password with an explicit rubout in it, which had to be quoted with a \ when typing it. Lately, when using rlogin and telnet, I've been deliberately mistyping my (normal, printable) password, and correcting it in mid-stream, dodging behind a few meaningless backslashes just for good measure, in case there are any network snoop programs running, which are clever enough to grab password packets but not clever enough to reproduce the tty driver in all its arcane detail. (Whoops, I guess the trick's not much good now that the secret is out.) Steve Summit scs@adam.pika.mit.edu
lvc@cbnews.ATT.COM (Lawrence V. Cipriani) (11/28/88)
One enhacement to security I have seen on mainframes running UNIX(tm) is to have a "External Security Password" that is settable by the system administrator. The admin will change it monthly. Typically it is "pronouncable but hard". To login successfully, you have to give your login, your password, and the ESP. Then, if any of these is bad, you're repompted. This helps security by ensuring that there is at least one hard password. The bad part is that you have to distribute the new password to all the users. I like this system pretty well. -- Larry Cipriani, AT&T Network Systems, Columbus OH, Path: att!cbnews!lvc Domain: lvc@cbnews.ATT.COM
jmc@ptsfa.PacBell.COM (Jerry Carlin) (11/29/88)
In article <2349@cbnews.ATT.COM> lvc@cbnews.ATT.COM (Lawrence V. Cipriani) writes: >One enhacement to security I have seen on mainframes running UNIX(tm) is >to have a "External Security Password" that is settable by the system >administrator. A little documented feature of V.2+ systems is a 'dial password'. Create a file /etc/dialups (with a list of ports such as): /dev/tty12 /dev/tty13 Create a file /etc/d_passwd: :passwd1: /bin/sh:passwd2: /bin/rsh:passwd3: (restricted shell not remote shell) /bin/ksh:passwd4: /bin/csh:passwd5: /usr/lib/uucp/uucico:: (i.e., no password for uucico) The first line is for those with nothing in field 7 of /etc/passwd (default). This scheme gives the administrator the ability to implement a second password on a list of ports and to make it different by 'shell' (actually any program in field 7 of /etc/passwd). You can generate passwords using /usr/lib/makekey (undocumented until V.3.?) or by creating a dummy login, doing a 'passwd' and then moving the resulting encrypted passwd to /etc/d_passwd. Enjoy. -- Jerry Carlin (415) 823-2441 {bellcore,sun,ames,pyramid}!pacbell!jmc To dream the impossible dream. To fight the unbeatable foe.
guy@auspex.UUCP (Guy Harris) (11/30/88)
>One enhacement to security I have seen on mainframes running UNIX(tm) is >to have a "External Security Password" that is settable by the system >administrator. This is, as I remember, present but @#!$%#@! undocumented in, at least, later S5 releases, with the "dialup password" mechanism.
ted@nmsu.edu (12/07/88)
I would let all of this discussion about pin's and password protection just slide on by, except for the fact that a friend of mine was apparently a recent victim of an atm fraud. The situation was that she went to the bank to make a withdrawal and they said that her account had only $5 in it. She objected that according to her records she had over $700 in the account and that she had not made any withdrawals recently. The bank claimed that she had made 5 withdrawals in one day for virtually the entire amount in the account, leaving only the minimum in the account. Upon presentation with a written complaint, the bank checked the camera for the atm and found that it had been blocked during the time of the withdrawals in question. The bank is currently standing pat on the absolute security of the atm system and is insisting that they have no obligation to disburse any of the questioned funds. Combined with the recent discussion on the net about the errors that have occurred in atm software and with the fact that some systems store the pin (or the encrypted pin) on the card, there is considerable doubt in my mind about whether atm's provide even minimal levels of security. My questions for the net are: 1) are account and pin numbers really stored on the card in such a way that a card can be easily forged (please, no secure details, I just need enough information to believe you). 2) how autonomous are atm machines? 3) to what degree do atm's record transactions. I know they record the account number and amount, but do they record erroneous pin entries, and do they record the pin number that is actually entered? Is there enough of an audit trail to substantiate a claim of card forgery? 4) are there any publicly available accounts of atm fraud, or breakdowns in atm security? (the bug mentioned on the net recently would classify, but did the company involved manage to sufficiently hush up the problem so that it has effectively been pushed into the apocrypha of computer security?) If your reply is not suitable for public dissemination, please reply by email, usmail or phone. I will or will not summarize to the net depending on the wishes of individual respondents. I will honor requests for anonymity, but obviously, in the current situation, I would prefer to find experts in the field whom I can cite. Thank you. Ted Dunning Computing Research Laboratory New Mexico State University Las Cruces, New Mexico 88003-0001 ted@nmsu.edu (505) 646-6221
vrao@hubcap.UUCP (Venkateshwar Rao) (12/07/88)
From article <17730@adm.BRL.MIL>, by ted@nmsu.edu: > > The situation was that she went to the bank to make a withdrawal and > they said that her account had only $5 in it. She objected that > according to her records she had over $700 in the account and that she > had not made any withdrawals recently. The bank claimed that she had > made 5 withdrawals in one day for virtually the entire amount in the > account, leaving only the minimum in the account. Upon presentation > with a written complaint, the bank checked the camera for the atm and > found that it had been blocked during the time of the withdrawals in > question. > Did your friend lose her card or do you think that someone temporarily 'stole' the card and forged it? -- Ellanki Venkateshwar Rao.
roy@phri.UUCP (Roy Smith) (12/07/88)
ted@nmsu.edu writes: > The bank claimed that she had made 5 withdrawals in one day for virtually > the entire amount [$700] in the account The Citibank atms have limits on the number of cash withdrawals and the total amount of cash you can withdraw in one day. I don't remember the exact numbers, but it's something like 2 transactions a day for up to $500 total. It seems to me that any system which does not have a similar safeguard is lax about security. GOK what this has to do with unix wizards, though. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network"
cml@brachiosaur.cis.ohio-state.edu (Christopher Lott) (12/07/88)
In article <3627@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >ted@nmsu.edu writes: >>The bank claimed that she had made 5 withdrawals in one day for virtually... >The Citibank atms have limits on the number of cash withdrawals and... Hi, Nothing against all of you, I *do* find this discussion extremely interesting due to my ATM card ownership && (meagre :-) funds behind those machines, but ATM security was hashed out at great length in comp.risks some weeks ago, and IMHO this is not helping the unix.wizards group. Could this discussion please be carried on in comp.risks and comp.security? I read those journals too..... (I tried to set the followup-to line, hope I did ok.) thanks. chris... -=- cml@tut.cis.ohio-state.edu Computer Science Department, OSU 614-292-6546 or: ...!{att,pyramid,killer}!osu-cis!cml <standard disclaimers>
ron@ron.rutgers.edu (Ron Natalie) (12/08/88)
The cards themselves are easily forged. Essentially, nothing is encoded in the stripe that you can't see on the front of the card. Obviously criminal elements have the ability to forge this information because well publicised cases of credit cards (which use the same technology) exist. When dealing with a machine, it's even easier, the card doesn't need to look real to the eye, just have the correct data on the stripe. Even if the PIN records at the bank are relatively secure, there are many ways that the 4 digit number may be discovered. Abuse of telephone credit card numbers (which are essentially just your account number ( phone number) and a 4 digit PIN) inidicate how vulnerable that system is. Banks mail PINs (albeit separately from the cards) through the use of printthrough computer envelopes. You don't even need to open these to get the information. Banks should never send the PINs out. Here we get to go to the bank to set them. People should safeguard their PINs. Be careful about the guy behind you in line. Don't write them down, and if you get to pick your own, don't be so bloody obvious. I guessed my wifes with little difficulty.
cory@gloom.UUCP (Cory Kempf) (12/09/88)
Has anyone ever noticed that most of the ATM machines that are out there is the real world (at least in the US) have a vertical keypad? Does anyone really think that it is possible (without being a contortionist) to prevent the person behind you from seeing as you type in the PIN? Can anyone come up with a way to make it *easier* for someone else to see you type in your PIN? Retorical question time... why do most banks NOT use horizontal keypads (as well as other security measures)? GAK +C -- Cory Kempf UUCP: encore.com!gloom!cory "...it's a mistake in the making." -KT
cory@gloom.UUCP (Cory Kempf) (12/21/88)
In article <4420@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: > >Given a 100 character character set and 8 characters in a password >the search space is 100^8 which is: > > 10,000,000,000,000,000 Except for one little problem... I don't think that the average secretary is capable of remembering a password like 'z&B_= ^W4' If she is given the chance to select a password for herself (I am using the female form 'cause the secretary here is female), she is most likely going to choose one that can be found in either a dictionary or a list of names. (For that matter, so will a lot of people who 'know better'). As has been shown, the search space is considerably reduced... to the point that on a machine with 20 users, the chances of finding a valid password are fairly good. By increasing the number of significant characters, the chances of an easily guessed password drop. >Currently even fast DES implementations on fast processors can't seem >to hit 1,000 encryptions per second although it's probably possible, >let's allow 20,000 encryptions per second, a brute force search would >now take: > 500,000,000,000 >500 billion seconds or almost 16,000 years. Even improving *that* by a >factor of 1,000 (ie. 20,000,000 encryptions per second) wouldn't leave >much hope for the cracker (16 continuous machine-years.) I wonder... with Thinking Machine's offer to allow people on the internet to access a Connection Machine, has anyone tried to write an algm. for brute force password testing for such a machine? (ie with 64k processors, each at 1000 encryptions a second it is down to about 3 mos. -- unfortunately, I don't know enough about the connection machine and DES to know how reasonable this is... (mean time 'till success would be around 1.5 months -- shorter if the seach is set up with a bit of forethought (ie start with unshifted keys, then shifted, then control, etc] Besides, it would make me feel better if someone who managed to watch me key in a password (I try to avoid this) had to catch more than 8 characters... +C -- Cory (...your bravest dreams, your worst nightmare...) Kempf UUCP: encore.com!gloom!cory "...it's a mistake in the making." -KT
bzs@Encore.COM (Barry Shein) (12/21/88)
From: cory@gloom.UUCP (Cory Kempf) >>Given a 100 character character set and 8 characters in a password >>the search space is 100^8 which is: >> >> 10,000,000,000,000,000 > >Except for one little problem... I don't think that the average >secretary is capable of remembering a password like 'z&B_= ^W4' The average secretary I know is bright enough to understand rules like "use two short words with some upper-case letters and/or digits thrown in and separated by a punctuation, like "Hey!Jude" "FidoIS#1". Very hard to guess, very easy to remember, next... >>500 billion seconds or almost 16,000 years. Even improving *that* by a >>factor of 1,000 (ie. 20,000,000 encryptions per second) wouldn't leave >>much hope for the cracker (16 continuous machine-years.) > >I wonder... with Thinking Machine's offer to allow people on the >internet to access a Connection Machine, has anyone tried to write >an algm. for brute force password testing for such a machine? (ie >with 64k processors, each at 1000 encryptions a second it is down >to about 3 mos. -- unfortunately, I don't know enough about the >connection machine and DES to know how reasonable this is... (mean >time 'till success would be around 1.5 months -- shorter if the seach >is set up with a bit of forethought (ie start with unshifted keys, then >shifted, then control, etc] Cargo cult worship, each CM processor is not very fast (that's part of the point, use lots of small processors and try to beat the price-performance curves), I mean, we can fantasize and postulate a machine which *can* break a password in some reasonable amount of time at which point of course it becomes doable. But it doesn't exist, so what's the point? >Besides, it would make me feel better if someone who managed to >watch me key in a password (I try to avoid this) had to catch >more than 8 characters... Well, if what we're really talking about is making you and others *feel* better rather than trying to understand security a little better and gauge effective methods to obtain reasonable security levels then that explains everything. Perhaps security would be improved on your system by throwing back a good double of Scotch? -Barry Shein, ||Encore||
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (12/21/88)
The simple solution seems to be to force users to use some non alpha character somewhere in the middle of their passwords. Users then tend to use a combination of two words which prevents the dictionary search. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Support ISO 8859/1 zeeff%b-tech.uucp@umix.cc.umich.edu Ann Arbor, MI umix!b-tech!zeeff
prh@actnyc.UUCP (Paul R. Haas) (12/22/88)
In article <4444@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: >The average secretary I know is bright enough to understand rules like >"use two short words with some upper-case letters and/or digits thrown >in and separated by a punctuation, like "Hey!Jude" "FidoIS#1". Very >hard to guess, very easy to remember, next... Give a thousand secretaries that same set of instructions and you will get far less than a thousand different passwords. Sort them in order of frequency and try them all on whatever system you are trying to crack. You certainly won't be able to break all the accounts, but you will get a few. Many people may prefer to listen in on a large ethernet rather than deal with a thousand secretaries, but the result should be the similar. If people are allowed to create their own passwords, there should not be a way to try ten thousand different passwords on each account with out triggering some alarm. If security is really important it may be usefull to put the shadow password file on a separate server machine. The server machine should be physically and electronically remote so that the only requests it services are "check password/username", "add password/username", "remove password/username" and "changepassword newpassword/oldpassword/username". This implies that backups and restores have to be done manually. A logical migration path to a secure password server is to use a shadow password file which is normally only accessable through a small well defined interface. ----- Paul Haas uunet!actnyc!prh haas@frith.egr.msu.edu (212) 696-3653
haynes@ucscc.UCSC.EDU (99700000) (12/23/88)
In article <5005@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >The simple solution seems to be to force users to use some non alpha >character somewhere in the middle of their passwords. Users then tend >to use a combination of two words which prevents the dictionary search. the 4.3-tahoe-BSD version of passwd seems to do this. At least the last time I logged into a tahoe system and tried to change my password it wouldn't rest until I had put a non-alphabetic character into it. Had the same experience on a Convex machine. haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ..ucbvax!ucscc!haynes "Any clod can have the facts, but having opinions is an Art." Charles McCabe, San Francisco Chronicle
bzs@Encore.COM (Barry Shein) (12/24/88)
From: prh@actnyc.UUCP (Paul R. Haas) >In article <4444@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: >>The average secretary I know is bright enough to understand rules like >>"use two short words with some upper-case letters and/or digits thrown >>in and separated by a punctuation, like "Hey!Jude" "FidoIS#1". Very >>hard to guess, very easy to remember, next... >Give a thousand secretaries that same set of instructions and you will >get far less than a thousand different passwords. Sort them in order >of frequency and try them all on whatever system you are trying to >crack. You certainly won't be able to break all the accounts, but you >will get a few. Is this based on *anything*? Or just a wild guess, sounds utterly baseless to me. You honestly think if I told 1000 people to: choose two short words separated by a punctuation character and mix some upper-lower case into the words I would frequently get the exact same result from different people? Gads, and what might that result be? The world of human psychology awaits your discovery! (the only exception I can imagine is that if you gave an example they'd all use the example, but other than that, you can check for that easily enough.) >If people are allowed to create their own passwords, there should not be >a way to try ten thousand different passwords on each account with out >triggering some alarm. I doubt you can ever achieve this as someone only needs access to your encryption algorithm. >If security is really important it may be usefull to put the shadow >password file on a separate server machine. The server machine should be >physically and electronically remote so that the only requests it >services are "check password/username", "add password/username", >"remove password/username" and "changepassword >newpassword/oldpassword/username". This implies that backups and restores >have to be done manually. A logical migration path to a secure password >server is to use a shadow password file which is normally only accessable >through a small well defined interface. Unfortunately you now have to trust your network (eg. that I can't send "password ok" messages from a different system.) It's a hard problem, merely adding layers of complexity is not a particularly compelling approach. That's my whole poing. -Barry Shein, ||Encore||
merrill@bucasb (John Merrill) (12/24/88)
In article <4469@xenna.Encore.COM>, bzs@Encore (Barry Shein) writes: > >From: prh@actnyc.UUCP (Paul R. Haas) >>In article <4444@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: >>>The average secretary I know is bright enough to understand rules like >>>"use two short words with some upper-case letters and/or digits thrown >>>in and separated by a punctuation, like "Hey!Jude" "FidoIS#1". Very >>>hard to guess, very easy to remember, next... > >>Give a thousand secretaries that same set of instructions and you will >>get far less than a thousand different passwords. Sort them in order >>of frequency and try them all on whatever system you are trying to >>crack. You certainly won't be able to break all the accounts, but you >>will get a few. > >Is this based on *anything*? Or just a wild guess, sounds utterly >baseless to me. You honestly think if I told 1000 people to: > > choose two short words separated by a punctuation character > and mix some upper-lower case into the words > >I would frequently get the exact same result from different people? Yes, Barry, you would. Why do I know this? Consider the following modification of your paradigm: choose an English word of at most eight characters, mixing both upper and lower case in the word. You must be able to recall this word easily---without writing the word down. Guess what! There's a short list that covers the vast majority of these words. This list is dominated by the hundred most common names (in the local language), followed by a collection of folk names. (For your test, I'd expect to see things like Frodo!Ba[ggins], at least if the target audience was of CS nerds.) Is the idea a bad one? No, not at all, if only because it might take a while to extract the statistics of the process. But in the long run, the two paradigms are probably equal.
debra@alice.UUCP (Paul De Bra) (12/24/88)
In article <5835@saturn.ucsc.edu> haynes@ucscc.UCSC.EDU (Jim Haynes) writes: }In article <5005@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: }>The simple solution seems to be to force users to use some non alpha }>character somewhere in the middle of their passwords. Users then tend }>to use a combination of two words which prevents the dictionary search. } }the 4.3-tahoe-BSD version of passwd seems to do this. At least the last }time I logged into a tahoe system and tried to change my password it }wouldn't rest until I had put a non-alphabetic character into it. }Had the same experience on a Convex machine. } Requiring the use of a non-alphanumeric character is not at all sufficient. Many people react to this by just putting a special character (usually ".") in front of their old password... Now, if you start by forcing users to put the non alphanumeric char somewhere in the middle of the password this would no longer work, but users will still come up with passwords that are a lot easier to guess than zXk.4;ur... Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
sns@genghis.UUCP (Sam Southard) (12/28/88)
In article <5835@saturn.ucsc.edu>, haynes@ucscc.UCSC.EDU (99700000) writes: > time I logged into a tahoe system and tried to change my password it > wouldn't rest until I had put a non-alphabetic character into it. > Had the same experience on a Convex machine. Someone at your site probably modified /bin/passwd. I know of a Convex C1 with the latest software releases from Convex (I think) and it does accept a completely alphabetic password. -- Sam Southard, Jr. {sns@genghis.caltech.edu|sns@genghis.uucp|{backbone}!cit-vax!genghis!sns}
fuka@concave.uucp (Kent Fuka) (12/30/88)
In article <410@genghis.UUCP> sns@genghis.UUCP (Sam Southard) writes: >Someone at your site probably modified /bin/passwd. I know of a Convex C1 with >the latest software releases from Convex (I think) and it does accept a >completely alphabetic password. Recent Convex OS releases support password aging, minimum password length enforcement, and restriction against trivial passwords. These options are enforcable on a per-user basis through a seperate password restriction file (/etc/pwrestrict). It sounds like your system administrator has enabled the restriction against trivial passwords.
devine@cookie.dec.com (Bob Devine) (01/06/89)
John Haugh writes: > 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 [...] No, the original VMS encryption algorithm was called "AUTODIN 2". Essentially it hashed the password into a 32 bit quantity. There were a couple problems with it: 32 bits wasn't enough to prevent several passwords generating the same hash value; and it was too fast. A brute force attack would work. The current algorithm is called the "Purdy" algorithm. It runs about 100 times slower than the other plus it uses a 64 bit value. Bob Devine