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.
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
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).
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.
Don’t bug users to change passwords periodically. Only do it if there’s evidence of compromise.
This is a big one. Especially in corporate environments where most of the users are, shall we say, not tech savvy. Forcing people to comply with byzantine incomprehensible password composition rules plus incessantly insisting that they change their password every 7/14/30 days to a new inscrutable string that looks like somebody sneezed in punctuation marks accomplishes nothing other than enticing everyone to just write their password down on a Post-It and stick it to their monitor or under their keyboard.
Remember: Users do not care about passwords. From the perspective of anyone who isn’t a programmer or a security expert, passwords are just yet another exasperating roadblock some nerd keeps putting in front of them that is preventing them from doing whatever it is they were actually trying to do.
That works great until some dickhole implements the old, “New password cannot contain any sequence from your previous (5) passwords.”
This also of course necessitates storing (multiple successive!) passwords in plain text or with a reversible cipher, which is another stupid move. You’d think we’d have gotten all of this out of our collective system as a society by now, and yet I still see it all the time.
All of these schemes are just security theater, and actively make the system in question less secure while accomplishing nothing other than berating and frustrating its users.
This also leads to stupid rules like you can’t change your password more than once a day, to prevent someone from changing their password 5 times and then changing it back to what it was before.
Only issue I see is that the 8 chars required is very short and easy to brute force. You would hope that people would go for the recommended instead, but doubt it.
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.
I tried that without a password manager for a little while. But then my answers were too abstract to remember, so now I also use a password manager for that.
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.
I think so, based on the original: “Verifiers and CSPs [credential service providers] SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.” With “shall not” being used for hard prohibitions.
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 knows what they’re doing. It’s getting organizations to adapt that’s hard. NIST has recommended against expiring passwords for like a decade already, for example, yet pretty much every IT dept still has passwords expiring at least once a year.
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.
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.
It matters for bcrypt/scrypt. They have a 72 byte limit. Not characters, bytes.
That said, I also think it doesn’t matter much. Reasonable length passphrases that could be covered by the old Latin-1 charset can easily fit in that. If you’re talking about KJC languages, then each character is actually a whole word, and you’re packing a lot of entropy into one character. 72 bytes is already beyond what’s needed for security; it’s diminishing returns at that point.
If the same user can generate the same input, it will result in the same hash.
Yes, if. I don’t know if you can guarantee that. It’s all fun and games as long as you’re doing English. In other languages, you get characters that can be encoded in more than 1 way. User at home has a localized keyboard with a dedicated key for such a character. User travels across the border and has a different language keyboard and uses a different way to create the character. Euro problems.
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.
There is always some son-of-a-removed who doesn’t get the word.
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.
Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.
They might mean well, but the reason we require a special character and number is to ensure the amount of possible characters are increased.
If a website doesn’t enforce it, people are just going to do a password like password
password is a totally valid password under this rule. Any 8 letter word is valid. hopsital for example.
These passwords can be cracked in seconds under 10 minutes, and have their hashes checked for in leaks in no time if the salt is also exposed in the hack.
Edit: Below
Numbers from a calculator with 8 characters using sha2 (ignoring that crackers will try obvious fill ins like 0 for o and words before random characters, this is just for example)
hospital 5m 23s
Hospital 10m 47s
Hospita! 39m 12s
Moving beyond 8
Hospita!r - 19h 49m
Hospita!ro 3w 4d
Hospita!roo 2y 1m
Hospita!room 66 years
The suggestion of multiple random words makes not needing the characters but you have to enforce a longer limit then, not 8.
At least with 11 characters with upper case and special characters if it was all random you get about 2 years after a breach to do something instead of mere weeks. If it was 11 characters all lower case nothing special you’d only get 2 months and we are rarely notified that fast.
They might mean well, but the reason we require a special character and number is to ensure the amount of possible characters are increased.
The problem with this sort of requirement is that most people will solve it the laziest way. In this case, “ah, I can’t use «hospital»? Mkay, «Hospital1» it is! Yay it’s accepted!”. And then there’s zero additional entropy - because the first char still has 26 states, and the additional char has one state.
Someone could of course “solve” this by inserting even further rules, like “you must have at least one number and one capital letter inside the password”, but then you get users annotating the password in a .txt file because it’s too hard to remember where they capitalised it or did their 1337.
Instead just skip all those silly rules. If offline attacks are such a concern, increase the min pass length. Using both lengths provided by the guidelines:
8 chars, mixing:minuscules, capitals, digits, and any 20 special chars of your choice, for a total of 82 states per char. 82⁸ = 2*10¹⁵ states per password.
15 chars, using only minuscules, for a total of 26 states per char. Number of states: 26¹⁵ = 1.7*10²¹ states per password.
Verifiers and CSPs SHALL require passwords to be a minimum of eight characters in length and SHOULD require passwords to be a minimum of 15 characters in length.
I’d they’d just said shall require 15 but not require special chars then that’s okay, but they didn’t.
Then you end up with the typical shitty manager who sees this, and says they recommend 8 and no special chars, and that’s what it becomes.
I don’t think that the entity should be blamed for the shitty manager. Specially given that the document has a full section (appendix A.2) talking about pass length.
The entity knows people will follow what they say for minimums. There’s already someone in the comment section saying they’re now fighting what these lax rules allow.
Edit: stupid product managers will jump at anything that makes it easier for their users and dropping it to 8, no special characters, and no resets is the new thing now.
What you’re proposing is effectively the same as "they should publish inaccurate guidelines that do not actually represent their informed views on the matter, misleading everybody, to pretend that they can prevent the stupid from being stupid." It defeats the very reason why guidelines exist - to guide you towards the optimal approach in a given situation.
And sometimes the optimal approach is not a bigger min length. Convenience and possible vectors of attack play a huge role; if
due to some input specificity, typing out the password is cumbersome, and
there’s no reasonable way to set up a password manager in that device, and
your blocklist of compromised passwords is fairly solid, and
you’re reasonably sure that offline attacks won’t work against you, then
min 8 chars is probably better. Even if that shitty manager, too dumb to understand that he shouldn’t contradict the “SHOULD [NOT]” points without a good reason to do so, screws it up. (He’s likely also violating the “SHALL [NOT]” points, since he used the printed copy of the guidelines as toilet paper.)
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.
That’s the “zero width space,” Alt + 200B for Windows users. Another favorite of mine is the nonbreaking space, Alt + 0160, which a staggering majority of web sites and other systems fail to account for.
gosh who would want an uncommon character that obviously most average people aren’t thinking about in their passwords, that sounds like it might even be somewhat secure.
I’m with you, despite seeing lemmings downvote the heck out of your comment 😢
The reason, and specifically for whitespace at the beginning or end of a password, is that a lot of users copy-paste their passwords into the form, and for various reasons, whitespace can get pasted in, causing an invalid match. No bueno.
Source: I’m a web developer who has seen this enough times that we had to implement a whitespace-trim validation for both setting & entering passwords.
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.
Didn’t know about sha3.
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
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).
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.
This is a big one. Especially in corporate environments where most of the users are, shall we say, not tech savvy. Forcing people to comply with byzantine incomprehensible password composition rules plus incessantly insisting that they change their password every 7/14/30 days to a new inscrutable string that looks like somebody sneezed in punctuation marks accomplishes nothing other than enticing everyone to just write their password down on a Post-It and stick it to their monitor or under their keyboard.
Remember: Users do not care about passwords. From the perspective of anyone who isn’t a programmer or a security expert, passwords are just yet another exasperating roadblock some nerd keeps putting in front of them that is preventing them from doing whatever it is they were actually trying to do.
Everyone I’ve spoken to who has a password change rule just changes one character from their previous password. It does NOTHING.
That works great until some dickhole implements the old, “New password cannot contain any sequence from your previous (5) passwords.”
This also of course necessitates storing (multiple successive!) passwords in plain text or with a reversible cipher, which is another stupid move. You’d think we’d have gotten all of this out of our collective system as a society by now, and yet I still see it all the time.
All of these schemes are just security theater, and actively make the system in question less secure while accomplishing nothing other than berating and frustrating its users.
This also leads to stupid rules like you can’t change your password more than once a day, to prevent someone from changing their password 5 times and then changing it back to what it was before.
HA, I hope you’re joking. Surely nobody’s actually done that, right? …Riiiight?
“I just increment the number at the end” is a phrase I’ve heard so many times
Only issue I see is that the 8 chars required is very short and easy to brute force. You would hope that people would go for the recommended instead, but doubt it.
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.
I tried that without a password manager for a little while. But then my answers were too abstract to remember, so now I also use a password manager for that.
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.”
Sarah Palin had her Yahoo mail account hacked because of those “security” questions. In 2008. We should be well past the time where they are a thing.
Q: What do you often see when you look out your back window?
A: Vladimir Putin riding a horse shirtless.
Hey maybe the GOP got connected with Putin because he was often at Palin’s backyard BBQs when he would ride over to say hi when he saw the gathering.
Though I also just noticed there’s only two letters different between Putin and Palin… Maybe it was just Putin in a wig the whole time.
I think so, based on the original: “Verifiers and CSPs [credential service providers] SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.” With “shall not” being used for hard prohibitions.
NIST knows what they’re doing. It’s getting organizations to adapt that’s hard. NIST has recommended against expiring passwords for like a decade already, for example, yet pretty much every IT dept still has passwords expiring at least once a year.
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.
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.
It matters for bcrypt/scrypt. They have a 72 byte limit. Not characters, bytes.
That said, I also think it doesn’t matter much. Reasonable length passphrases that could be covered by the old Latin-1 charset can easily fit in that. If you’re talking about KJC languages, then each character is actually a whole word, and you’re packing a lot of entropy into one character. 72 bytes is already beyond what’s needed for security; it’s diminishing returns at that point.
Yes, if. I don’t know if you can guarantee that. It’s all fun and games as long as you’re doing English. In other languages, you get characters that can be encoded in more than 1 way. User at home has a localized keyboard with a dedicated key for such a character. User travels across the border and has a different language keyboard and uses a different way to create the character. Euro problems.
https://en.wikipedia.org/wiki/Unicode_equivalence
There is always some son-of-a-removed who doesn’t get the word.
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.
I think it’s pretty idiotic to
They might mean well, but the reason we require a special character and number is to ensure the amount of possible characters are increased.
If a website doesn’t enforce it, people are just going to do a password like password
password is a totally valid password under this rule. Any 8 letter word is valid. hopsital for example.
These passwords can be cracked in
secondsunder 10 minutes, and have their hashes checked for in leaks in no time if the salt is also exposed in the hack.Edit: Below
Numbers from a calculator with 8 characters using sha2 (ignoring that crackers will try obvious fill ins like 0 for o and words before random characters, this is just for example)
hospital 5m 23s
Hospital 10m 47s
Hospita! 39m 12s
Moving beyond 8
Hospita!r - 19h 49m
Hospita!ro 3w 4d
Hospita!roo 2y 1m
Hospita!room 66 years
The suggestion of multiple random words makes not needing the characters but you have to enforce a longer limit then, not 8.
At least with 11 characters with upper case and special characters if it was all random you get about 2 years after a breach to do something instead of mere weeks. If it was 11 characters all lower case nothing special you’d only get 2 months and we are rarely notified that fast.
The problem with this sort of requirement is that most people will solve it the laziest way. In this case, “ah, I can’t use «hospital»? Mkay, «Hospital1» it is! Yay it’s accepted!”. And then there’s zero additional entropy - because the first char still has 26 states, and the additional char has one state.
Someone could of course “solve” this by inserting even further rules, like “you must have at least one number and one capital letter inside the password”, but then you get users annotating the password in a .txt file because it’s too hard to remember where they capitalised it or did their 1337.
Instead just skip all those silly rules. If offline attacks are such a concern, increase the min pass length. Using both lengths provided by the guidelines:
But they mess that up with their 8 char rule
I’d they’d just said shall require 15 but not require special chars then that’s okay, but they didn’t.
Then you end up with the typical shitty manager who sees this, and says they recommend 8 and no special chars, and that’s what it becomes.
I don’t think that the entity should be blamed for the shitty manager. Specially given that the document has a full section (appendix A.2) talking about pass length.
The entity knows people will follow what they say for minimums. There’s already someone in the comment section saying they’re now fighting what these lax rules allow.
Edit: stupid product managers will jump at anything that makes it easier for their users and dropping it to 8, no special characters, and no resets is the new thing now.
What you’re proposing is effectively the same as "they should publish inaccurate guidelines that do not actually represent their informed views on the matter, misleading everybody, to pretend that they can prevent the stupid from being stupid." It defeats the very reason why guidelines exist - to guide you towards the optimal approach in a given situation.
And sometimes the optimal approach is not a bigger min length. Convenience and possible vectors of attack play a huge role; if
min 8 chars is probably better. Even if that shitty manager, too dumb to understand that he shouldn’t contradict the “SHOULD [NOT]” points without a good reason to do so, screws it up. (He’s likely also violating the “SHALL [NOT]” points, since he used the printed copy of the guidelines as toilet paper.)
What kind of barbarian puts a space in their password?
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.
Deleted
Deleted
That’s the “zero width space,” Alt + 200B for Windows users. Another favorite of mine is the nonbreaking space, Alt + 0160, which a staggering majority of web sites and other systems fail to account for.
gosh who would want an uncommon character that obviously most average people aren’t thinking about in their passwords, that sounds like it might even be somewhat secure.
hunter 2unhackable
My passphrase includes several spaces. It’s another character to assist in entropy.
I’m with you, despite seeing lemmings downvote the heck out of your comment 😢
The reason, and specifically for whitespace at the beginning or end of a password, is that a lot of users copy-paste their passwords into the form, and for various reasons, whitespace can get pasted in, causing an invalid match. No bueno.
Source: I’m a web developer who has seen this enough times that we had to implement a whitespace-trim validation for both setting & entering passwords.
Trimming whitespace from the start and end of a password is fine but you absolutely should not remove whitespace from the middle of a password.