NIST has published new guidelines relating to security and privacy (I noted recent NIST’s involvement in privacy engineering here). As many of their documents, new guidelines will be influential for security and privacy engineering. Though they’re focused on Digital Identity, the reach will be much broader.

I paid attention to the guidelines development. There are many interesting points. In this note, I focus on a selection of important points which may well be generalised.

Security

There are plenty of interesting security engineering aspects in the guidelines. The most important are those related to passwords. They attempt to fix the long-held myth in security engineering industry relating, which propagated over the years. At some point, those myths were propagated mechanically.

Composition of password

Minimum length of password should be 8 chars, and maximum 64 chars. There should be no requirement on specific composition of a password. For example, weird rules such as “at least one special character, but not exclamation mark included after the question mark”. So Cutedog11_ goes away. Welcome the support of diceware.

No periodic password changes

NIST recommends not to make the user to change their password on an arbitrary basis. This is good for security. Imagine you’re a user who knows that the password needs to be changed in 30 days. Would you invest into memoizing complex secret only to repeat the procedure? Or would you rather pick something easy - or “better” even, put it on a yellow post-it note? The fact that users must cope with having lots of passwords these days is not helping - password managers are currently a good approach here. Indeed, password managers are another argument for phasing out requirements of arbitrary password changes. Of course, if evidence of compromise surfaces, the systems should be able to enforce password changes. But in that case, it is not “arbitrary”.

I can’t recall where the recommendation of periodic password change come from. If memory serves, this was from an obscure US Army report published a few decades ago.

Security Questions are going away

Systems should not store or require hints of the kind “what’s the name of your second most favorite pet”.

Pre-verification of strength

Strength meters should be shown to the user. The system should, on its own, check the chosen password against a list of common weak passwords. This may include dictionary words, previously used passwords, etc.

Users should be able to paste passwords

Some systems disable pasting functionality, probably in response to the risk of fraud or automatic scripts. In NIST’s view, it appears to be bad security UX. Pasting passwords into online forms should be allowed.

No more * * * *

Systems should have option to display the password as it’s being typed, instead of dots or asterisks. This is good for security UX. Goodbye ** * * **.

Storing passwords

No surprise here. Use hash and salt. Examples of key derivation functions are PBKDF2 or Balloon, with an approved standard hash function, such as SHA-3. Avoiding salt (at least 32 bits) collisions is recommended.

Secret salt should also be employed when hashing the password. This will decrease the risk of password recovery in case a database of hashed passwords would leak. That’s a nice recommendation, following the leaks of hundreds of millions of hashed secrets...

Privacy

The guidelines include privacy considerations. This is a good standard and should be a standard in itself. Furthermore, NIST acknowledges the importance of privacy-enhancing technologies and techniques. That’s a clear sign that privacy engineering is gaining momentum. So we have support for pseudonymization, cryptographic privacy-preserving methods, and careful consideration of identifiers during design. Indeed, identity systems and their deployments should treat privacy risk assessment process as a standard requirement.

Privacy Risk Management and Privacy Impact Assessment

Privacy risk management is recommended approach. It should be made side-by-side with other proceedings, in particularly, defining operational/business needs of the system. In other words, privacy becomes an integral aspect of requirements engineering. This is not only about legal compliance requirements. It’s about retention periods, the processing requirements, the types of processed data, but also about balance. Privacy risk assessment must contain the identified risks, the mitigation strategies, the chosen solution and the usual considerations of likelihood and impacts of privacy risks. These must be documented. I usually recommend to include these in the scope of a technical part of Privacy Impact Assessment (two notes on PIAs: 1, 2), which is also recommended by NIST. This kind of approach is gaining popularity world-wide.

Tracking and profiling

NIST notes that when designing identity systems, tracking and profiling should be minimal. Identity systems should basically do one thing. When federated systems are concerned, risk of profiling naturally arises. This should be carefully assessed.

Strategies

Explicitly mentioned privacy strategies include: data minimization, privacy considerations over consent, use limitation to avoid the risk of secondary uses, etc.. These should be accommodated by appropriate privacy controls, which are required.
Privacy policies should explicitly forbid correlating identifiers between unrelated database. In essence, this recommendation discourages from building large centralized databases - and also mapping users between two separate databases.

Summary

I recommend reading them all to anyone designing identity and authentication systems. But the guidelines contain plenty of useful design remarks going beyond.