NYCPHP Meetup

[David Sklar]

Allen Shaw wrote:

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

David