This piece highlights the pros and cons of passwords for organizations, and best practices for composing passwords, and updating company policies and authentication processes to increase security.
Password Pros and Cons
Passwords are the simplest technology available to authenticate users when they sign into systems and applications, but they have pros and cons:
Password Pros:
Universality: They work from every type of device where text input is possible, every kind of system and application that someone might want to sign into, and all users (unlike biometrics and some hardware devices).
Inexpensive: They require no special hardware or sensors.
Password Cons:
- Security: Passwords are vulnerable to well-known attacks, including:
- Password guessing, either in a targeted or bulk fashion.
- Denial of service, by triggering account lockouts through intentional, repeated bad login attempts.
- Man-in-the-middle attacks, where attackers access passwords in transit by intercepting plain text communication between a client and server.
- Bulk compromise, where the file or database that stores passwords is stolen and attacked offline. This is catastrophic where passwords are stored in plain text, but it can also be very damaging where passwords are securely hashed, because
the rate of password guesses can be very high when using modern GPU hardware.
- Client-side exploits: Key-loggers and attacks against the memory or disk of a client device can often uncover passwords.
- Usability: People hate typing passwords and often forget them.
- Support cost: The No. 1 type of support incident in most IT helpdesks is to resolve login problems due to users who forgot or locked out their passwords.
How to Secure Passwords
To help mitigate the security vulnerabilities of passwords, organizations should consider:
- Controlling access to password databases, so they cannot be compromised in bulk. This means using appropriate access controls, operating system security, patch management, etc.
- Ensuring passwords are always stored as a salted hash.
- Verifying passwords are never transmitted in plain text, including at login time and when changed.
- Protecting user devices against key-logger and similar attacks, and block logins from devices where basic endpoint security cannot be assured.
- Instructing users to never share or write down passwords.
- Requiring users to change passwords periodically, so compromised values have a limited lifespan, closing the window of opportunity for attackers.
Unfortunately, those password security requirements alone probably are not enough. Passwords can also be compromised by:
- Third parties: A third party hosting a software-as-a-service (SaaS) application may have its password database stolen, perhaps by a malicious insider.
- An off-the-shelf application: It may use internal passwords, encoded in plain text or some other insecure method.
- A client/server application: It may send passwords in the clear.
- User devices may be compromised by key-loggers. Desktop PCs are especially easy to compromise by someone with physical access who inserts a device between the keyboard and PC.
- Users: They can be counted on to behave badly.
These challenges are why passwords are a weak form of authentication. It is difficult to get everything right, in all contexts.
REALTED CONTENT: Key Considerations for Password-less Authentication
Improving Password Security
To improve password security, it makes sense to add another factor. Authentication is any process where users prove that it is really them, rather than an impostor, logging in. This may be done by the user providing something they know, and others should
not know (a secret, such as a password or PIN), or some physical characteristic of the user being measured (biometrics) or users proving possession of a physical, personal device such as a hardware token, smart card or phone.
However, no method is perfect -- for any given biometric, some users cannot provide a sample (amputees, blind users, etc.). Biometrics also cannot be repudiated -- if malicious actors steal a user's biometric data, they may be able to inject that data
into a reader and impersonate the user. Hardware devices can be costly, may be lost or stolen and in some cases require readers. Because of these challenges, it is reasonable to offer a variety of authentication factors.
Unfortunately, multi-factor authentication (MFA) is both costly and complex. Many applications cannot directly support it and implementing such a system once per application is impractical. This is where federated access is helpful.
First, configure a single system to authenticate users with two or more credentials – typically a password or PIN combined with a smartphone app or biometric. Next, configure every application to outsource its authentication to this shared infrastructure.
This can be done using Kerberos for on-premises Windows-integrated applications, and Open ID Connect (OIDC) or SAMLv2 for web applications.
When credentials are combined, no single factor needs to be as secure. For example, sending a PIN to users via SMS is not very secure, but combining that with a password is often good enough. Similarly, a short, all-lowercase password is not very secure,
but when combined with a smartphone app, it may be sufficient.
Even if MFA is not deployed universally, consider making it mandatory at least for high-risk users.
What to Avoid in a Password Policy
Whether you deploy MFA or not, consider avoiding the following issues when formulating a strong password policy:
- Failing to consider the limitations of existing systems and applications: When formulating a password policy, first check what each system where the policy will be applied can accept for password values. For example, how long a password can be set?
Does the system differentiate between uppercase and lowercase letters? Can users enter digits? Punctuation marks? The weakest system is often a mainframe because it supports just eight-character passwords consisting of case-insensitive letters,
digits and only three punctuation marks. Also, mainframe passwords must begin with a letter. A separate, weaker password policy should be used for such legacy systems.
- Using Unicode passwords. User input may map to different character codes, depending on the kind of device the user connected from, leading to hard-to-diagnose login problems. Moreover, Unicode text input involves display of the user-entered character,
which is both a nuisance for the user and a security vulnerability because what the user types is visible to someone standing behind the user. In other words, it is best to limit passwords to US-ASCII letters, digits and punctuation marks. These
can be entered on any keyboard or touch screen and yield the same codes consistently, without display of what the user typed.
- Using passphrases (long sentences). This is because users will typically select a short sentence that makes sense in their language, and the rules of grammar and syntax mean the amount of entropy per character is very low – often less than 2
bits. This makes passphrase guessing attacks surprisingly effective.
- Letting users choose predictable passwords. This includes those based on their name, login ID or a dictionary word. Password policy should forbid passwords based on any of those.
Number of Possible Passwords
The number of possible passwords for a given policy can be computed as follows:
- L = the minimum length of passwords
- C = the number of allowed characters
- P = the number of possible passwords
- P = CL
The table above demonstrates that longer passwords are more computationally expensive to guess than those that use more character classes.
Password Policy Requirements
Ideally, all systems where the policy will be implemented support passwords with mixed-case letters, digits and punctuation marks, and have large limits on password length (at least 20 characters are legal).
Your complexity rules then depend on how difficult you want it to be for an attacker who has managed to steal a copy of the hashed and salted password database to guess a password. A modern GPU can test about a billion possible passwords per second, so
if someone can steal the mainframe password database, it will be 100 percent cracked very quickly. On the other hand, a 10-character password with mixed-case and digits would take thousands of years to crack.
Consider the following requirements as a framework for a reasonable policy:
- Only US-ASCII characters (not Unicode).
- Minimum of 10 characters.
- At least one lowercase letter.
- At least one uppercase letter.
- At least one digit.
- No literal dictionary words, forward or backward. This rule should only apply to dictionary words of at least four letters, because forbidding "a" or "it" or "the" makes the set of legal passwords smaller. Choose a large dictionary and add dictionaries
for every human language your users use.
- No usernames of at least four letters, forward or backward. This should be applied to first name, last name, middle name and login ID.
- If possible, include at least one punctuation mark.
Many organizations implement a basic policy such as the above, and an even stronger policy (with longer passwords) for high-risk users, such as executive management, human resources or system administrators.
Implement Secure Password Change Processes
Because users inevitably do share or write down their passwords or may use the same password they have at work on many consumer-facing websites, some of which may have been compromised, it is reasonable to ask users to change their passwords periodically.
To help avoid issues associated with when and how passwords are changed, consider the following:
- Secure the password reset process: Users who forget or lock out their passwords may call the helpdesk or interact with a self-service portal. Be sure the non-password authentication process is as least as strong as the passwords that will be unlocked
or replaced. Otherwise, attackers could try to compromise a user's account by convincing the helpdesk to reset a user's password for them. One way to ensure this type of attack cannot happen is to send a random PIN to the mobile phone or personal
e-mail address of any user requesting a reset. If the users can enter that, ask them to answer a few security questions.
- Set all helpdesk-provided passwords to expire. When the helpdesk resets a user's password to a known value, the window of time during which the helpdesk technician knows the user's new password should be short.
- Remind users to change passwords periodically. Once every 90 or 120 days is typical and reasonable. Send reminders a few times (e.g., 10 days, 5 days, 3, 2 and 1 day) ahead of expiry and force password change eventually.
- Don't allow password reuse. There is no reason for password history to be limited to "last N" for some small integer N.
- Allow users to change passwords as often as they would like. The only reason for legacy "maximum one password change per day" rules exist is due to a small N in the history rule.
- Explain password policy in the password change UI, and visually indicate which rules the user's new password satisfies as the user types.
- Give clear feedback in the password change UI about which systems and applications will get the new password.
- Implement an intruder lockout on login screens. For example, set it so 10 successive failed logins in under 30 minutes causes the account to be locked out for 15 minutes. This limits the rate at which an attacker can try to guess passwords by feeding
data into the login system. The number of failed attempts can be high enough to avoid nuisance to users (10 or 20 is fine) and an automatic unlock can reduce helpdesk calls without giving attackers too much leverage.
- Consider an enterprise password management system (for synchronization, reset and policy enforcement) to help users choose and manage passwords securely and conveniently. Verify compatibility with client devices, user contexts (e.g., offline with
a locally cached password) and login systems.
- Consider a password wallet application which stores and injects random passwords on behalf of users. If implementing one, carefully validate compatibility with user devices, client apps such as browsers and login systems. Also investigate how securely
the system stores and synchronizes credentials and what happens if users are unable to unlock their password wallet.
Establishing a Secure Password Policy
Ideally, your password policies make it easy for users to comply. With that in mind, consider:
- Using federation where possible to reduce the number of passwords users must remember and login screens users must sign into. Move away from per-application login screens and use federation to consolidate logins into a more sophisticated MFA scheme.
- Avoiding weakening the password policy to accommodate legacy systems. If some systems or applications with password-based logins require simple passwords, ensure those passwords are not used on other systems.
- Looking for and fixing the weakest link. This may be an application that stores passwords in plaintext or a weak helpdesk process. Fix what you can and isolate what you cannot (legacy systems/applications).
- Avoiding passphrases. They seem secure but are not, due to the structure of human languages.
- Avoiding non-ASCII passwords. These are secure but can create both usability and compatibility problems.
- Avoiding very long passwords. Users struggle both to remember and enter them.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.