It is important to distinguish the use of a password manager by an individual from single sign-on (SSO) access to your systems. Single sign-on does not depend upon each application, platform, or system within your architecture having a password defined for a user to access it. SSO is discussed in more detail later in the “Single Sign-On” section.
Using a password manager system can provide greater security for an individual user, and organizations that need their users to routinely access systems outside of the organization may find it worthwhile to look at corporate implementation strategies for them. They can, however, lead to two novel and potentially catastrophic security failures, if not configured and used properly.
The first case, in which all passwords would be compromised, occurs when the central repository for the user's passwords is breached. This can happen either if the master password is guessed by an attacker on the user's system (the one your organization manages) or if the password manager vendor's central repository is breached. This should not be possible if proper encryption techniques are used in either case to protect the repository information while in use, at rest, and in motion; that said, it is a significant risk that must be addressed.
Password managers entail another, much simpler risk, too, which is the possibility that the user might forget the master password. Eventual recovery might be possible, depending on the brand of password management software, but some operational disruption would be certain. This also requires users (individual or corporate) to repose great trust in their password management system vendor, the recovery agent, or both.
In 2017, the U.S. National Institute of Standards and Technology (NIST) has updated its password and passphrase policy recommendations. (See https://pages.nist.gov/800-63-3/sp800-63-3.html.) Based on many years of industry experience and with input from security researchers and academics alike, NIST's new recommendations overturn many of password policies that have been in widespread use for decades. For example, NIST no longer recommends requiring a periodic reset of user passwords, as this tends to promote poorer password hygiene among users. NIST also recommends against classical ideas of password complexity for the same reason. Many of these recommendations are reflected in this chapter; study them and see how they can be put to use to improve your organization's security posture.
Passphrases
Since about 2016, more and more voices in the information security community have recommended the use of strong passphrases instead of passwords, primarily as a way to avoid all of the inherent failings of humans and human organizations to make effective use of more complex passwords. (One of the industry pundits who first advocated complex passwords actually offered a bit of an apology for doing so, as he acknowledged his change of heart on this topic.) A passphrase is a longer string of characters that ideally is both meaningful and memorable to its user and creator but is not easily inferred by others based on public knowledge about that individual. It should also not be a direct quote (with or without spaces and punctuation) from a published work. For example, if I am a well-known fan of J. R. R. Tolkien's body of fantasy works, a passphrase such as “inawholeindagroundlovedahobbit” might be too easy for someone to deduce based on my interests. (If I am anything but a fan of fantasy, by contrast, it just might be a start on a good passphrase.) Some of the best passphrases are made by combining four or five totally unrelated words together, with the occasional shift of letter case or a substitution of vowels with numbers. “Strongch33z3janerator,” for example, might start with “strong phrase generator” and be tweaked by the user into a phrase that might withstand attack for 35 quintillion years, according to www.howsecureismypassword.net (but don't use it as is because it's been published). Adding a few extra characters to a passphrase, such as tacking on a four-digit number to its end, does nothing for its overall hardness. Do be aware that many systems have length limits on the input fields for passwords (or passphrases) and advise users to stay within those lengths.
Several key benefits come from using passphrases instead of classic but complex passwords:
Users find them easier to create and remember, without relying on publicly available knowledge about them as a person.
Longer passphrases exponentially increase the search space that a password cracker has to operate in, requiring much larger dictionaries or rainbow tables as well as far more CPU cycles.
Passphrases actually make it easier for users to creatively use numbers, case shifts, and special characters as part of their phrase than they can in much shorter passwords.
Security practitioners are also recommending that with proper use, passphrases do not benefit from being changed periodically.
Passphrases, of course, are prone to being written down and to being reused on more than one system that the user has access to. Using a password manager application can help with these risks.
All but the most rudimentary legacy systems actually store a hash of a user's password, passphrase, or other Type I factor value; if an attacker exfiltrates a copy of the stored hash of the factor, they face a computationally infeasible (or tremendous brute force) burden of trying to unhash that back into its original plaintext form. This hash function should be applied at the endpoint device at which the user enters the factor so that only the hash is transmitted to the access control system.
Secure hash functions can be made much more secure by appending a pseudorandomly generated salt value to the input plaintext version of the factor before hashing it. Secure frameworks and systems tools make it easier for systems administrators to add salt to their hash function use and provide many powerful ways to select and manage salts.
There is no practical reason why the plaintext version of a Type I factor has to be stored in your system—anywhere.
Security Questions
Security questions are often used as an additional Type I factor during authentication. These often use a preset list of security questions that users must answer during account provisioning or after a password is forgotten. Typically, the system hashes the answers entered by the user (ideally at the user's endpoint device!) and stores the hashed answers in a table associated with the user ID. A very few systems treat the answer to a security question in ways that allow the user to vary the way that they enter it (such as with fewer blank spaces or in a different mix of upper and lowercase); while this may make “passing this quiz” easier on the user, it also reduces the security of the system overall and would not therefore be a recommended approach.
At each login or access attempt, the user is asked to provide answers to a certain number of these questions. Retry logic might allow two incorrect responses to a set of five randomly chosen questions, for example, before the user must contact the help desk for assistance and verification of their identity.
In many respects, security questions are just another set of passwords, and they suffer from all of the shortcomings and risks that passwords do. Users have been prone to take screenshots of the questions and answers as they first establish them and then store that file in an unprotected way on their system, for example. (You don't do that, do you?)
In practice, most security questions reflect open source information (often called OSINT) about the subject—that is, information that is published or public-facing—which