Last week, Vy, a large Norwegian transport company, announced their new password composition rules by email and on their website. The password requirements, presented under the heading “increased security for passwords”, are as follows:

  • At least eight characters
  • At least one number
  • At least one special character
  • At least one lowercase letter
  • At least one uppercase letter

I.e. one modest length requirement, and four separate composition rules. Knowing that the National Institute of Standards and Technology (NIST) specifically identifies composition rules as bad practice, I obviously made a complaint on LinkedIn. In response, Vy claimed to be in compliance with the recommendations of Norway’s National Security Authority:

Screenshot of Vy’s LinkedIn reply, in Norwegian.

In English: Briefly explained, there is a small mismatch between what NIST and NSM recommend, but we follow NSM’s recommendations.

They are, in fact, wrong. (Or I wouldn’t be writing this post.) Anyway, let’s answer the following questions:

  • What are best practices according to NSM?
  • What are best practices according to NIST?
  • What should Vy do differently?

What are the best practices according to NSM?

Norway’s National Security Authority a.k.a. Nasjonal Sikkerhetsmyndighet (NSM) has published two articles that provide guidelines for creating passwords that are both secure and memorable by means of normative examples.

The first source was published by NSM in 2019, was last updated in 2024, and is in a section of its site which is continuously updated with current best practices. Advice and Recommendations about Passwords is written in Norwegian, and so I have translated relevant excerpts into English for this post.

Length and complexity are both essential to create a strong password that is hard to break for both humans and machines. E.g.,

Ad si17#¤rO Ple,()!#?-ZCWEerg?`^&

Such passwords can, however, be impractical in terms of memorability, and any single typing mistake means you have to start over. A passphrase might be easier to use, while remaining a strong password. E.g.,

Jæ liker mei faktisk på ærbe

Notice the spaces and Norwegian letters. And several words are spelled in a way that does not appear in any dictionary by means of both deliberate spelling errors and dialect.

The advice (with slightly stronger wording) was initially published in Recommendations on Passwords by NSM. This is an article from 2018, last updated in 2020, and written in direct response to a news cycle about what I believe was a database with leaked credentials.

It is an excellent article, which, briefly summarized, argues that long and complex passwords are strong, but they are hard to remember. As a result, users will keep passwords on Post-its on their desks, forget them, or choose passwords as simple as they are allowed. Meanwhile, computers are excellent at guessing passwords up to a certain length. Special characters do not significantly alter this calculus. Threat actors will also use dictionary attacks, or start an attack by guessing leaked or popular passwords, which works because humans are often predictable when selecting passwords.

The presented solution to all of this is password phrases of at least 16 characters, which are relatively easy for humans to remember and type, yet relatively hard for computers to guess.

Previous recommendations with special characters would give password phrases like:

J1gbrukerF@cebOOkpaajobb1

It satisfies length and complexity, and is a phrase, but the combination will be very difficult to remember.

NSM recommends a longer, easier-to-remember phrase like:

JegbrukerFacebookpåjobben

Better yet, also consider using dialect and spaces:

Je bruker Facebookpåarbe

In brief, no recommended example is consistent with Vy’s rules for composition.

What are the best practices according to NIST?

The American National Institute of Standards and Technology (NIST) publishes Special Publication (SP) 800-63B-4, a set of guidelines, intended for American federal agencies, on the implementation of digital identity services. NIST is an internationally recognized authority on cybersecurity, and the document is widely used outside this context. NSM, for example, frequently references both the NIST SP 800-63B-4 document and other NIST publications in its own recommendations.

SP 800-63B-4, Section 3.1.1.2: Password Verifiers pertains to passwords, and prescribes requirements for verifiers and credential service providers (CSPs) in RFC 2119-style language. Directly relevant to the topic of password composition rules are the following:

  • Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length.
  • Verifiers and CSPs MAY allow passwords that are only used as part of multi-factor authentication processes to be shorter but SHALL require them to be a minimum of eight characters in length.
  • Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.

The rationale is provided in Appendix A, and the core ideas are two simple insights, each substantiated by peer-reviewed scientific articles:

  • Password length is a primary factor in characterizing password strength1,2.
  • Users respond in very predictable ways to the requirements imposed by composition rules3.

Keeping in mind that the intention of composition rules is to rule out known-weak passwords, note that SP 800-63B-4 instead dictates that passwords be compared against a blocklist, e.g., passwords obtained from previous breach corpuses, dictionary words, and context-specific words, such as the name of the service, the username, and derivatives thereof.

It might also be of interest that SP 800-63B-3, published in 2017, changed the previous requirement from recommending composition rules to SHOULD NOT, a slightly weaker requirement than the current version. And finally, in case I end up using this post as a reference in the future, here are the additional requirements:

  • Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.
  • Verifiers and CSPs SHOULD accept all printing ASCII [RFC20] characters and the space character in passwords.
  • Verifiers and CSPs SHOULD accept Unicode [ISO/IEC 10646] characters in passwords. Each Unicode code point SHALL be counted as a single character when evaluating password length.
  • Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.
  • Verifiers and CSPs SHALL NOT permit the subscriber to store a hint (e.g., a reminder of how the password was created) that is accessible to an unauthenticated claimant.
  • Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication (KBA) (e.g., “What was the name of your first pet?”) or security questions when choosing passwords.
  • Verifiers SHALL request the password to be provided in full (not a subset of it) and SHALL verify the entire submitted password (e.g., not truncate it).

What should Vy do differently?

Vy need to adhere to the composition requirements set forth by NIST in SP 800-63B. Furthermore, they should adhere to NSM’s slightly stronger requirement for password length. I.e.:

  • 16 characters minimum for single-factor password authentication
  • No other composition rules
  • Blocklist of known-weak passwords

Moreover, they need to go through all requirements of SP 800-63B-4, Section 3.1.1.2, and ensure they are in compliance with all of them. Any deviation should be intentional, and have a valid and explicit reason.

This brings them into compliance with the current best practices as recommended by both NIST and NSM.

  1. P. G. Kelley, S. Komanduri, M. L. Mazurek, R. Shay, T. Vidas, L. Bauer, N. Christin, L. F. Cranor, and J. López, “Guess Again (and Again and Again): Measuring Password Strength by Simulating Password-Cracking Algorithms,” in 2012 IEEE Symposium on Security and Privacy, San Francisco, CA, USA, 2012, pp. 523–537. https://doi.org/10.1109/SP.2012.38 ↩︎

  2. S. Komanduri, R. Shay, P. G. Kelley, M. L. Mazurek, L. Bauer, N. Christin, L. F. Cranor, and S. Egelman, “Of Passwords and People: Measuring the Effect of Password-Composition Policies,” in Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI ‘11), Vancouver, BC, Canada, 2011, pp. 2595–2604. https://doi.org/10.1145/1978942.1979321 ↩︎

  3. M. Weir, S. Aggarwal, M. Collins, and H. Stern, “Testing Metrics for Password Creation Policies by Attacking Large Sets of Revealed Passwords,” in Proceedings of the 17th ACM Conference on Computer and Communications Security (CCS ‘10), Chicago, IL, USA, 2010, pp. 162–175. https://doi.org/10.1145/1866307.1866327 ↩︎