White Papers Password Management Best Practices Password Management Best Practices
Hitachi ID Facebook Page Hitachi ID Twitter Page Find us on Google+ Hitachi ID YouTube Page

Password Management Best Practices

This document describes and justifies password management best practices as applied in medium to large organizations. It offers reasoned guidance to IT decision makers when they set security policy and design network infrastructure that includes passwords.

The guidance in this document is focused on how to best manage user passwords. It is not intended to address the special challenges and techniques that arise when managing privileged passwords, that belong to administrators, service accounts, etc.

Look for the figure marks throughout this document to find best practices.

User authentication and passwords

(1)

Definitions

Authentication technologies

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 device possessed only be the user.

A one time password (OTP) token or smart card.
Biometrics: Something you are.

A unique, measurable characteristic of the user.

Voice print verification, fingerprint, vein pattern, retina or iris scan.

 

Generally, it is more secure but less convenient to use multiple forms of authentication -- e.g., a one time password token combined with a password or PIN.

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.

Moreover, as non-password authentication technologies are deployed, they are usually combined with passwords to improve their security. For example, tokens are secure -- unless they are stolen, in which case the person who stole the token can impersonate the legitimate user. This is easily remedied by requiring the user to sign into systems with the OTP displayed on a token plus a password or PIN, which a thief would not know.

The remainder of this document discusses how to best manage passwords, to maximize security and minimize cost of ownership. The guidelines here apply primarily to passwords used as a single authentication factor, but can also be applied to passwords used as a second authentication factor, in conjunction with biometrics, tokens or smart cards.

Security threats

(2)

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

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.

Conversely, if passwords are managed securely by users and if password systems are constructed so as to prevent brute-force attacks and inspection or decryption of passwords in transit and in storage, then passwords can actually be quite secure. This document will describe some of the mechanisms for securing passwords.

Human factors

(3)

Users in a large organization frequently have many passwords, each protecting their account on a different system or application. Users are people, not machines, so their ability to securely manage passwords is intrinsically limited. In particular, it is hard for most people to remember:

Without these constraints, password security would not be a problem and there would be no market for other authentication technologies. For example, if every password was changed every day, was remembered perfectly without being written down and consisted of 100 randomly chosen letters and digits, there would really be no need for authentication technologies other than passwords.

Effective password management is therefore taken to mean password management that is secure, user friendly and supportable within the confines of both technology and human behavior.

When people have trouble remembering their passwords, they usually resort to one or more of the following:

Clearly, sound password management practices must take into consideration human limitations, to reduce the frequency of these insecure practices. Hitachi ID Systems Best Practices

Composing hard-to-guess passwords

(4)

As outlined in (2), one of the weaknesses of passwords is that they can be guessed. While a human may give up after ten or a hundred guesses, software s available to automate the guessing process and try millions of possible passwords per second:

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 probable guesses, which an attacker might try first.

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 typical combinations are shown below:

Character set

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 should 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).

The policy should be based on the smallest acceptable set of possible password values. This, in turn, depends on how fast an attacker can check if a possible password is valid; how much time an attacker has to attack a given password and how log we want the attacker's probability of success to be.

This is best illustrated with an example:

  1. Assumptions:
    1. Encrypted passwords are not available to an attacker and consequently passwords can only be guessed at a rate of 100/second (this number is high / conservative for an over-the-network attack).

    2. An attacker can make an unlimited number of guesses without being detected (this is easy to fix).

    3. Passwords are changed, at most, every 90 days.

  2. Objective: the attacker's probability of success should be no more than 1%.

  3. Technical constraints: passwords may only contain lowercase letters, uppercase letters and digits.

  4. Calculation:
    1. An attacker can make 90 x 24 x 60 x 60 x 100 = 777,600,000 guesses before a password will expire.

    2. There should be 77,760,000,000 possible passwords -- about 8e10.

    3. From the above table, a 7 character password is sufficient, so long as users don't pick easily guessed values (e.g., their name or a dictionary word).

In practice, assuming that encrypted passwords are not available to an attacker and that passwords cannot be captured or decrypted in transit, the following policy is a often reasonable: Hitachi ID Systems Best Practices

Some of these rules merit further discussion, since a naive implementation of the rule can actually reduce password security. Consider the rule "password should not contain a dictionary word." The letters "a" and "I" are legitimate English words, and if the rule is enforced using a dictionary that contains these, then in effect we have reduced the set of available letters from 26 to 24. To avoid this sort of problem, rules of the form "shall not contain" should be fine-tuned:

Unicode and other non-Latin passwords

(5)

Most password composition rules focus on how passwords composed of Latin characters (i.e., "English language" letters), digits and punctuation marks are composed.

Unfortunately, English is the native language of no more than 400 million people and is spoken by no more than 1.5 billion people -- out of a global population of over 6.5 billion people. In other words, even if other European languages that use a similar character set are included, a focus on Latin characters ignores at least 2/3 of the world's population.

This not just an academic problem. Many organizations are global in nature and include users who speak a variety of languages. A system or application whose users reside around the world needs to enforce a password policy that makes sense for all of them, not just for those who happen to prefer English.

Password management for multi-lingual users is a broad subject, but following are some important considerations:

  1. Most users, in most countries, have keyboards that include most Latin characters. This means that they are able to type passwords composed of "English" letters, even if they don't read or write the language.

  2. Not every system or application supports non-Latin characters in the password field. When composing an enterprise password policy, it's important to consider the limitations on the password fields of in-scope systems and applications. Failing to do this can yield a policy that is relevant to only some systems.

  3. In countries where Chinese, Japanese or Korean (CJK) is spoken, text input often involves a display component. For example, a Chinese user might type the pinyin representation of a character and the input software will display a list of matching characters. The user will then choose the desired character and start on the next character.

    This pattern is normal for input of text in the CJK languages but is problematic for passwords since password input should not be visible to other people in the physical vicinity.

    Most CJK users avoid this problem by choosing passwords that consist only of Latin characters -- something that may surprise native English speakers.

Some best practices follow from this discussion:

  1. Encourage or require users to restrict their passwords to Latin characters, both for compatibility and to avoid input methods which display the characters users type. Hitachi ID Systems Best Practices
  2. Do use a dictionary lookup to ensure that new passwords are hard to guess, and do include dictionaries of non-English words represented in Latin character sets (e.g., Pinyin, etc.). Hitachi ID Systems Best Practices

Changing and reusing passwords

(6)

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

To limit the usefulness of passwords that have been compromised, a best practice is to change them regularly. A common rule in many organizations is to force users to change their passwords when they log in, every 60 or 90 days.

In general, users should be required to change their passwords regularly. The password expiry interval should not be longer than 90 days. Hitachi ID Systems Best Practices

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. Hitachi ID Systems Best Practices

When password history is enforced, users may figure out the number of passwords stored for this purpose. As this number is usually 10 or fewer, a user who would prefer to keep his password the same may make a series of consecutive password changes where the final password value is the same as the first one.

To defeat such "smart" users, some systems also enforce a password rule that limits the number of password changes that a user can make in any given day. By making the process of defeating password history take several days, users are discouraged from trying to reuse old passwords.

A better approach, though not available on all systems, is to simply maintain an unlimited number of entries in each user's password history. Since disk storage is inexpensive, this approach is practical on modern systems. With this approach, users can change their passwords as often as they like -- and still never be able to reuse old ones. Hitachi ID Systems Best Practices

Keeping passwords secret

(7)

Passwords are intended to reliably differentiate between the authentic user and impostors. 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:

A comprehensive password policy should explicitly forbid these behaviors and specify negative consequences to users who violate the policy. Hitachi ID Systems Best Practices

To help users comply with an effective password policy, user friendly password management tools and processes should be provided. Key among such aids to users are password synchronization and single sign-on. Hitachi ID Systems Best Practices

With either synchronized or automatically filled-in passwords, users have fewer passwords to remember so they are less likely to write down their passwords. Hitachi ID Systems Best Practices

Intruder detection and lockout

(8)

Many systems can detect repeated attempts to sign into an account with incorrect passwords. A pattern of failed logins may be due to:

  1. Typing problems. For example, the user may have the Caps Lock or Num Lock key enabled and not realize it.
  2. A forgotten password.
  3. The wrong password being used. For example, the user may be trying to sign into system A using the password for system B.
  4. An intruder trying to sign into an account by guessing the legitimate user's password.

To deter the last of these, it's reasonable for a system that detects too many invalid attempts during a short period of time to lock out the user's account and prevent further attempts, at least for a while. This is called an intruder lockout.

Many systems include an "intruder lockout" feature. If N invalid attempts to login to the same account are made during an interval of Tdetect minutes, then the account is disabled for Tlockout minutes.

While this mechanism is effective against concerted attacks against a single account, it does nothing to prevent an intruder from simultaneously trying to guess the passwords of many users. A more sophisticated mechanism might extend this as follows: If M invalid login attempts are made from network address A, to any account, during an interval of Tdetect minutes, then the address A is disabled for Tlockout minutes.

This will deter intruders with access to just a single network device/address from which to carry out their attack.

Intruder lockout also has a down side -- it can be used to carry out a denial of service -- by systematically locking out many accounts, including administrator IDs.

Because of these fundamental limitations, the best practice is to combine several intruder lockout-related policies: Hitachi ID Systems Best Practices

Encrypting passwords in storage and transit

(9)

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 signs into systems and applications.

Most organizations are powerless to improve the manner in which existing infrastructure uses encryption to protect passwords. However, staff responsible for developing a new applications that include password authentication can and should take effective precautions, such as storing passwords using a well-known and trusted hashing algorithm such as SHA-256 or (somewhat less effective, but still infeasible to find a collision in 2010) SHA-1. Hitachi ID Systems Best Practices

Passwords transmitted from a client device to a server are similarly subject to weaknesses in the protocol used by the relevant application. For example, Telnet and TN3270 are plaintext while SSH and SSL are strongly encrypted. Where password security is important and where one cannot trust the physical security of all communication media between a user and the systems he logs into, then additional mechanisms, such as IPSec should be considered to protect that communication. Hitachi ID Systems Best Practices

Some client devices and applications cache passwords and automatically provide them to servers on behalf of users, as required. Cached passwords should also be cryptographically protected, but in this case encryption rather than hashing is required, since the password must be recoverable. Hitachi ID Systems Best Practices

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 for password transmission, beyond that provided natively by the application vendor. Hitachi ID Systems Best Practices

Synchronizing passwords

(10)

Password synchronization technology helps users to maintain the same password on two or more systems. This, in turn, makes it easier for users to remember their passwords, reducing the need to write down passwords or to call an IT help desk to request a new password, to replace a forgotten one.

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

In practice, it is very difficult to get users who have many passwords to stop writing them down. The two arguments above therefore can be restated as:

Since most systems and applications make at least some effort to protect their passwords, synchronized passwords are normally 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: Hitachi ID Systems Best Practices

The bottom line is that a single, hard-to-guess, regularly changing password is normally 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.

Single sign-on

(11)

Single sign-on (SSO) is any technology that replaces multiple, independent system or application login prompts with a consolidated authentication process, so that users don't have to repeatedly sign in.

Taxonomy of SSO Systems

There are several types of single sign-on systems:

  1. Enterprise SSO -- application login prompts continue to ask users to type their login IDs and passwords, but software on the user's PC automatically automatically identifies and fills in these dialogs.

  2. Agent-based web SSO -- agents on each web application check whether the incoming web browser (and by extension, its user) has already been authenticated. If so, no further authentication is required.

  3. Proxy-based web SSO -- web browsers access web applications through a proxy, which looks up user credentials and injects them into the data stream sent to each web application.

  4. Kerberos -- authentication is performed using a separate infrastructure, outside of other systems and applications. Users sign into the Kerberos infrastructure and their computer receives a token, which can be offered to Kerberos-enabled applications instead of filling in a login prompt.

  5. Federation -- similar to Kerberos, but designed to allow single sign-on between different organizations (administrative domains). Users sign into a system in one domain and when they try to access an application in another domain, a security assertion is forwarded from their source domain indicating who they are.

Security of SSO Systems

When organizations consider various approaches to single (or reduced) sign-on, they generally need to know:

IT support for forgotten and locked out passwords

(12)

Sometimes users forget their passwords or type the wrong one often enough to trigger an intruder lockout. When this happens, users generally call their IT help desk and ask for the lockout to be cleared or the password to be reset.

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 (i.e., authentication of a human by a human).
  5. Support analyst compares this information with some on-line resource.
  6. If the user is authenticated, the support analyst will generally do one of three things:
    1. Reset the forgotten password.
    2. Clear the intruder lockout.
    3. Forward the support incident to another IT support person, who has the requisite privileges to perform one of the above functions.
  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 challenges

The process described above may be vulnerable to security weaknesses:

Mitigating controls

These problems can be overcome through: Hitachi ID Systems Best Practices

User authentication

It is important to ensure that users who request a password reset, either by calling the IT support help desk or using self-service, are reliably authenticated. Following are some practical considerations when designing a non-password authentication system:

Sample security questions are provided in [link].

(13)

Questions with textual answers

Sample security questions, which may have alpha-numeric questions and so are suitable for a text user interface, include:

Questions with numeric answers

Sample security questions, that have numeric answers and so are suitable for authentication using a touch-tone phone, include:


Appendix: References

(14)

This document was prepared by Hitachi ID Systems and reflects expertise with password management accumulated through many deployments of Hitachi ID Password Manager.