Security is not an end state, part MDCXVI

You know it seems like all this must have surely been discussed hundreds of
times by other people, maybe even by us, before. Wouldn't this all be
somewhat generally understood by now, and maybe even written down in some
reliable source? I've found lots of "advice" on good password policy, but
nothing that claimed or seemed to be vaguely authoritative. Are there just
too many variables to generalize about, or maybe people aren't interested in
really understanding the issue?

> You know it seems like all this must have surely been discussed
> hundreds of times by other people, maybe even by us,
> before. Wouldn't this all be somewhat generally understood
> by now, and maybe even written down in some reliable source?
> I've found lots of "advice" on good password policy, but
> nothing that claimed or seemed to be vaguely authoritative.

One of my favorite resources for this sort of thing is the book
Practical Unix Security by Simson Garfinkel and Gene Spafford [*]

> Are there just too many variables to generalize about,
> or maybe people aren't interested in really understanding the
> issue?

I think both are true (most of the time).

It's a waste of your time to spend many hours coming up with lots of
rules that filter out bad passwords (can't begin or end with a number,
must have at least 3 uppercase and 3 lowercase chars, etc.) if what
results is that acceptable passwords are so complicated so that people
can't remember them and end up writing them down on the dreaded "sticky
note attached to the monitor." Same with overly stringent policies on
how frequently passwords must be changed, how many passwords the change
cycle must go through before you can re-use a password, etc.

Security is a process, not an end state. You must constantly make
decisions that balance robustness with convenience and risk of attack
with severity of attack.

So, sure, there are some guidelines that just about always make sense
("your password can't be your username or a dictionary word") but much
beyond that is all situational.

Stopping brute force attacks on a web application's login page (say,
more than 50 requests per second for the login page from the same IP or
same cookie or whatever) is a much easier, legitimate-user friendly, and
effective mechanism than making users who wish you no harm cycle through
the account signup page six times because they can't think of a
sufficiently obfuscated password.

Some applications don't need passwords at all. Witness the zillion wikis
around the web that mostly let anyone do anything and (perhaps) have a
squad of janitors who clean up the mess if someone does something bad.
(Another nice thing about this model is that it promotes the use of
version control.)

This essay has some interesting points about designing software for
specific, small, linked-offline communities:
--> http://www.shirky.com/writings/situated_software.html

Many of the points in there apply to how you make security decisions, too.