Before the change : https://pages.nist.gov/800-63-3/sp800-63b.html

"Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. "

After the change: https://pages.nist.gov/800-63-4/sp800-63b.html

"Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords."

So advice to requirement for this part, which is great!

> SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)

Are there employers that follow this advice? Mine won't (and won't say why).

It seems it’s been upgraded to SHALL NOT this year.

NCSC has advised against arbitrary forced password changes since 2015 https://www.ncsc.gov.uk/blog-post/problems-forcing-regular-p... - one day we might see this practice gone

> Also worth pointing out that NIST doesn't set policy…

Which has a side effect of NIST not even following its own guidance!

I had one today that said my password must be between 6 and 20 characters. I had entered a generated 16 character password.

Generated another 16 character password, alphanumeric-only this time, and it worked.

If you're going to have forbidden characters, MAKE SURE YOU TELL ME WHAT THEY ARE!!!

A good password

- Must be likely to enter correctly on the first attempt, on a bad mobile keyboard, or using a TV remote.

- Must be likely to be remembered in my stupid brain even if I haven't used it for many years. Must work even on places

where you can't use a password manager (Such as a smart TV, games console, ...) Other less important requirements to me, in 99% of cases:

- It's hard to guess for someone else, unless it's an account where you mind someone guessing it.

The last point is key. I have thousands of accounts. And I care about people not breaking into maybe 4 of them.

I don't trust sites to have good lost password ("email login") flows. So for 90% of sites and services I use a password that is a) as simple as possible and b) as common as possible so I don't have to remember many. Yes I AM a developer. Yes I DO use a password manager. But I don't know whether I'll be able to use my password manager when I sign into a specific account next time. It's more likely than not that it ends up being on a smart TV or whatever. So I just use a stupidly simple password. Because for almost all sites, I don't mind it being guessed. Worst case I'll need to reset it. Or worst case someone starts a support request in my name at Logitech, or someone screws with my Netflix viewing history or whatever. But I don't care. Or rather, I care much less than I care about not being frustrated when desperately logging in via a TV remote 3 minutes after the game has started.

I guard the important accounts with 2FA (especially the mail account that in turn resets ALL these other poorly protected accounts!). But for 99% of stores, forums, services: I use the equivalent of "12345" as password. (really I use a small prefix word + the service name 'initials' as suffix and end with an exclamation mark to pass most password demands).

Years ago I worked in a Wells Fargo call center that had all the usual requirements including forced monthly rotation that had to be significantly different than the prior one.

Guess what the most common thing written on a post-it note on a monitor in somebody's cube was?

This was an outbound call center doing credit investigations, processing huge piles of PII and financial information daily.

I'm so glad to see this farce done away with.

And no white space characters. That one makes me want to hurl obsceneties until the author’s eyes pop out. Goddamned amateurs.

I wonder how well those correlate with poor password storage security practices (plaintext, lack of salt, lack of encryption, etc.)

The most offensive are the ones where it says "your password is not safe" but don't tell what the problem is!

The absolute worst I ever encountered was the Mojang to Microsoft account migrator. The only thing I ever found it accepted was one of those indecipherable browser generated passwords unfit for human entry or memory. Ofc the rules were never stated, so you just had to guess.

I had a website keep rejecting my registration at checkout, and Customer Support explained that I was tripping the bot filter for my password being too random. I had to introduce them to the concept of password managers, in 2020. It's a wild world out there.

Why are you so happy about?! Those devs will continue to not know what a good password is. It's not like a new standard will telepathically transplant itself into their brains.

It drives me absolutely crazy that the same bank website that times out my session after 5 minutes of inactivity insists that I set up recovery questions from a list that all amount to what is typically public information. I just save these as random values in extra fields in my password manager, but it's a ridiculous exercise for a website that thinks it's important enough to time out the session.

It is ZD4Fbyed6fzoUcmi.

I just treat those as another password input that I save in my password manager (e.g. Bitwarden).

Recently I had to change a password for my utility provider. One of the options for a security question was, not kidding, What is your favorite security question?

I'm fine with the questions, because I never give the real answer.

These password guidelines were the state of the art at the time they were popularised. It really only becomes obvious why they’re bad when you observe the knock on behaviours they encourage, and even then the only way to make them not bad is with the use of modern tooling like password managers.

The world has been rather slow to move off this standard, but NIST has been a huge enabler of that, so I don’t think they deserve any hate for this. Not too long ago the NIST password guidance was THE authority that enabled regulated companies (like PCI companies) to migrate off password complexity requirements with a compensating control.

There’s plenty of other toxic security ideas out there as well. I would argue any control that generates large amounts of user friction for a negligible security benefit is probably a net downgrade in security posture, as user friction just normalises a culture of circumvention. Hopefully authorities like NIST can lead the way in tackling many of those as well.

My suspicion is this to rule out a specific hash. One well known to everyone interested in computer security back in the 1990's. One that haunts our nightmares to this day.

Back in my day, you see, there was this hash known as NTLM, which actually took your password and stored and then matched it in two ways, the NT hash (MD5 of your password in UTF-16) and the LM hash (split the first 14 bytes of your password in ASCII, then add parity bits and use that as a DES key to encrypt a well-known string). That LM hash was because they wanted it to be backwards compatible with Microsoft LanMan, introduced for OS/2 back in 1987. Even back in the 1990's it was a well known weak link, and given how trivial it is today to brute force a match for MD5 (since all characters after the first 14 can be arbitrary), you can see that this is simple to brute force with modern computing power. Microsoft has recommended NTLM not be used since 2010, but it's still in Windows for backwards compatibility reasons, and there are almost certainly still servers running today that a NTLM hash could get you access to. So that's my guess as to what they are targeting.

It predates bcrypt by quite a bit - descrypt would truncate password at 8 characters (or technically 8 bytes) and was used on a lot of older Linux and *NIX systems.

Ran into this exact issue on a project. The developer that implemented the solution wanted to make sure that we handled those 6 digit PINs in the most secure way with salt and pepper and bcrypt, and at the end of the day the system only actually checked the first two digits of the PIN because bcrypt ignored the rest.

Does this permit taking a sha 512 digest hash of the user input and returning that digest hash to the backend for proper password hashing?

My interpretation is that the entire password is being verified, even though the backend is only ever verifying a sha 512 digest hash of it.

(Oh and why would you do this? To be able to support arbitrary length passwords without opening yourself up to ddos attacks. Support as long passwords as the user wants - only the digest hash is sent.)

Still a problem irrespective of algorithms used. I recently set up an account on a website, letting my password manager do its thing. Couldn’t log in. Turns out the password was too long (20 chars when 16 were allowed) and was silently truncated during signup.

The login form of course used the entirety of the password, not truncating it. Fun stuff.

Perhaps old stuff like LM/NTLM:

- https://en.wikipedia.org/wiki/LAN_Manager#LM_hash_details

- https://en.wikipedia.org/wiki/NTLM

I also misread this requirement the first time, but it's "at least", i.e. they are encouraging as high as possible, but suggesting that the "minimum" max length should be 64 characters.

Just signed up for Discover credit card online access the other day, and they wanted a symbol in the username. I think their nags also said to change your username often. Like oof, the cargo cult gets its own cargo cult.

They've been working on just this bit for the better part of a decade. It'll happen (passkeys I imagine), just slower than most of us would like.

Mandatory game for those who managed not to see it already: https://neal.fun/password-game/

Not without losing a lot, for most applications.

For an additional attack vector of people spying on screens?

Having password masked makes sense by default, but I agree users should be able to see passwords explicitly by tapping an "eye" icon.

Who is typing passwords these days?

> max 64 chars “should” requirement? vs. no truncation?*

There kind of needs to be a truncation at some point. Otherwise there is a risk of an attacker triggering a denial-of-service attack by sending multi-gigabyte passwords.

This! Required frequent changes just makes people who don't use password managers choose weaker passwords to be able to remember them easily. And they'll almost guaranteed just choose the same password as before with a new post or prefix. "mychildhoodteacher1", "mychildhoodteacher2", etc.

It would be better to encourage users to use a single random four word passphrase and stick to that forever. Add 2FA and you are golden. But legacy systems gonna legacy. I still see systems with max password lengths of 12 characters in the wild, and no 2FA to boot. It's been a while since I got my password back in clear text though, so perhaps we're moving in the right direction.

Yep. The bit about not doing mandatory periodic password resets has been in these recommendations for a while, but most companies I hear about still require them.