Cycling Passwords

[Rick Stevens]

Karl Pearson wrote:
> I'm curious on your take on systems that require changing passwords on a 
> set schedule, whether it's 90 days or whatever.
> 
> When I've setup new systems, I instruct the users to select passwords 
> that are cryptic and follow guidelines that make them essentially 
> impossible to crack, such as: Ol10yzZx119xa
> 
> Once a good password is found, why change it? I know there are a lot of 
> consultants who say you must, but everywhere I've been that requires 
> people to change passwords, I see they have written them on sticky notes 
> and then put them on their monitor, or bookshelf or whereever. I also 
> see the frustration level raise everytime they are trying to get into a 
> system with a customer on the phone, and they have to tell them to wait 
> for their session as they change their password...
> 
> Since roughly 90% of corporate break-ins are from the inside, having to 
> change the passwords, and then sticking the passwords up, defeats the 
> security purposes for changing passwords.
> 
> What do you think?
> 
> Okay, I do have a reason for asking this: 1. convince me I'm wrong, and 
> 2. I have a client that wants it to stop, and I need to know where in 
> Fedora Core 6 that is setup so case I can make the change for them.
> 
> Their FC6 system is setup so the accounts go to /sbin/nologin so they 
> don't have to change their password for email. But no one has shell 
> access, and a few need it, thus creating the need for passwords to change.

Any access control system should be tailored to the specific needs of
your business.  It is entirely possible to make a server or network so
secure it's unmanageable.  The art of it is balancing security against
ease of use and flexibility.

We set up PCI-compliant systems (you know, credit card processing), so
our attitude towards passwords is "make them complex and change them
often".  We're driven by the statement: "Just because we're paranoid
doesn't mean they AREN'T out to get us!"

Since in your case user accounts don't have a shell associated with
them, an enforced password rotation schedule would have minimal positive
effects.  Your root, administrative and any other account with shell
access should be put on an enforced rotation.  This is only sensible.

Our (somewhat paranoid) systems use this:

We require our root passwords to be rotated at least every 90 days, but
no one's allowed to have them.  Root and admin passwords use the 
following criteria:

1. We use cracklib
2. Minimum of 12 characters
3. Minimum of two upper case characters
4. Minimum of one special character (punctuation mark)
5. Minimum of two decimal digits
6. A given password cannot be reused until at least three others have
been used.
7. No minimum lifetime
8. Maximum lifetime of 90 days

Our security admin creates passwords on the systems themselves in the
standard /etc/passwd and /etc/shadow files, then creates a KeePass file
containing them which is put on two FLASH pendrives kept in two
different firesafes in two different offsite locations.  They're
available if we need them, but all administrative work is done by
designated personnel using sudo.

All of our authentication data (with the exception of root and other
admin stuff above) is maintained in LDAP on two, fully redundant LDAP
servers.  We do lessen the restrictions for normal user accounts:

1. Minimum lifetime is 1 week
2. Maximum lifetime is 365 days
3. Minimum of 8 characters
4. Must have one uppercase character
5. Must have one decimal digit
6. A given password cannot be reused until three others have been used.

The LDAP server enforces these requirements via the "ppolicy" overlay
and a custom password checking library specifically written for this
purpose (they're easy to write).  We also make use of the "host"
attribute capability of LDAP (if a user tries to authenticate from a
machine and that machine is not in a "host" attribute in the user's LDAP
entry, they're denied access).

The LDAP database also includes the equivalent of the /etc/sudoers file
and all machines use the LDAP sudoers data.  You can set an attribute in
LDAP that will prevent the machines from even looking at a local
/etc/sudoers file, which makes circumventing the sudo system more
difficult.

We have a few admins that do real heavy lifting where having to enter
"sudo this" and "sudo that" can be onerous. we allow them to create a
root shell via "sudo bash -l".  Needless to say, these are highly
trusted people.

As I said, these are probably more extreme than most systems need, but
we have financial data coursing through our systems.  With some mods,
they may work for you.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer                       rps2 at nerd.com -
- Hosting Consulting, Inc.                                           -
-                                                                    -
-         We have enough youth, how about a fountain of SMART?       -
----------------------------------------------------------------------