From: Steve Gibbons <steve@aztech.net>
Date: Fri, 19 Apr 1996 21:25:27 +0800
To: jleonard@divcom.umop-ap.com
Subject: Re: Spaces in passwords
Message-ID: <009A110B.0F384760.631@aztech.net>
MIME-Version: 1.0
Content-Type: text/plain


# > I have a hard enough time getting lusers to choose non-dictionary 
# > passwords that they can *remember* - one technique is to teach sub-100 
# > i.q. types to use two words, seperated by a #,@, etc., with a number 
# > tossed in: kill#pig1et, which isn't a dictionary word, but has a chance of 
# > being remembered without writing it on a sticky note and pasting it to 
# > the @#%&ing monitor.

# It's hard.  I'd really rather have longer pass{words,phrases} so that there's
# the potential for lots of entropy without requiring line-noise for passwords.

One of the ideas that I've been kicking around in the back of my head for a
while for stronger, easier to uses user authentication goes something like
this:

1) User enters a pass-phrase.

2) System "tokenizes" the pass-phrase.
   The tokenization would probably include a normalization step: condensing
   white-space and punctuation, standardizing the casing of words, perhaps 
   even going so far as converting 3133+ speak to something readable.

   Once normalized, the pass-phrase would be parsed, and tokenized.  It would
   be useful to have a large system-wide dictionary, sorted by how common a 
   given word or group of words is normally used in the most commonly used 
   languages that the system's users speak/write.  Any word or group of words
   found in the dictionary would be converted to a number, representing its
   position in the dictionary, and the significant bits of that number are 
   concatenated to a running bit string.  Words and tokens not found in the
   dictionary would pass through some other algorithm that I haven't thought
   too much about, yet.

3A) System examines the tokenized pass-phrase against another (probably _very_
    large) dictionary of common phrases for acceptability.  (maybe just
    comparing the hashes of the phrases [smaller dictionary])

    System also examines the "length" of the tokenized pass-phrase for 
    acceptability (for pass-phrase changes.)

3B) System hashes the tokenized pass-phrase, and compares it against the
    previously stored hash (for authentication.)
    [ Standard crypt(3) stuff ]

Ignoring the fact that strong one-time-passwords are orders of magnitude 
better, what would something like this buy you?

0) "Good" pass-phases should be more difficult to brute-force or inteligently
    attack than simple (8 or 16 byte) passwords.  [ rm /usr/local/bin/crack ]

1) Pass-phrases are generally easier to remember than system-generated
   passwords.  [ no more post-its pasted to screens or hidden under keyboards
   with passwords written on them. ]

2) Pass-phrases can be a pain to type in correctly, the normalization step
   should help in this regard.  [ happier users ]
   
3) Enforcement of selecting good pass-phrases is difficult.  This scheme
   addresses _some_ of the issues involved.  [ The next generation of 'crack'
   won't have a foothold - happier security officers. ]

This message has been sponsored by off-the-cuff, back-of-the-brain, and
poorly-thought-out; comments and suggestions/improvements are welcomed.

--
Steve@AZTech.Net