swipe to navigate

Different audiences

Organizations that use systems or applications must deploy and support that software as it exists, not as they wish it performed. As such, only a subset of NIST rules pertain -- those that do not require changes to the underlying software or service.

On the other hand, organizations that develop software can attempt to comply with a broader range of recommendations.

This document has separate sections for application developers versus the IT organizations that deploy and support applications.

Summary of new guidance

Following are important highlights from the new NIST guidelines:

NIST guidance Hitachi ID Systems view
Complexity is a problem, and making password management easier is important. This is consistent with what Hitachi ID has been saying since the early 1990s. This also underlines the need for some combination of single sign-on and password synchronization, to reduce the password management burden.
Don’t bother asking for mixed-case, special characters or digits because users just capitalize their password and append a 1 or similar. This is reasonable if it's compatible with existing systems and applications and if sufficient entropy comes from elsewhere -- e.g., password length.
Passwords should have an 8 character minimum with permissible length being at least 64 characters. This is entirely reasonable.
Skip password expiration -- users will just use patterns. Bulk-expire all passwords if and only if there is suspicion of a system compromise. This is reasonable if you are confident that plaintext passwords won't ever be compromised and if it's compatible with existing systems and applications. Neither of these constraints is currently realistic in an enterprise IAM system, however.
Enable display of plaintext passwords while typing -- in case the user is working in an isolated environment. This is a browser behaviour -- it should only be done when alone, and modern browsers already support it. Applications should still use the password-type input field when prompting for user input.
Allow pasting into password fields. Agreed. Applications that block browser or OS-level paste are annoying at a minimum and incompatible with consumer-type password managers.
Disallow dictionary-based passwords, passwords based on user name or service name, common sequences (123456) or passwords from previous bulk disclosures. Agreed -- this is nothing new and Hitachi ID Password Manager has enabled organizations to enforce such rules for many years.
Don't use password hints. Agreed -- that has never been a good idea.
Don't use knowledge-based authentication (KBA, security questions) for password resets. This is dubious, because at some level, organizations have to be able to support users who forgot their password. Sending a PIN to the user's phone is hardly a sufficient alternative, and some kind of password reset process is required for the system which forms the "root of trust" if users forget passwords to other systems. Instead, Hitachi ID recommends that organizations select a combination of KBA questions that is hard for an attacker to research and combine KBA with a second factor (app, PIN to phone, OTP devices, etc.).
Intruder lockout is required. This is not new and is obviously needed. Hitachi ID would suggest that the threshold should be set reasonably high, so as not to needlessly trigger lockouts and should automatically unlock after a while, to avoid pointless help desk workload. Intruder lockouts should operate per-user across authentication methods and per-network-address as well.
Store passwords with a random 32-bit salt and a secure one-way hash. This is reasonable and not new, except for an updated preference for algorithms. Obviously, this only applies to application developers.
Communication between users and an application or service must be over a secure channel. Obviously.
Periodically reauthenticate users -- do not allow never-ending sessions and do trigger a lockout after a period of inactivity. Reasonable.
Use two-factor or multi-factor authentication, rather than just a single factor, such as a password -- typically password+device; device+biometric or password+biometric. This is a a good idea where it can be implemented. All Hitachi ID customers get this for all users.
Avoid e-mail PIN and voicemail PIN as a second factor. Whether this is sensible depends on context. It takes a fairly sophisticated attacker to compromise personal e-mail INBOXes or voicemail in bulk. If this is just one of two factors, Hitachi ID thinks that, in most cases, these are reasonable second factors. On the other hand, in organizations that need to defend themselves against state-level actors or major organized crime syndicates, this is good guidance.
SMS/PIN is still OK in the final draft as a second factor. There was some controversy around this point before the final NIST guidance was published, since SMS can be compromised (as above, by a sophisticated attacker). Hitachi ID agrees that allowing for SMS/PIN as a 2FA is reasonable, especially as this is intended to be only of two factors.
Biometrics alone are not an acceptable form of authentication: biometric samples cannot be kept secret, cannot be revoked and in some cases can be copied and replayed. Hitachi ID agrees. Biometrics are a good proof of enrollment and can be a good way to unlock a second factor, such as a smart card, but should not be offered directly to an identity provider as a proof of identity at runtime.
Passwords should support all printing ASCII characters. Spaces, tabs, etc. should be avoided or stripped as users may type them unreliably. This is reasonable in organizations where all users and all applications operate in English. In organizations where some users interact with systems in another language, it makes sense to further reduce the character set, to ensure compatibility with all endpoints and services.
Password fields should support Unicode characters. This is actually bad advice, because of compatibility problems across systems (which may input or store passwords differently) and because many Unicode text input methods involve a display of the character being typed (risk of someone standing behind the user seeing the password). NIST acknowledges in their guidance that there are compatibility problems, a need for normalization, and possible inability to sign into some endpoints -- i.e., they are aware of the problems. Hitachi ID suggests allowing for Unicode passwords if and only if: (a) all users connect from the same type of endpoint and (b) all connections are to services running on the same platform.
Do give users guidance about the strength of chosen passwords. Agreed - the password change UI in Password Manager has done this for years.


Comment via LinkedIn