in reply to Words without a Dictionary

Most of my users cant even type these passwords in, let alone remember them for more than 10 seconds...

A user really should not need to remember a password that YOU or your SYSTEM generated. They just need to be able to type it once, and then define a password for THEMSELVES. Two benefits: (1) you have less liability if you don't know their passwords, and (2) they can design passwords that they can remember.

Security and Convenience are typically opposed. The easier, the weaker. The stronger, the more complicated. The challenge is not in developing secure rules, but in encouraging secure behavior. Make the rules too strict and the users will break them (password on PostIt). Make the rules too lax and the users will drive right through them (password eq userid). Help them understand the implications of security and liability, and how to choose strong yet mnemonic passwords on their own.

Update: Yes, I implied but didn't stipulate that the best practice is to generate a use-once password and force a password change.

--
[ e d @ h a l l e y . c c ]

Replies are listed 'Best First'.
Re: Re: Words without a Dictionary
by sauoq (Abbot) on Jul 22, 2003 at 19:32 UTC
    Two benefits: (1) you have less liability if you don't know their passwords, and (2) they can design passwords that they can remember.

    And one drawback: some people are likely to write it down rather than change it. If you can force them to change it, that's great. But if not, there is some merit to generating pronounceable passwords.

    BTW, your reason (1) doesn't necessarily apply at all. Generating a password for a user doesn't imply keeping a record of it.

    -sauoq
    "My two cents aren't worth a dime.";
    
Re: Words without a Dictionary
by jonadab (Parson) on Jul 23, 2003 at 20:57 UTC
    define a password for THEMSELVES. Two benefits

    One very serious drawback: ten percent of your users' passwords will be brute-forceable given fifty tries.

    If you are an ISP, this may be okay. Warn the users that if anyone guesses their password they're fully responsible, don't give them access to anything but their own stuff, patch against whatever local root exploits are discovered, and that'll probably do.

    If your users have to have access to stuff that you have to protect, then you have problems. If possible, the mechanism users use to change their passwords should check against a list of common passwords and a dictionary and reject any password that's very close to anything on the list or in the dictionary.

    Of course, if you can give them a secure password that they can remember... There was an article on slashdot recently about using inkblots as password clues, but what about using pronounceable sequences or words?

    I did a little arithmetic on this issue, and I have concluded that a sufficient number of dictionary words (at least three IIRC, but it of course depends on the size of your dictionary) strung together with hyphens can be as secure as a much harder-to-remember random password. It takes longer to type the words, but they are easier to remember. There's your tradeoff. Say your dictionary has twenty thousand words and you use $n of them, that's (20000)**$n possibilities. The traditional approach (using sequences of random characters from [A-Za-z0-9]) gets more like (62)**$n and so requires a somewhat higher n. Thus, you don't have to string eight words together to surpass the security of an eight-character random password. Three words may be adequate for some purposes (especially if you use a large dictionary) -- and it will be easier to remember. Even a four-word password (so your dictionary only needs to have 64*64 words in it) may be easier to remember than jEp3WkbG, if you consider a word to be easier to recall than two random characters.


    $;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/