On Tue, Jul 04, 2006 at 10:07:53PM -0400, STeve Andre' wrote:
> On Tuesday 04 July 2006 08:45, Joachim Schipper wrote:
> > On Mon, Jul 03, 2006 at 09:22:59PM -0700, Jeff Simmons wrote:
> > > Well, just to play the devil's advocate here ...
> > >
> > > One of the main functions of any password hygiene program 'should' be to
> > > prevent users from changing 'mypassword1' to 'mypassword2' and then
> > > 'mypassword3', etc. (Yes, we can force complex passwords, but the idea
> > > is the same.)
> > > "In conclusion the main thing we did wrong ... was to worry about
> > > criminals being clever; we should rather have worried about our
> > > customers ... being stupid." Ross Anderson, "Security
> > > Engineering"
> >
> > This suggests a rather fascist, and thus very effective approach: deny
> > the users the right to create their own passwords, but institute some
> > scheme that produces strong, but hopefully memorizable passwords.
> [snip]
>
> Oh Gods. If you do that with normal people, they will put those
> passwords on PostIts and leave them in "safe" places like monitors.
>
> MOST people have real real REAL problems remembering all but some
> very few passwords. People hate passwords, and even in "secure"
> institutions (like military environs) they circumvent them. Forcing a
> password on people results in a secure password, but in unsecure
> storage methods.
>
> We computer folks are weird in that we remember many of them.
We computer folks are weird in that we can be made to understand that
spending five minutes memorizing a password actually makes sense.
Also, I do not necessarily advocate dd if=/dev/urandom bs=16 count=1 |
b64encode - though that is a good method and produces proper passwords -
but have you looked at something like the S/KEY scheme for producing
text passwords? A slightly modified version could both create sentences
that make some sense (for fairly low values of some), and if you add a
little fuzzing somewhere the passwords are fairly strong.
Consider five lower-case words chosen from 1024 possibilities each, for
instance - this has 50 bits of entropy, roughly equivalent to a
10-character password based on natural language [1]; a little fuzzing
and use of capitals will make the passwords chosen much more powerful,
but a 10-character password based on natural language really isn't that
shabby for a lower bound on password complexity.
(Plus, with a secret algorithm/wordlist the above is significantly
harder to crack; while assuming secrecy of your algorithm is a no-no in
crypto, it's still a nice side benefit, and not completely unjustified
if the wordlists are rotated regularly...)
Of course, the above will create more complex passwords than people
would choose themselves and make it impossible to use mydog1, mydog2,
and so on; and yes, some people will be annoyed. However, since the goal
was to improve password security (or, rather, getting the auditors to
sign off for good password security), *some* increase in the complexity
of passwords is inevitable - and communicating this well might lead to
more understanding.
The main disadvantage would be that it creates noticeably longer
passwords; this is the price paid for an easily-remembered but still
strong password. This can be offset by sprinkling more randomness (for
instance, arbitrarily capitalize each letter with 50% chance - this adds
1 bit of entropy per character), but that makes the password less
rememberable.
(Note also that long, but memorizable, passwords will induce bitching
but are less likely to make people use Post-its.)
Joachim
[1] Giving a generous 5 bits of entropy for each character; simple
natural language has 2 - 4 bits by most counts, but passwords tend to be
a little more random.
