Worm/Passwords

[Jonathan Bayer]

In article <13 at herron.uucp>, jbrown at herron.uucp (Jordan Brown) writes:
. jbayer at ispi.UUCP (Jonathan Bayer) writes...
. > In article <10 at herron.uucp>, jbrown at herron.uucp (Jordan Brown) writes:
. > > jbayer at ispi.UUCP writes:
. > > > It is possible to adopt a single system, if that system is random.  For 
. > > > example, I have included below a random password generating program, ...
. 
. > > Somebody go by this fellow's office and look at all the desk blotters and
. > > scraps of paper to find written-down passwords.  Then log in and mail him
. > > a note to go watch War Games.
. 
. >	 Instead of being critical without offering suggestions, why don't you
. > shut up?
. 
. You may disagree with me on the security of randomly generated passwords,
. but I don't think this tone is reasonable.  (At least I don't think my
. comment was this nasty.  My apologies if it came across that way.)
. 
. > I challenge you to develop a program which will create random passwords
. > which will be easy to remember.
. 
. I'm not sure what "easy to remember" means.  Enough users have problems
. remembering passwords that *they* picked to make me doubt that any random
. scheme has any chance.  I didn't mean to say that *your* random password
. program was bad, but that they *all* are.
. 
. I'm not going to try to write a "better" version, as I'm convinced it
. isn't possible to write one "good enough".
. 
. Thinking about it, there's another serious problem.  If you don't have a
. *very* good seed source, your random passwords are easily guessable.
. (For instance, suppose you use the time in seconds as your source.
. if you know what day the password was assigned, then there are only 86k
. passwords to try.  It'll typically take a second or so to try each, so
. about a day of CPU time later...  Time in ms would be better, but it is
. still probably practical to observe password changes and search the
. appropriate range of random numbers.  Write a program that "watches"
. /etc/passwd and logs username and time when it's updated.  Probably
. an adequate solution is to continuously increment a counter while
. waiting for a keystroke.  That's pretty close to truly random.)
. 
. You presented a "solution" to the problem; I poked what I consider
. to be a gaping hole in it, one that I thought was "well-known"
. (documented in a mainstream motion picture, even).
. 
. I hate a flawed solution to a problem more than no solution at all.
. At least when you know there's no solution you aren't deceived.


Your apology is accepted.  I continually see comments that probably are
not meant to offend, but since this is a written medium the tone of voice
does not come across.  I appreciate  your civil reply, as opposed to a
totally bozo response I received by mail.   I will not mention the bozo's
name unless he (see, I've given you a hint  :-)  ) posts his message in
a news group.  

BTW, Brandon Allbery posted a program which is 264 lines long (including
comments) which does pretty much what I asked you to do. It was posted 
to comp.sources.misc.

I agree that if ONE system becomes universal then it makes life easier
for the crackers.  I posted one solution, admittedly a simple one.  Brandon
has posted a more sophisticated one.  I am sure there are others (one which
crosses my mind is to have the password be two random words, seperated by
a non-character.  If the dictionary is big enough then there is a lot of
work for the cracker).  The more solutions which are available, both
publicly and privately, the harder it is for the cracker.

For the bozo who likes to call people names, remember that name-calling
is not going to produce any answers.   Rather, it makes at least one party
upset and angry, while providing you with, perhaps, momentary pleasure.  It
would be better to provide CONSTRUCTIVE critisism (which I will be glad to
take) rather than DESTRUCTIVE critisism (which you are glad to give).

Jonathan Bayer
Intelligent Software Products, Inc.