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.