sklar.com

...composed of an indefinite, perhaps infinite number of hexagonal galleries...

© 1994-2017. David Sklar. All rights reserved.

Security is not an end state, part MDCXVI

As part of a recent thread on nyphp-talk about password strength enforcement, Allen Shaw wrote:<blockquote>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?

</blockquote>To which I replied:<blockquote><blockquote>> 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.</blockquote>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.

</blockquote>



[*] Although I have an older edition, so I left out one of the new authors: Alan Schwartz.

Tagged with security