Don’t bug users to change passwords periodically. Only do it if there’s evidence of compromise.
Don’t store password hints that others can guess.
Don’t prompt the user to use knowledge-based authentication.
Don’t truncate passwords for verification.
I was expecting idiotic rules screaming “bureaucratic muppets don’t know what they’re legislating on”, but instead what I’m seeing is surprisingly sane and sensible.
NIST generally knows what they’re doing. Want to overwrite a hard drive securely? NIST 800-88 has you covered. Need a competition for a new block cipher? NIST ran that and AES came out of it. Same for a new hash with SHA3.
I think if you do allow 8 character passwords the only stipulation is that you check it against known compromised password lists. Again, pretty reasonable.
That stipulation goes rather close to #5, even not being a composition rule. EDIT: see below.
I think that a better approach is to follow the recommended min length (15 chars), unless there are good reasons to lower it and you’re reasonably sure that your delay between failed password attempts works flawlessly.
EDIT: as I was re-reading the original, I found the relevant excerpt:
If the CSP [credential service provider] disallows a chosen password because it is on a blocklist of commonly used, expected, or compromised values (see Sec. 3.1.1.2), the subscriber SHALL be required to choose a different password. Other complexity requirements for passwords SHALL NOT be imposed. A rationale for this is presented in Appendix A, Strength of Passwords.
So they are requiring CSPs to do what you said, and check it against a list of compromised passwords. However they aren’t associating it with password length; on that, the Appendix 2 basically says that min length depends on the threat model being addressed; as in, if it’s just some muppet trying passwords online versus trying it offline.
It’s crazy that they didn’t include all the “should” items in that list. If you read the entire section, there’s a critical element that’s missing in the list, which is that new passwords should be checked against blocklists. Otherwise, if you combine 1, 5, and 6, you end up with people using “password” as their password, and keeping that forever. Really, really poor organization on their part. I’m already fighting this at work.
Very common for pass phrases, and not dissuaded. Pass phrases are good for people to remember without using poor storage practices (post it notes, txt file, etc) and are strong enough to keep secure against brute force attacks or just guessing based off knowledge of the user.
On one hand, that’s true. On the other hand, a person should only need exactly one passphrase, which is the one used to unlock their password manager. Every other password should be randomly-generated and would only contain space characters by chance.
That’s great in theory, but you’ll have passwords for logging into OSes too which password managers do not help with and you better have it memorized or you’re going to have a bad time.
Yeah, I think 7 and 8 both cover that. I recently signed up for an account where all of the “security questions” provided asked about things that could be either looked up or reasonably guessed based on looked up information.
We live in a tech world designed for the technically illiterate.
I usually invent answers to those and store those answers in a password manager. Essentially turns them into backup passwords that can be spoken over the phone if necessary.
Oh old eoY&Z9m4LNRDY!Gzdd%q98LYiBi8Nq and I go way back! I met eoY&Z9m4LNRDY!Gzdd%q98LYiBi8Nq in Pre-K and we’ve been inseparable ever since.
It is quite annoying if they’re a service that makes you read aloud your security questions to phone reps to prove your identity. One of my retirement accounts requires that and I have to sigh and read out the full string. I’ve changed it since to an all lowercase, 20 digit string as a compromise.
It needed to be said. Because some password system architects have been just that stupid.
Edit: Fear of other’s stupidity is the mind killer. I will face my fear. My fear will wash over me, and when it has passed, only I will remain. Or I’ll be dead in a car accident caused by an AI driver.
I’ve seen sites truncate when setting, but not on checking. So you set a password on a site with no stated limit, go to use said password, and get locked out. It’s infuriating
Another ridiculous policy I’ve seen (many years ago) is logging in too fast. I used to get locked out of my banks website all the time and I used autotype with KeePass so I was baffled when it wouldn’t get accepted. Eventually I had a thought to slow down the typing mechanism and suddenly I didn’t get locked out anymore.
Years back, I had that happen on PayPal of all websites. Their account creation and reset pages silently and automatically truncated my password to 16 chars or something before hashing, but the actual login page didn’t, so the password didn’t work at all unless I backspaced it to the character limit. I forgot how I even found that out but it was a very frustrating few hours.
Banks usually have the absolute worst password policies. It’s typically because their backend is some crusty mainframe from the 80s that limits inputs to something absurdly insecure by today’s standards and they’ve kicked the upgrade can down the road for so long now that it’s a staggeringly monumental task to rewrite it all. Thankfully most of them have upgraded at this point, but every now and then you still find one that’s got ridiculous limits like a maximum password length of 8 and only alphanumeric characters (with no 2FA obviously).
Who cares? It’s going to be hashed anyway. If the same user can generate the same input, it will result in the same hash. If another user can’t generate the same input, well, that’s really rather the point. And I can’t think of a single backend, language, or framework that doesn’t treat a single Unicode character as one character. Byte length of the character is irrelevant as long as you’re not doing something ridiculous like intentionally parsing your input in binary and blithely assuming that every character must be 8 bits in length.
Reworded rules for clarity:
I was expecting idiotic rules screaming “bureaucratic muppets don’t know what they’re legislating on”, but instead what I’m seeing is surprisingly sane and sensible.
NIST generally knows what they’re doing. Want to overwrite a hard drive securely? NIST 800-88 has you covered. Need a competition for a new block cipher? NIST ran that and AES came out of it. Same for a new hash with SHA3.
For now, at least. Could change after Inauguration Day.
I think if you do allow 8 character passwords the only stipulation is that you check it against known compromised password lists. Again, pretty reasonable.
That stipulation goes rather close to #5, even not being a composition rule.EDIT: see below.I think that a better approach is to follow the recommended min length (15 chars), unless there are good reasons to lower it and you’re reasonably sure that your delay between failed password attempts works flawlessly.
EDIT: as I was re-reading the original, I found the relevant excerpt:
So they are requiring CSPs to do what you said, and check it against a list of compromised passwords. However they aren’t associating it with password length; on that, the Appendix 2 basically says that min length depends on the threat model being addressed; as in, if it’s just some muppet trying passwords online versus trying it offline.
It’s crazy that they didn’t include all the “should” items in that list. If you read the entire section, there’s a critical element that’s missing in the list, which is that new passwords should be checked against blocklists. Otherwise, if you combine 1, 5, and 6, you end up with people using “password” as their password, and keeping that forever. Really, really poor organization on their part. I’m already fighting this at work.
What kind of barbarian puts a space in their password?
Deleted
Deleted
Very common for pass phrases, and not dissuaded. Pass phrases are good for people to remember without using poor storage practices (post it notes, txt file, etc) and are strong enough to keep secure against brute force attacks or just guessing based off knowledge of the user.
On one hand, that’s true. On the other hand, a person should only need exactly one passphrase, which is the one used to unlock their password manager. Every other password should be randomly-generated and would only contain space characters by chance.
That’s great in theory, but you’ll have passwords for logging into OSes too which password managers do not help with and you better have it memorized or you’re going to have a bad time.
re #7, I hope they are also saying no ‘secret questions’ to reset the password?
Yeah, I think 7 and 8 both cover that. I recently signed up for an account where all of the “security questions” provided asked about things that could be either looked up or reasonably guessed based on looked up information.
We live in a tech world designed for the technically illiterate.
I usually invent answers to those and store those answers in a password manager. Essentially turns them into backup passwords that can be spoken over the phone if necessary.
Where was I born? “Stallheim, EUSA, Mars”
Name of first pet? “Groovy Tuesday”
It’s fun, usually.
What is the first name of your first best friend?
Oh old eoY&Z9m4LNRDY!Gzdd%q98LYiBi8Nq and I go way back! I met eoY&Z9m4LNRDY!Gzdd%q98LYiBi8Nq in Pre-K and we’ve been inseparable ever since.
It is quite annoying if they’re a service that makes you read aloud your security questions to phone reps to prove your identity. One of my retirement accounts requires that and I have to sigh and read out the full string. I’ve changed it since to an all lowercase, 20 digit string as a compromise.
20 character all lowercase is very secure as long as its random words / letters that would make it unguessable by knowing you.
Edit: you could also prefix it if you think you’d have to read it
“This question is stupid fuck nuts house gravel neptune cow.”
It needed to be said. Because some password system architects have been just that stupid.
Edit: Fear of other’s stupidity is the mind killer. I will face my fear. My fear will wash over me, and when it has passed, only I will remain. Or I’ll be dead in a car accident caused by an AI driver.
I’ve seen sites truncate when setting, but not on checking. So you set a password on a site with no stated limit, go to use said password, and get locked out. It’s infuriating
Another ridiculous policy I’ve seen (many years ago) is logging in too fast. I used to get locked out of my banks website all the time and I used autotype with KeePass so I was baffled when it wouldn’t get accepted. Eventually I had a thought to slow down the typing mechanism and suddenly I didn’t get locked out anymore.
Years back, I had that happen on PayPal of all websites. Their account creation and reset pages silently and automatically truncated my password to 16 chars or something before hashing, but the actual login page didn’t, so the password didn’t work at all unless I backspaced it to the character limit. I forgot how I even found that out but it was a very frustrating few hours.
Sounds like my bank.
Banks usually have the absolute worst password policies. It’s typically because their backend is some crusty mainframe from the 80s that limits inputs to something absurdly insecure by today’s standards and they’ve kicked the upgrade can down the road for so long now that it’s a staggeringly monumental task to rewrite it all. Thankfully most of them have upgraded at this point, but every now and then you still find one that’s got ridiculous limits like a maximum password length of 8 and only alphanumeric characters (with no 2FA obviously).
Hmm. I wonder about this one. Different ways to encode the same character. Different ways to calculate the length. No obvious max byte size.
Who cares? It’s going to be hashed anyway. If the same user can generate the same input, it will result in the same hash. If another user can’t generate the same input, well, that’s really rather the point. And I can’t think of a single backend, language, or framework that doesn’t treat a single Unicode character as one character. Byte length of the character is irrelevant as long as you’re not doing something ridiculous like intentionally parsing your input in binary and blithely assuming that every character must be 8 bits in length.