Password Management, The Best Practices

I found a very nice and thorough article about password management. I love it! 🙂

And it’s increasingly needed nowadays!!!

Password Management Best Practices

This document describes and justifies current password management best practices in an enterprise network. It is intended to offer reasoned guidance to information technology decision makers when they set security policy and design network infrastructure that includes passwords.

The document is organized as follows:

• User authentication and passwords: Describes the objectives of user authentication, alternative technologies for authentication and why passwords continue to be the prevalent technology for identifying users.
• Security threats: A list of the major security threats to password-protected network systems.
• Human factors: How human behaviour affects password management.
• Composition rules: Recommended rules for composing an acceptable password.
• Changing and reusing passwords: Reasons and recommendations for periodic password changes, and for not recycling old passwords.
• Secrecy: The need for keeping passwords secret, and recommended practices.
• Intruder detection: Detecting and responding to security attacks.
• Encryption: Using encryption to protect passwords in storage and in transit.
• Synchronization: Reasons for and risks with keeping passwords on different systems the same.
• User support: Password problems encountered by users, and how to securely resolve them.
• Find out more: Other resources with information about password management.

Many applications depend on reliable user identification, also called authentication. Over the years, many technologies have been developed to support this requirements. Authentication technologies may be categorized as follows:

Authentication Factor	Description	Example
Secrets: Something you know	secret information known only the user	a password or PIN.
Tokens: Something you have	a physical deviced possessed only be the user	a token card or smart card.
Biometrics: Something you are	a unique, measurable characteristic of the user	voice print verification, fingerprint or retinal scan.

Generally, it is more secure to use multiple forms of authentication — e.g., a security token combined with a password.

These types of authentication may be further characterized as follows:

Characteristic	Secrets	Tokens	Biometrics
Reliable identification?	Good	Very good	Excellent
Requires client-side hardware	No	Sometimes	Yes
Requires client-side software	No	Sometimes	Yes
Typical deployment cost/user	0	$50	$100
Works with legacy systems	Yes	No	No

Due to cost and compatibility with legacy systems, the most popular form of user authentication continues to be a secret password.

The remainder of this document discusses how to best manage passwords, to maximize security and minimize cost of ownership.

Passwords are simply secret words, or at best secret phrases. They can be compromised in many ways:

• Users may write them down or share them, so that they are no longer really secret.
• Passwords can be guessed, either by a person or a program designed to quickly try many possibilities.
• Passwords may be transmitted over a network either in plaintext, or encoded in a way which can be readily converted back to plaintext.
• Passwords may be stored on a workstation, server or backup media in plaintext, or encoded in a way which can be readily converted back to plaintext.

Each of these vulnerabilities make it easier for someone to acquire the password value, and consequently pose as the user whose identity the password protects.

Users in a large organization frequently have many passwords, each protecting their access to a different computer system. Users have some basic limitations, which limit what can be done in the context of secure password management. In particular, it is hard for most people to remember:

• Complicated passwords.
• Many different passwords.
• Passwords that change frequently.
• Passwords for systems that are used infrequently.

When people have trouble remembering their passwords, they do one or more of the following things:

• Write down their passwords — and reduce security to the protection afforded by a piece of paper.
• Forget their passwords — and require frequent assistance from a computer help desk organization to reset it.
• Use very simple, easily compromised, passwords.
• Reuse old passwords as often as possible.

Clearly, sound password management practices must take into consideration human limitations, to limit the above problems.

As outlined in (2), one of the primary weaknesses of passwords is that they may be guessed. While a human may give up after trying to guess ten or a hundred possible passwords, software such as Crack and L0phtCrack will happily try millions of combinations.

To combat password guessing attack, users should pick hard-to-guess passwords. One way to do this is to ensure that the set of all possible passwords is too large to search thoroughly, and then to eliminate probably guesses.

The number of possible password combinations is calculated by taking the number of legal characters in a password, and raising that number to the number of characters in the password. The possibilities for some likely combinations are shown below:

Legal	 
characters	5	6	7	8	9	10
0-9	1.00e05	1.00e06	1.00e07	1.00e08	1.00e09	1.00e10
a-z	1.19e07	3.09e08	8.03e09	2.09e11	5.43e12	1.41e14
a-z,0-9	6.05e07	2.18e09	7.84e10	2.82e12	1.02e14	3.66e15
a-z,0-9,3 punct	9.02e07	3.52e09	1.37e11	5.35e12	2.09e14	8.14e15
a-z,A-Z	3.80e08	1.98e10	1.03e12	5.35e13	2.78e15	1.45e17
a-z,A-Z,0-9	9.16e08	5.68e10	3.52e12	2.18e14	1.35e16	8.39e17
a-z,A-Z,0-9,32 punct	7.34e09	6.90e11	6.48e13	6.10e15	5.73e17	5.39e19

Users must be required to choose their passwords from the widest possible set of characters, subject to the constraints of the systems where those passwords reside. For example, most mainframes do not distinguish between uppercase and lowercase, and only allow three punctuation marks (fourth row in the table above).

You must then set a policy based on the smallest permissible set of legal password values — for example: 10 billion. To draw from the above table, mainframe compatible passwords must be at least seven characters long to meet the requirement of at least 10 billion possible passwords.

A reasonable set of password rules, designed to ensure that the search space for all possible values is as reasonably large, and that passwords are not too easy to guess, follows:

• To ensure that the search space is sufficiently large:
  • Passwords must be at least seven characters long.
  • Passwords must contain at least one letter, and at least one digit.
  • If this is compatible with your systems: passwords must contain both uppercase and lowercase letters, and at least one punctuation mark or other “special” character.
• To eliminate easily guessed passwords:
  • Passwords must not be based on the user’s name or login ID.
  • Passwords must not be based on a dictionary word, in any language.
  • Passwords may not contain more than two paired letters (e.g. abbcdde is valid, but abbbcdd is not).

Over time, passwords may be compromised in many ways, including:

• Users may share them with friends or coworkers.
• Users may write them down, and they may then be exposed.
• Passwords may be guessed, either by humans or security diagnostic software.
• The servers that house passwords may be compromised, and their passwords acquired by an intruder.
• The networks that passwords travel between a user’s workstation and servers that the user logs into may be compromised, and passwords may be recorded by an intruder during transmission.
• Users may be tricked into providing their passwords to intruders via a social engineering effort.
• The help desk may be tricked into giving an intruder a valid password.

To limit the usefulness of passwords that have been compromised, a best practice is to change them regularly. Common rules on many systems is to force users to change their passwords when they log in, if they have not been changed for an extended period (e.g., 30 or 60 days).

In general, users should be required to change their passwords regularly, at most every 90 days, and preferably more frequently.

For the same reasons, users should not reuse old passwords, as they may already have been compromised. Many systems support this by recording some representation of old passwords, and ensuring that users cannot change their password back to a previously used value.

When password history is enforced, users may figure out the number of passwords in their history file. As this number is normally 10 or fewer, a user who does not really wish to change his password when prompted to do so may make several consecutive password changes, and finally return his password to its original value.

To defeat such “smart” users, some systems also enforce a password rule that limits the number of password changes that a user may make in any given day. By forcing users to spend several days, users are less inclined to defeat the password history mechanism.

A better approach, though not yet available on many systems, is to simply maintain an unlimited number of entries in each user’s password history. Since disk storage has become very cheap, this approach is now feasible.

Passwords are intended to uniquely identify a user. As such, they must be secrets — known only to the user they identify.

Users frequently behave in ways that lead to password disclosure. In particular, users may:

• Choose passwords which are easily guessed — so are not really secret.
• Share their passwords with coworkers, friends or family.
• Write down their passwords, and place the written password near their computer, or in an ostensibly private place like a wallet.

Corporate password management policy must forbid these practices, and allow for some negative consequence to users who violate these rules.

In addition, alternative mechanisms should be provided, to help users manage passwords without writing them down or sharing. Key among these mechanisms is password synchronization – which helps users to remember rather than write down passwords.

Many systems can detect an attempt by a user to log in with an incorrect password. If too many invalid attempts are made in a short period of time, it is possible that someone is trying to guess the user’s password.

To make password guessing attacks more difficult, many systems include an “intruder lockout” feature. This simply means that if N invalid attempts to login to the same account are made during T_1 minutes, then the account is disabled for T_2 minutes.

While this mechanism is effective against concerted attacks against a single account, they do not prevent an intruder from simultaneously trying to guess the passwords of many users. Also, intruder lockout can be used to carry out a denial of service — by systematically locking out many accounts, including administrator ones.

Because of these fundamental limitations, best practice is to limit enforcement of intruder lockout to:

• Apply only to users, but exempt at least one administrator login.
• Apply a high threshold for intruder detection — e.g., 5 failed attempts in 2 minutes.
• Automatically clear the lockout quickly — e.g., after 10 minutes.

Passwords may be stored on user workstations or servers. They must be transmitted, in some form, from the user’s workstation to a server when the user first logs in, and possibly again later.

Not much can be done to enforce reasonable password encryption or hashing on existing server products. However, if you are responsible for developing a new server or application that manages its own passwords, it is best to store passwords using a well-known and trusted hashing algorithm, such as MD5 or SHA.

Passwords transmitted from a workstation to a server are similarly subject to the protocol developed by that server’s vendor. In general, mainframe, minicomputer and Unix servers tend to use no encryption by default, although strong encryption is available from most vendors as an add-on. If password security is important in your organization, and if you cannot trust the physical security of all communication media between a user and the systems s/he logs into, then you should seriously consider additional mechanisms to protect these login sessions.

Some workstations may “cache” passwords — and automatically provide them to servers when users need access. Such password caches also require strong cryptographic protection, and if this cannot be guaranteed are best avoided.

In some cases, the protocol provided by a vendor may encrypt passwords when they are used to login to a system, but not when a password change is transmitted. This happens with Oracle SQL*Net, for example. In these cases, if password management software is deployed, it is helpful for that software to implement its own encryption, beyond that provided natively by the system vendor.

Password synchronization is any process that helps users to keep the passwords that they use to log into different systems the same.

There is some debate as to whether password synchronization makes systems more secure, or less. The arguments are as follows:

• Synchronization reduces security: If a single system is very insecure, then compromising that system will give an intruder the passwords for every other system in the network. This is prevented by requiring users to use different passwords on different systems.
• Synchronization improves security: Users with many passwords have trouble remembering them, and consequently write them down. System security is reduced to the physical security of a piece of paper — i.e., almost no security at all.

In practice, it is hard or impossible to prevent users with unsynchronized passwords from writing them down. The two scenarios (synchronized vs. different passwords) therefore boils down to:

• Synchronized passwords: as secure as the least secure system on the network.
• Unsynchronized passwords: reduce protection to that provided by slips of paper.

Since most systems make at least some effort to protect their passwords, synchronized passwords are more secure. To mitigate the risk of a single system compromise being leveraged by an intruder into a network-wide attack, there are some password management guidelines to follow:

• Very insecure systems should not participate in a password synchronization system.
• Synchronized passwords should be changed regularly.
• Users should be required to select strong (hard to guess) passwords when synchronization is introduced.

The bottom line is that a single, hard-to-guess, regularly changing password is more secure than multiple passwords, some of which may be easy to guess, some of which may not be changed regularly, and all of which may be written down.

Sometimes users forget the passwords they must type to log into network systems, or else type the wrong password too often, and trigger intruder lockout on their account. When this happens, users must call their help desk, and request assistance. The help desk process normally proceeds as follows:

1. User experiences problems trying to log in.
2. User calls the help desk, and may wait in a service queue.
3. Support analyst asks the user for his name and a problem description.
4. Support analyst asks the user for information to prove his identity.
5. Support analyst compares this information with some on-line resource.
6. If the user is authenticated, the support analyst may reset the password directly, or forward the problem to a special support person, who has the tools and privileges to reset the caller’s password.
7. The user tries to log in with the newly assigned password.
8. The user may be required to change the new password immediately.

Security problems

This process presents several security problems:

• The support analyst may forget to authenticate the user at all.
• Authentication information may not be available for the user.
• Authentication information available to the help desk may be easily guessed, so that an intruder could compromise the process by claiming to be a user, and answering that user’s supposedly secret questions.
• Many support analysts have the right to reset passwords.
• Password resets may not be attributable to a support analyst, and consequently there is no accountability for who performed a password reset, when and how.
• The support analyst knows the user’s new password at the end of the process, so it is no longer truly secret.

Mitigating controls

These problems can be overcome through:

• Analyst training.
• Ensuring that reliable authentication information is available for every user.
• Providing an application proxy for analyst passwords resets — so that support analysts log into the application, and it resets passwords on their behalf. This can require user authentication, and provides for accountability and a reduced number of support staff with administrative system privileges.
• Allowing users to reset their own forgotten passwords, after reasonable authentication.

User authentication

It is important to ensure that users who request a password reset, either by calling the help desk or using a self-service facility, are reliably authenticated. In practice, this means that:

• Using security tokens or biometrics as a form of user authentication is more secure than asking personal questions.
• Each user should be required to answer a unique set of questions for authentication.
• Users should be prompted to answer truly personal questions.
• If possible, users should be asked to answer different, randomly-selected questions every time they must authenticate.
• Users should be able to update their own personal question and answer profiles. They can be authenticated to do so using one of their passwords.
• Repeated failed attempts to authenticate as a user should trigger a security incident, and lock out the user’s account.
• User Q&A profiles should include standards for minimum number of questions: e.g., 3, and minimum answer length and complexity — e.g., 10 characters per answer.

Some popular questions include:

• Bank account or parts of a credit card number.
• All or part of a social security number.
• Expired car license numbers or old home address.
• Driver’s license number.
• Old telephone numbers.
• Mother’s maiden name.
• Nicknames of family, friends or pets.

Ideally, users should be able to define their own questions, in addition to answering standard ones.

This document was prepared by M-Tech, and reflects expertise with password management accumulated through many deployments of the P-Synch® Password Management System:
http://P-Synch.com/
http://MTechIT.com/

To find out more about automatic programs for guessing passwords, see Crack for Unix and L0phtCrack for Windows NT/2000/2003:
ftp://coast.cs.purdue.edu/pub/tools/unix/pwdutils/crack/
http://www.atstake.com/research/lc/index.html

The US federal government has password management standard — FIPS 112 at:
http://www.itl.nist.gov/fipspubs/fip112.htm

For a solution to logging into Unix systems without exposing passwords (or other data) on the network, refer to OpenSSH:
http://www.openssh.org

A more secure passwd program for Unix systems is npasswd – at:
http://www.utexas.edu/cc/unix/software/npasswd/

For general security news and information, visit:
http://www.securityfocus.com/.

Seriously!!!