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, used to sign into administrator, service and embedded accounts.
Look for the marks throughout this document to find best practices.
The remainder of this document is organized as follows:
An overview of how password security can be compromised.
A reminder that human behaviour has to be considered when designing the security of any system, including one for managing passwords.
How to estimate password strength and guidance for composing hard-to-compromise passwords.
Password composition for users whose first language is not English, and who may normally use multi-byte text input.
Guidance regarding when to change passwords and whether to allow users to choose the same password twice.
A reminder that passwords are supposed to be secret, and how to help users keep them that way.
The role that intruder lockouts have in ensuring password security, and guidelines for a balance between keeping out attackers and not bothering legitimate users.
The need to encrypt passwords, in motion and at rest.
The pros and cons of using the same password value on multiple systems and applications.
The pros and cons of replacing multiple login prompts with a single, shared login process.
How to assist users who forgot or locked out their password.
Enabling access to the password management system from user phones, dealing with passwords cached by various apps on user devices and leveraging phones to resolve login problems and to increase the strength of authentication processes.
The end of passwords has been predicted for decades. Biometrics, smart cards, one time password tokens and more have been offered up as alternatives and many of these are gaining market share.
In reality, passwords are likely to remain popular for a long time:
Only when most applications can externalize their login process will organizations be able to seriously contemplate the end of passwords.
The unique identifier that a user types to sign into a system or application is that user's login ID on that system.
Authentication is a process by which a user proves his identity to a system -- normally when logging in.
An authentication factor is something a user presents to a system in order to prove his identity. It may be something he (and hopefully only he) knows, or proof of possession of a physical object, or a measurement of some physical characteristic (biometric) of the living human user. In other words, something the user knows, or something he has, or something he is.
Multi-factor authentication means authentication using multiple factors . For example, a user might sign into a system with a combination of two things he knows, or a combination of something he knows and something he has, or perhaps something he knows, something he has and something he is.
The premise is that adding authentication factors makes it more difficult for a would-be attacker to simulate a legitimate authentication and consequently impersonate a legitimate user.
Strong authentication refers to an authentication process which is difficult to simulate. It may be based on use of multiple authentication factors or use of a single but hard-to-spoof authentication factor .
There are three types of credentials:
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, smart card or app on a smart phone.|
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 combine multiple credentials, preferably of different types, to sign into a system or application. For example, use a password plus a token, or a biometric plus a PIN. This is called multi-factor authentication.
The strengths and weaknesses of different types of credentials can be generally described as follows:
|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 type of credential remains the password.
Moreover, as non-password credentials are deployed, they are commonly combined with passwords or PINs. 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 remedied by requiring the user to sign into systems by entering the pseudo-random code displayed on their token and also enter 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.
Passwords are simply secret words or phrases. They can be compromised in many ways:
Each of these vulnerabilities create an opportunity for an attacker to acquire password values and consequently impersonate users.
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.
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 minimize bad behavior.
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 is available to automate the guessing process and try millions of possible passwords per second.
Such brute-force attacks are not made against login screens, but rather against copies of the password database, where passwords are normally stored in a hashed (encrypted, but not reversibly) format. The first line of defense is therefore to prevent attackers from getting a copy of a password database.
Attackers who can gain access to a password database can choose from many powerful tools to attempt brute-force attacks, including:
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:
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:
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:
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:
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 7 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 raises some important considerations:
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:
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.
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 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.
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.
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.
With either synchronized or automatically filled-in passwords, users have fewer passwords to remember so they are less likely to write down their passwords.
Many systems can detect repeated attempts to sign into an account with incorrect passwords. A pattern of failed logins may be due to:
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 attacker 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 attackers 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 the intruder lockout mechanism cannot differentiate between a password guessing attack, a denial of service attack and a user input problem, the best practice is to combine several intruder lockout-related policies:
Passwords may be stored on user devices and are stored on servers. They must be transmitted, in some form, from the device where it was entered by the user to a server at login time.
Organizations rarely have any influence over how systems and applications store passwords -- these are fundamental characteristics of the relevant software and are difficult or impossible to change. Fortunately, most modern applications incorporate strong encryption and reasonably safe protocols. The exception is custom applications, where developers working for the organization should follow best practices, such as storing passwords using a well-known and trusted hashing algorithm such as SHA-256.
Passwords transmitted from a client device to a server are similarly protected only as well as the application in question subject is able. For example, Telnet and TN3270 are plaintext while SSH and SSL are encrypted. It is generally not safe to trust the physical security of the communication path between a user's device and the systems the user signs into, so protocol level encryption, at least of credentials but preferably of entire sessions, is recommended. Where an application does not support network-level encryption natively, using IPSec to protect all communication is recommended.
Some client devices and applications cache passwords and automatically offer 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 normally must be retrievable. Many systems cache plaintext passwords (e.g., Android, iOS) and unfortunately there isn't much organizations can do about this, other than to promptly change passwords in the event that an endpoint device was lost or stolen.
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.
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:
If a single system is very insecure, then compromising that system will give an attacker the passwords for every other system which uses synchronized passwords.
This weakness is avoided by minimizing the use of such systems and requiring that users employ unsynchronized passwords on such weak systems.
Users with many passwords have trouble remembering them and consequently tend to write them down. System security is reduced to the security of a piece of paper, a note on the user's phone, etc. -- i.e., close to zero.
In practice, it is very difficult to get users who have many passwords to stop writing them down or keeping them on insecure media. The two arguments above therefore can be restated as:
Most modern systems and applications take reasonable precautions to protect their passwords, so synchronized passwords are normally more secure. To mitigate the risk of a single system compromise being leveraged by an attacker into a network-wide attack, follow these guidelines:
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.
Single sign-on (SSO) is any technology that replaces multiple, independent login prompts with a consolidated authentication process, so that users don't have to repeatedly sign in.
Many organizations are interested in reducing the burden of repeated login prompts for users. Eliminating some or all of these login prompts is referred to as "single sign-on" though more accurately it is "reduced sign-on."
There are several classes of reduced sign-on technology:
Users sign into a Kerberos domain -- typically using a Windows client signing into Active Directory. Their PC is issued a ticket which is passed to other server on the network when the user needs to authenticate to those systems.
Microsoft's adoption (and extension) of this technology has led many to refer to it as Integrated Windows Authentication (IWA) but the technology was actually originally developed at MIT and is underpinned by public standards.
Client software is deployed to user PCs (typically Windows). This detects login prompts displayed by various applications and automatically populates login IDs and passwords in those dialogs and screens. Application credentials are typically stored in some sort of a secure "wallet" -- on the filesystem, in a database or in a directory.
Enterprise single sign-on (E-SSO) systems are attractive to many organizations because they provide a single mechanism for both legacy applications (client/server, terminal based) and applications with a web user interface.
Web single sign-on (WebSSO) systems intercept user attempts to access web applications. A cookie in the user's web browser is checked to see if the user has already been authenticated. If the user has not yet signed on, the web browser is redirected to a login application where the user signs in. The user is then redirected back to the application login page and automatically signed into the web application.
Two common architectures of WebSSO systems are available, often in the same product.
In one approach, a web proxy server is used, which signs users into applications by retrieving application login credentials for every user, on every application, from a secure directory or database. These credentials are injected into the HTTP data stream between the WebSSO system and the application the user wishes to access. In this scenario, nothing is installed directly on the target application ("agentless architecture"); the user is not able to access the application URL directly, without going through the proxy; and a database of credentials must be maintained.
In a second approach, an agent is installed on each web application server. This requires a variety of agents to be developed -- one for each type of supported application. Using this architecture, the agent intercepts user access attempts and notifies the application where it is installed of the authenticated user's identity. In this architecture, there is no database of user credentials.
Federated access management means that users sign into a web site in one domain -- say the on the Intranet of their own corporation -- and are able to follow a URL link to a web site on another domain -- say a SaaS-hosted application. A trust relationship is defined between the two servers, such that the first server (in the user's domain of origin) vouches for the identity, authentication status and authorizations of the user to the second server. The most common mechanism for vouching for user data is to issue an assertion, using a standard protocol such as security assertions markup language (SAML).
Federated access management is also only applicable (in practice) to web applications. Its main advantage is that authentication and authorization information about users can be exchanged between systems under the control of different organizations, eliminating both redundant login prompts and user administration.
When organizations consider various approaches to single (or reduced) sign-on, they generally need to know:
The short answer is usually "yes."
The longer answer is more nuanced:
SSO works by extending the reach of an initial authentication step. So long as that step is robust, subsequent application logins are also secure. In other words, if users sign into the SSO system with a strong password (as described elsewhere in this document) or using a two-factor technology such as OTP+PIN, Smart card+PIN or biometric+password, then the SSO infrastructure rests on a robust process. On the other hand, if the SSO system depends on a weak password or PIN, on a proximity card, on a single physical authentication factor (which could be stolen) or on an easily recorded biometric, then the entire system is vulnerable.
Some SSO mechanisms depend on assertions, while others depend on the injection of login IDs and passwords into application login prompts. The latter set includes enterprise SSO and proxy-based web SSO.
Injection of application passwords depends on reliable, secure storage of passwords. This raises the question of where and how these passwords are stored and the SSO software itself is authenticated before it can retrieve these passwords.
For example, if a user signs into the SSO system using a biometric or proximity badge, there is no way to generate a consistent encryption key. This means that the SSO system must have direct access to stored passwords, even in cases where the user was not authenticated. On the other hand, if a user signs into the SSO system with a password, then the user's SSO password can be used to decrypt other passwords -- the SSO system does not have unlimited access to stored credentials.
The answer here is also nuanced, and depends on how users sign into the SSO system in the first place.
If password synchronization covers only secure systems, whose password databases have been protected against attack using strong encryption, good password composition rules, regular changes, history, intruder lockout, etc., then the security difference between SSO and synchronization is the difference between compromising a single robust password database (the one used to sign into the SSO system) and compromising any one of several such systems. i.e., infeasible in either case.
If users with into the SSO system using a weak password, proximity badge or single physical authentication factor, then the energy that an attacker must expend to compromise all credentials is lower than what the attacker would have to expend to compromise one of several strong password systems.
If users with into the SSO system using a two-factor technology or strong password, then the energy that an attacker must expend to compromise all credentials is at least as high as what the attacker would have to expend to compromise one of several strong password systems, with the possible exception of injected passwords (see enterprise SSO and proxy-based web SSO above) with a vulnerable encryption key management scheme.
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:
The process described above may be vulnerable to security weaknesses:
These problems can be overcome through:
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].
Today, almost every user carries at least one mobile device with them at all time. These devices are called 'smart phones' but they are really quite powerful and compact pocket-sized computers, with a decent quality display, touch screen, a rich variety of sensors and often with Internet access. Incidentally, these devices can make phone calls.
Devices owned by the user but accessing corporate information services are often referred to as 'bring your own device' or BYOD for short.
Users expect to be able to interact with a variety of computing service, including corporate password management systems, from these hand-held computers. They already interact with corporate e-mail, calendaring and other applications from these devices. This leads to some challenges:
Password management systems are typically deployed on-premise, attached to the private corporate network, and firewalled off from the public Internet. That's a problem for smart phones, since they are attached to the public Internet and usually have no access to services inside the corporate network. Enabling these devices to reach services inside the corporate network perimeter requires either opening inbound connections across firewalls or exchanging messages with an Internet-attached (cloud hosted) proxy system.
Text input into smart phones is a pain. Consequently, most phone-based apps try to minimize it, for example by caching passwords to corporate services. For example, users do not have to re-enter their password every time they read their corporate e-mail or check their corporate calendar on their phone. Whenever a user's password is changed on the network, these cached passwords are invalidated, and indeed the phone could trigger a lockout by offering the cached password too often.
Ideally, organizations deploying a password management system make it available to users via their smart phones. Rather than opening an inbound connection path across their corporate firewall, it is safer to broker communication between phones and an on-premise password management system via a cloud-hosted proxy.
It would be nice if the password management system, perhaps using an app deployed on user phones, could update locally cached passwords after each password change. Unfortunately, this is not technically possible: iOS and Android implement strong isolation between apps, plus many apps use proprietary storage to cache passwords, rather than the provided OS-level key-ring. A second-best solution, which is all that can be done today, is to send reminders from the password management system to the user, after each password change, reminding the user to update phone-cached passwords, along with instructions on how to do that.
There are contexts where a user needs to reset a password or clear a lockout, but cannot launch a browser on their PC. For example, a user may have forgotten their pre-boot password, used to unlock an encrypted filesystem, or their OS login password, used to sign into their PC. In each of these cases, a smart phone is a viable user interface, as it is most likely not locked out.
There is also a growing demand for users to leverage multi-factor authentication, for a variety of use cases, including authenticating into a self-service password reset system. A smart phone is a device which most users already have, so an app on a phone can be used as a credential ("something you have") in the login process.
Sample security questions, which may have alpha-numeric questions and so are suitable for a text user interface, include:
Sample security questions, that have numeric answers and so are suitable for authentication using a touch-tone phone, include:
This document was prepared by Hitachi ID Systems and reflects expertise with password management accumulated through many deployments of Hitachi ID Password Manager.