Questions in Large Installation System Administration

Denis McKeon dmckeon at hydra.unm.edu
Fri Feb 8 06:08:16 AEST 1991


Those were a lot of good hard questions about large systems admin.
Here's a small tidbit in reply:

>	*B) How can you convince users to co-operate with security
>precautions? You can force them to choose good passwords; if you try
>hard enough, you can even pretty much not drive them mad in the
>process. But you can't forcibly prevent people from writing down their
>passwords, or giving them out to other people. How do you make
>security safeguards that are livable and comprehensible, and get
>people not to turn around and destroy them for their own purposes?

My preferred approach to creating easy-to-remember passwords
which are not words in any language is to use the initial letters
of easily remembered phrases, for instance:

    password	memorable phrase
    string

    NIlmdts	Now I lay me down to sleep

    Ttsciab	These two strings come into a bar

    Witcohe	When in the course of human events

    Csmnlra	Congress shall make no law respecting an
    eoroptf	establishment of religion, or prohibiting the free
    etoatfo	excercise thereof; or abridging the freedom of 
    sootpot	speech, or of the press; or the
    rotppta	right of the people peaceably to assemble, 
    atptGfa	and to petition the Government for a
    rog		redress of grievances.

Note that phrases in foreign languages, poetry, even .sig quotes can be used.

Benefits:

Users will have less need to write down more memorable passwords.

Password string is easy to recall once you recall the mnemonic phrase,
thus does not need to be written down (up to some fairly small limit of 
different strings/phrases.)

Someone watching you type the password has a harder time visually
collecting the letters and remembering them (harder than a word,
or someone's name, anyway - which a good system shouldn't allow).

In an environment that forces periodic new passwords, the user can jump
ahead a few words in the source text - better than switching back &
forth between two passwords. (but no good if the cracker knows the
previous mnemonic phrase and can attribute it.) (but if the cracker
knows only the password string it can map to many phrases.)

Drawbacks

While this approach makes passwords more memorable, it doesn't
produce most-difficult-to-crack-by-brute-force passwords. 
It also doesn't address people sharing access to their accounts.

Some people have a tendency to softly vocalize the mnemonic phrase.

Characters in the password string are usually in range a-z,
almost all in a-zA-Z, often with initial upper-case letter,
thus susceptible to brute force of all combinations of alphas.

(but You can adopt the German Model of capitalizing all Nouns.)

Cracker could use CD-ROM encyclopedia to generate strings for 
brute force (seems like more work than all alpha combos).

Of course you can enrich the password character mix by doing things like:

    1Bs-Iw!	One Bell system - It works!

but that limits your choice of phrases to those with numeric words - 
perhaps a combination with the license plate model would be better:

    O!U812.	Oh! You ate one too. 
		(or replace with (usually suggestive) phrase of your choice)
		(followup suggestions to rec.humor with Subject: YALPPWS  - :-)

    YALPPWS	Yet Another License Plate PassWord String :-)

Now before you-all in netland get out the flame-throwers, yes, I do
realize that randomly generated printing ASCII strings are more secure
from brute force attacks than alpha strings - but I think that most
people will agree that random strings are harder to remember (unless
committed to paper.)

This mnemonic phrase approach isn't a panacea - just a spoonful of
sugar to help create (optionally enforced) non-word, non-name password
strings which are more memorable than random ones.

Well, certainly 'nuff said - Followups re memorable passwords to
comp.unix.large - perhaps an odd choice, but the only security group at
this site is alt.security, and I can't be sure that an alt. group is
distributed as the original posting was.

--
Denis
dmckeon at hydra.unm.edu



More information about the Comp.org.usenix mailing list