# > 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