passwords

Sep 21, 2025 ∞

The previous version of NIST SP 800-63B, section 5.1.1.2, said that organizations SHOULD NOT require users to update their passwords on a regular basis, unless they believe that the password was compromised. The 2025-05-30 version moved that to section 3.1.1.2 and updated it to say organizations SHALL NOT do that.

Now whenever a website emails me to say I have to update my password because it’s been a month or two since I last did it, I report a security bug to them:

The website has a security flaw: it makes users rotate their passwords periodically. This is against the security controls in NIST Special Publication 800-63B-4, “Digital Identity Guidelines”, section 3.1.1.2, clause 6, which reads:

“6. 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.”

Please fix the website to remove this requirement. Thank you.

If we all do this, maybe it’ll get into their heads that it’s a bad idea to make users change their passwords just for the sake of it.

Feb 1, 2019 ∞

A standard for describing a site's password rules

There’s not a universal standard for what a valid password on a website must look like. Some sites allow you to use any four letters. Others require at least twenty characters, including at least one numeric digit and one “special character” (aka punctuation). Even when using a password manager, the process of creating a good one looks a lot like:

Turn the password manager’s strength settings all the way up and generate a password.
The website replies “passwords can’t be more than 20 characters long”.
Adjust the length down to twenty. Generate a new one and send it to the website.
The website replies “passwords may only contain the special characters ‘$_!#’.
Adjust the number of symbols down to zero. Generate. Try again.
The website replies “passwords must contain at least two special characters”.
Turn the number of symbols back up to two. Click “generate” until you a password that contains punctuation from “$”, “_”, “!”, and “#”, but nothing else. Generate. Try again.
…and repeat until you’ve appeased the website’s rules.

I propose instead that websites should document their password rules in a standardized, machine-readable manner. For instance, suppose that each site hosted a file in a pre-defined location, like /.well-known/password-rules.yaml, in a format such as:

max_length: 64
min_length: 8
allowed_symbols: "$#@!"
min_symbols: 1
min_upper: 1
min_lower: 1
min_digits: 1
matches: "^[a-z]+(.*)+$"

Then tools like 1Password could look for that file and tune their settings to suit. The new process for creating a password would look like:

Tell 1Password to generate a password for the site you’re currently looking at.
It fetches the rules file, interprets it, creates a password that satisfies all the requirements, and pastes it in the password field on the site.

Further suppose that the standard defined the calling conventions of a REST endpoint for changing passwords, and the rules file included that URL like:

change_url: /ajax/change_my_password

Wouldn’t it be just lovely if 1Password could automatically update every such website on a monthly basis, or whenever a site announces a security breach?