Re: Cycling Passwords

Rick Stevens <ricks@xxxxxxxx> · Fri, 22 Aug 2008 11:11:27 -0700

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@xxxxxxxx -
- Hosting Consulting, Inc.                                           -
-                                                                    -
-         We have enough youth, how about a fountain of SMART?       -
----------------------------------------------------------------------

_______________________________________________
Redhat-install-list mailing list
Redhat-install-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/redhat-install-list
To Unsubscribe Go To ABOVE URL or send a message to:
redhat-install-list-request@xxxxxxxxxx
Subject: unsubscribe