4

We need to determine a password policy for our organization.

All users, in general, will have 90 days until they will have to change their passwords, complexity required and passwords need to be at least 8 characters long. When you were determining your password policy, have you differentiated between computer-team in one or more of the password policy terms that was applied to all users?

dalimama
  • 1,065
  • 1
  • 11
  • 21
  • 1
    You are missing **password complexity** (letters, numbers, and/or symbols). An 8 character password if quite weak, especially for Windows. Have a look at NIST guidelines for your platform (eg. Windows, smart-phone, server, etc.) – david6 Nov 24 '11 at 08:25
  • 1
    You are missing **password history** (prevent re-use, eg. A to B to C, back to A). – david6 Nov 24 '11 at 08:26
  • I have generally two levels of enforceable IT policy: one for ALL users (Acceptable Use), and a much more strict one for higher privileged staff (IT Security Policy). The privileged staff include: systems administrators, 3rd level helpdesk, DBA's, audit, security staff, etc. – david6 Nov 24 '11 at 08:29
  • 3
    @david6 - can you wrap up these 3 comments into an answer instead? – Rory Alsop Nov 24 '11 at 09:09
  • About missing password history - never mind that and other terms, just focus on the question please. &btw - I did mentioned complexity. – dalimama Nov 24 '11 at 12:37
  • 1
    So is your question: how do you define password change periods for groups with differing security requirements? – Rory Alsop Nov 24 '11 at 13:29
  • @RoryAlsop: yes – dalimama Nov 27 '11 at 07:47

1 Answers1

4

What should be in your policy. Your policy should specify several things:

  • Minimum password length/strength. For instance, requiring that the password be at least 8 characters or longer makes sense.

  • Password selection methods. Advise people on good ways to select a password. People aren't very good at choosing strong passwords, so your password policy should provide guidance about how to do this. The best solution might be to provide them with a tool to automatically generate a random password for them. Alternatively, you could suggest how people can choose a strong password on their own (e.g., pick a short phrase that will be memorable to them and that no one else is likely to use).

  • Password handling. You should tell people to never share their password with anyone else. You should promise them that sysadmins will never ask them for their password. You should prohibit sysadmins and other staff from ever asking anyone for their password. You should specify the penalty for violations.

  • Cleartext passwords. I recommend that your policy prohibit transmission of passwords in cleartext over the network: in other words, it should require that internal services and applications be designed to avoid transmitting passwords in cleartext over the network, and it should prohibit services and applications (e.g., telnet, non-anonymous ftp) that transmit user passwords unencrypted over the network. Your policy might specify a phase-in period and a process for getting approval for exceptions, if necessary.

What should not be in your policy. You should not require users to change their passwords every 90 days. This is a lousy idea. It is horrible for usability. And, it does not improve security: it's one of those things that superficially sounds good to non-experts, but does not actually add any significant benefits that I know of. In particular, it does not really help defend against any realistic threat model I'm familiar with. If you're lucky, it may cause people to choose a predictable sequence of passwords (e.g., xlkjsadf1, xlkjsadf2, xlkjsadf3, etc.). If you're less lucky, it may make security worse, by forcing people to write down their password somewhere (a yellow sticky note attached to their monitor is the traditional method).

Possibilities to consider. Depending upon your circumstances, you might also consider the following:

  • Non-password authentication. Passwords are not the end-all, be-all of user authentication. For high-risk activities (e.g., sysadmins with root/administrator access to critical machines), you might consider requiring other forms of authentication, such as RSA SecurID cards. They are generally more secure than passwords.

  • Password escrow. There are some cases where you might want to require employees to escrow a copy of a password with the company. A typical case is where the employee signs up for some external service (e.g., Amazon EC2) and has to specify a username and password for the account with that service, and where the external service does not provide any way to link more than one username with the service, and where the external service is relied upon or used by multiple folks in the company. In that case, if the employee who created the account leaves the company, you may lose access to the account on the external service. One solution is to ask the employee to escrow the password they created for that account with the company: e.g., put it in an envelope, seal the envelope, sign over the flap, and place it in a locked safe controlled by their boss or some other employee.

Community
  • 1
D.W.
  • 98,860
  • 33
  • 271
  • 588
  • 1
    have added the link to the 90 days question for you. – Rory Alsop Nov 24 '11 at 09:10
  • Note that the 90 day password expiry **is** in the PCI-DSS (or at least it was the last time I had anything to do with it) so if compliance is your goal, learn to live with changing your password every 90 days and peeling post-it notes off everyone's monitors. – Ladadadada Nov 24 '11 at 09:56
  • The only thing it stops is *if* the password has been compromised, the attacker would not have access in 90 days (unless the attacker changes the password first). Of course, by the time 90 days is up, every piece of software on the system could have a back door in it, and several rogue accounts created. It's highly unlikely the attacker needs to know the password more than once for initial entry. – ewanm89 Nov 24 '11 at 12:19
  • 2
    @D.W.: I want to add that a good password policy should include some guidance on _how_ to "pick" a random phrase. Randomness is hard for a human brain. For security, I think a password generation tool is much better: have some program produce 20 passwords with reasonably high entropy, and let the user keep the one he prefers; you can end up with 30 bits of entropy that way, and that's not bad. – Thomas Pornin Nov 24 '11 at 13:49