silly password restrictions was:Re: [clug] secure remote access method

[Steve McInerney]

On Fri, 2009-06-19 at 22:34 +1000, Daniel Pittman wrote:
> Heck, recently a group of very, very technical people I was around had a
> discussion about a password system that required a password change every week,
> no reuse for 128 passwords[1], minimum length above 20 characters, characters
> from all the standard classes[2], no dictionary words, and no more than three
> characters in sequence from any one class.
> 
> Which was *still* vulnerable to a fairly trivial "rotate the number" guessable
> sequence of passwords, and which still left plenty of other risks.

I'd have to hunt a bit to re-dig it up. But some researchers in the UK
did a study on password lengths/time to change them and so on. Was a few
years ago now. ~ 2000-2005 time frame.

If I recall correctly, the study found that going with more frequent
password changes has two major impacts:
1. It's a *lot* more expensive. In terms of folks getting locked out -
hence no works done; helpdesk time resolving etc; and 
2. It's less secure. Folks write them down and use the post-it-note
method of (not) securing passwords. Or they rotate as Daniel noted. etc


One of the things I was *most* pleased about achieving from my time in
defence security branch in the 90's, was starting to inject increased
levels of sanity on password lengths and time between changes in
secman3.

Key word was "increased"; not overwhelming happiness. :-)

My key argument plank to increase times between changes was that we
layer defences: A decent password is one layer; *quality* system
auditing of password attempts/fails etc backs that up.

Much of the "logic" behind frequent password changes dates from the 80's
where /etc/password (and equivalents on other OS's) were world readable
and held the actual password - pre shadow. So what we've been doing
since then is cargo culting a process that is largely invalid.


Cheers!
- Steve