Re: Cycling Passwords
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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: Ol10yzZx119xaOnce 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, butno 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