NIST SP 800-63B-4: Understanding the New Password Security Standard (with significant updates on November 7th)

Passwords remain one of the most widely used authentication methods in the digital age, but did you know that many traditional password policies are actually counterproductive?

Issued by NIST (National Institute of Standards and Technology)SP 800-63B-4provides the latest guidelines on password security, and includes content that overturns conventional wisdom (which has long been accepted as common knowledge among experts). This article provides an easy-to-understand explanation of the core of this important document for those in charge of password-based user authentication systems within companies, as well as those responsible for setting such policies and managers.

Two categories of passwords

NIST SP 800-63B-4 classifies passwords into two types:

1. Passwords Server-side validated secrets, sent to the server upon login and validated centrally.

2. Activation Secrets Secrets that are verified locally on the device, such as a smartphone unlock PIN, are never sent to a server.

New requirements that overturn conventional "common sense"

❌ Things you shouldn't do

No forced periodic password changes

• Enforcing password changes every 90 days is no longer recommended
• Changes should only be requested if there is evidence of infringement
• Reason: Frequent changes cause users to choose predictable and weak passwords

NOTE: Some consultants say that this is required by ISMS and the like, but that's a mistake. ISO/IEC 27002 doesn't say anything about it; in fact, it says, "Requiring frequent change of passwords can be problematic." (I actually wrote the text about this part myself, around 2013. Note that there are also cases where passwords need to be changed.)

No imposition of complexity requirements

• SHALL NOT impose requirements such as "must contain uppercase and lowercase letters, numbers, and symbols"
• It has been stated to be harmful
• Rationale: Such requirements lead users to use predictable patterns like "Password1!"

Disable password hints

• Don't use hints or security questions like "What's your mother's maiden name?"
• These are valuable sources of information for attackers. In fact, there is a high probability that this information is known in multiple places, so it would be terrible if they could use this to reset authentication methods.

✅ Recommended requirements

1. Password length

• Single-factor authentication: minimum 15 characters
• Part of multi-factor authentication: minimum 8 characters
• Maximum length: should allow 64 characters or more

Length is the key to strength.It's like replacing parts of common password words with common symbol substitution rules (a → @, o → 0, s → 5, etc.)"correct horse battery staple" is far more powerful than "P@ssw0rd".This is a bit of a detailed discussion, so if you are interested in the details, please see the end of the article.Annex A.

NOTE: The current ISO/IEC 27002 includes a statement that dictionary word combinations should be excluded (C) 2) in 5.17 User responsibilities). This is an oversight on my part. They must be eliminated in the next edition.

2. Flexibility in character types

• Accepts all printable ASCII characters and spaces
• Unicode characters (Japanese, emoji, etc.) should also be supported.
  NOTE: To be honest, I don't like this, because it brings up the issue of Unicode normalization (incidentally, it is a SHOULD to perform NFC normalization).
• This allows users to create strong passwords that are easy to remember.

3. Implementing a Blocklist

Validators must check against a blocklist that includes:

• Passwords leaked in previous breaches
• Dictionary words
• Context-specific information such as service names and user names
• Common passwords such as "123456" or "password"

If you are on a blocklist, we will explain the reason for the rejection and allow you to choose a different password.

4. Active support for password managers

• Allow use of password manager (required)
• Supports autofill function
  NOTE: It's necessary for using a password manager. Recently, there has been an increase in websites in Japan that don't allow this, which is a bit of a mystery...
• Enable the paste function
  NOTE: Ibid.
• Why: Password managers allow users to use strong, unique passwords for each service.
  NOTE: Not only that, but many password managers validate the URL you submit to them, which is important for phishing resistance.

5. Improved user experience

• Provides a password display option (so you can see it while you type)
• This reduces typing errors and frustration for users.
  NOTE: This is especially important for smartphones.

Server-side requirements: Secure storage

There are also strict requirements regarding password storage:

Required items

• Use a good password hashing scheme
• Use at least a 32-bit salt
• Store both the salt and the hash
• Stored in a format that is resistant to offline attacks

Recommendations

• An additional encryption operation using a private key known only to the verifier
• This private key is stored separately from the hashed password.

Activation Secret (PIN) Requirements

There are also requirements for secrets used within the device, such as a smartphone unlock PIN:

• At least 4 characters (6 or more characters recommended)
• Can be entirely numeric
• Limit consecutive failed attempts to 10 or less
• Implementing a block list of common PINs (e.g., 123456) is recommended.
• At the AAL3 level, verification in a hardware-protected environment (secure element, TPM, TEE, etc.) is required.

Implementation Impact

These requirements affect both service providers and users:

For service providers

• Existing password policies need to be reviewed
• Implementing the block list function
• Ensuring Password Manager Support
• Restructuring user education

for users

• You can now choose passwords that are easier to remember
• Using a password manager is recommended
• Free yourself from unnecessary periodic changes
• Better user experience

My Feelings, Then and Now

NIST SP 800-63B-4 provides evidence-based password policies that balance security and usability. Key points include:

1. Length determines strength – Length over complexity
2. No need to change it regularly – Do not force changes without evidence of infringement
3. Utilizing block lists – Proactively block known weak passwords
4. Password manager recommended – Supporting users with technology
5. Focus on user experience – Security and usability can coexist

Passwords will continue to play a vital role in managing digital identities, and following the guidance in NIST SP 800-63B-4 will help you build a more secure and user-friendly system.

Does your organization or service's password policy comply with these latest standards? It may be time to take a fresh look.

(I'm also planning to make a more technically focused YouTube video, not a Short. Stay tuned.)

In the end, I wasn't able to go into much detail, but I made a YouTube video. Please enjoy. (I thought it would be better to do a live broadcast while answering questions, as it would take less time, but I'm in a different time zone from the West Coast.)

---

Appendix A: Password Strength

@yunishio pointed this out to me in a tweet (X's post), and I thought it was certainly misleading, so I added it to the main text.UnderlineI have added the following and will provide more details below.

It's well put together, but there's one fatal mistake.

→ "correct horse battery staple" is far more powerful than "P@ssw0rd".

The latter is only strong enough to contain around 8 alphanumeric characters.

NIST SP 800-63B-4: Deciphering the New Standard for Password Security https://t.co/ZaZ5iiMiE2 via @_nat

— yunishio (@yunishio) November 6, 2025

First, as a bit of background information, the phrase "correct horse battery staple" mentioned in this article was used as an example of a "long, easy-to-remember passphrase" in episode 936, "Password Strength" (August 2011), of the American webcomic "xkcd," which aims to raise awareness of password strength. This phrase has become somewhat symbolic in discussions of password strength, and is a historic figure that actually promoted the use of passphrases. Conversely, this passphrase should naturally be included in the block list when registering a password.

Now, as I added to the main text, SP800-63-4 says that if you request a combination of symbols or numbers, it has been proven that it will result in ordinary words with ordinary substitution rules applied, so you should stop doing that. Taking this into consideration, we will calculate entropy.

Let's start with the passphrase.

Calculating word phrase entropy

First, let's get the basic formula down.

Entropy (bits) = log_⁡2(size of trial space).
If the number of trial spaces is X, the amount of information is log_⁡2(​X) bit.

Dictionary Size N から k When choosing a word randomly:

H = k log_⁡2(N)

.

• N=3,000: log_⁡2(3000)≈11.55 bits/word
  → 4 words: 4 × 11.55 ≈ 46.20 bits
• N=25,000 (rough word count in the Cambridge Concise English Dictionary): log⁡₂(25000)≈14.61 bits/word
  → 4 words: 4 × 14.61 ≈ 58.44 bits

This is approximately 46.20 to 58.44 bits.

On the other hand, if you want to randomly select 8 characters from the 62 alphanumeric characters (a–z, A–Z, 0–9),

• log_⁡2(62) ≈ 5.9542 bits/character
• → 8×5.9542≈47.63≈47.63 bits

The information content of two alphanumeric characters is 2×log_⁡2(62)≈11.912 bits, so one word (evenly split into 3,000 words) is ≈11.55 bits, which is indeed "almost two characters" as @yunishio said.

But the point here is not to compare 62 randomly chosen characters with your passphrase.

As mentioned above, NIST points out that forcing mixed case tends to result in common passwords processed using common substitution rules, and this is what we are comparing.

Next, let's consider the strength of common password substitution methods.

"P@ssw0rd"-type model (when an attacker tries a dictionary + substitution rule)

Model the number of attempts an attacker uses:

Number of attempts =B×S×C

• B: Number of base words to consider (e.g. top 1, top 100, top 1,000, top 10,000)
• S: Number of substitution patterns (e.g., leet conversion) (e.g., 5, 10, 30, 100)
• C: Number of uppercase/lowercase change patterns (e.g. 1, 2, 4)

Calculation using representative combinations (log_⁡2(expanded below):

1. Very specific (targeted: just that word, few substitutions)
   • B=1,S=10,C=2 → number of trials = 1×10×2=20
     log_⁡2(20)≈4.32 bits/word
2. Attackers use small lists of common words
   • B=100,S=10,C=2 → number of trials = 2,000
     log_⁡2(2000)=log_⁡2(2×1000)=1+log_⁡2(1000)≈1+9.96578=10.97 bits
3. Larger but more realistic dictionary + more substitutions
   • B=1000,S=30,C=2 → number of trials = 60,000
     log_⁡2(60,000)=log_⁡2(1000+log_⁡2(30)+log_⁡2(2)≈9.96578+4.90689+1=15.87 bits
4. If the attacker tries a fairly large list + substitution
   • B=10,000,S=30,C=4 → number of trials = 1,200,000
     log_⁡2(1,200,000)≈20.19 bits
5. Extremely wide substitution pattern (worst case)
   • B=10,000,S=100,C=4 → number of trials = 4,000,000
     log_⁡2(4,000,000)≈21.93 bits

In any realistic model, the entropy of "variation of the P@ssw0rd system" goes only up to about 20–22 bits (usually much less).

In other words, Entropy of a 4-word passphrase46.20 to 58.44 bits > Entropy of character substitution patterns like "P@ssw0rd"4.32 to 21.93 bits, indicating that the Entropy of a 4-word passphrase is orders of magnitude stronger than the entropy of character substitution patterns, is the key point here.

Incidentally, passphrases are something you need to remember, and even in this case, you need to randomly choose a word from a large enough vocabulary. If you use a dictionary, you'll have to open it randomly, close your eyes, point to a page, and select the entry, repeating this process as many times as necessary. Well, that's a pain, so it's easier to have a password manager with a passphrase generation function choose one for you.

What you don't need to remember (most of the time)Use a password manager to create a random string of 15 characters or moreTheRecommendationWell, in a word,Use a password manager, which makes passkey migration easy, that's what it comes down to.