Reworded rules for clarity:
- Min required length must be 8 chars (obligatory), but it should be 15 chars (recommended).
- Max length should allow at least 64 chars.
- You should accept all ASCII plus space.
- You should accept Unicode; if doing so, you must count each code as one char.
- Don’t demand composition rules (e.g. “u’re password requires a comma! lol lmao haha” tier idiocy)
- 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.
I hate that anyone has to be told not to truncate passwords. Like even if you haven’t had any training at all, you’d have to be advanced stupid to even come up with that idea in the first place.
Microsoft used to do that. I made a password in the late 90’s for a we service and I found out that it truncated my password when they made it after it warned my my password was too long when I tried to log in. It truncated at 16 characters.
The weirdest one I found was a site that would only check to see if what you entered started with the correct password. So if your password was hunter2 and you tried hunter246, it would let you in.
Which means not only were they storing the password, but they had to go out of their way to use the wrong kind of string comparison.
USAA does this. I renentl learned that, when I updated my password a few years back to my personal standard number of characters, everything was good until someone mentioned this fuck-up in a thread. USAA only checks the first… 16? characters. I assume it just discards anything beyond that. Other users say that it warns and doesn’t let you enter more than that during password creation, but it/my pw mgr sure didn’t care, as I have a password several fold that limit. I took out a couple characters from my ‘set’ password, and it still logged in just fine. 16, just fine. 15, error.
Fucking wild.
I used to work there. I reported this bug every quarter until a VP told me to stop…
Can you elaborate further? Why would someone want to truncate passwords to begin with?
To save a few megabytes of text in a database somewhere. Likely the same database that gets hacked.
Which shouldn’t even matter because passwords are salted and hashed before storing them, so you’re not actually saving anything. At least they better be. If you’re not hashing passwords you’ve got a much bigger problem than low complexity passwords.
The place that truncates passwords is probably not the place to look for best practices when it comes to security. :-)
Hashing passwords isn’t even best practice at this point, it’s the minimally acceptable standard.
What is the best practice currently?
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.
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?
eoY&Z9m4LNRDY!Gzdd%q98LYiBi8Nq
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.”
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 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.
You should accept Unicode; if doing so, you must count each code as one char.
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.
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.
https://en.wikipedia.org/wiki/Unicode_equivalence
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-bitch who doesn’t get the word.
- John F. Kennedy
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
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
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.
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.
But they mess that up with their 8 char rule
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.)
How about making it illegal to block copying and pasting on website forms. I’m literally more likely to make a mistake by typing a routing number than copying and pasting it. The penalty for should be death by firing into the sun to anyone caught implementing any such stupidity.
Frankly I’m mostly annoyed that my browser allows web sites to block cut and paste, ever. I am capable of making my own decisions over whether I want to cut and paste.
There are plugins that will disallow this. I think the one I use is “don’t fuck with paste”
Ooh, ooh. And for implementing any Javascript or jQuery or whatever that pops up some kind of smarmy message when you right click: Believe it or not, straight to jail.
Plus, that kind of thing is not going to prevent anyone from scraping images from anywhere if they have the capability to lift a finger to press F12.
It won’t block it yes but it will diminish the amount of people doing it which is the point
Exactly.
My host decided to update their TOS to force me to accept binding arbitration, so I Inspect Elemented that right off the page and sent a message to support to end my service effective immediately (had been a paying customer for years). You’re not going to bully me on my own browser…
Browsers shouldn’t allow half of the stuff that they allow. You have to do the same thing not just with copy and paste, but also searching on the page with
ctrl + f. Like I don’t care that websites won’t to create their own experience. Don’t mess with browser behavior.You really want to memorise different shortcuts for search? What if you’re on a web app like discord? Ctrl+f isn’t gonna be as useful as a built in search solution that has access to data that isn’t visible until searched for. I get the issues on disabling the features but if they’re replacing browser behaviour with something that suits the site better I think that’s alright as long as it’s not s downgrade.
All too often it is a downgrade though. A lot of those webapps have terrible search and I only want to search for what is on the current page anyways. For example reddit search has been notoriously bad for a long time. Half the forums online seem to be using the exact same open source software with the exact same terrible search. When all too often I just want to find what is on the current page anyways.
Never thought to look for an extension for that. Thanks for mentioning it.
You can also just run it when you need it rather than having to add an extension. Just add a bookmarklet with the code here and just click it when you encounter a problematic website.
It’ll reduce your attack surface while still getting the job done.
https://github.com/jswanner/DontF-WithPaste?tab=readme-ov-file#bookmarklet
Even better, thanks!
It takes way less Delta V to push them into solar escape velocity.
Anger is no excuse to be inefficient with propellant after all
Idk, it might delay the sun imploding a smidge. Or maybe it would accelerate it. Eh, they know what they’re doing…
Don’t forget you save lots of fuel by firing out of the solar system instead
the document is nearly impossible to read all the way through and just as hard to understand fully
It is a boring document but it not impossible to read through, nor understand. The is what compliances officer do. I have a (useless) cybersecurity degree and reading NIST publications is part of my lecture.
It sets both the technical requirements and recommended best practices for determining the validity of methods used to authenticate digital identities online. Organizations that interact with the federal government online are required to be in compliance
My argument is that if this document (and others) are requirements for companies shouldn’t there also be a more approachable document for people to use?
Sure, have the jargon filled document that those in the know can access, but without an additional not so jargon-y document you’ve just added a barrier to change. Maybe just an abstract of the rule changes on the front page without the jargon?
I don’t know, maybe it’s not a big deal to compliance officers but just seems to me (someone that isn’t a compliance officer) that obfuscating the required changes behind jargon and acronyms is going to slow adoption of the changes.
Don’t bug users to change passwords periodically. Only do it if there’s evidence of compromise.
About damn time. I log into my company laptop with a smart card and PIN or a PIN/authenticator code, computer autoconnects to the VPN, and I’m good to go. If there’s no internet available, the smart card will still get me into my computer. If I’m on my personal computer, I log in with the PIN/authenticator. This morning I tried really hard to find someplace where I had the option of entering a password and there is none, yet I have to change my password every 6 months. At least my IT department lets me use KeePass.
Eh, I think they should nag users to change their password proportional to how “strong” their password is. If you’re barely meeting the minimum: reset every few months. If you’re using a proper passphrase dozens of characters long: only reset if there’s evidence of compromise.
One thing they should change is the word “password.” This implies that it’s a short string. Changing it to “passphrase” will help people feel comfortable choosing credentials like “correct horse battery staple.”
I recently set up a password with a 16 character max, alphanumeric only, no spaces. The service is in no way a security threat but still.
A couple years ago I ran into one with a 12 character limit…
I never understood password limits, other than something sufficiently large like 256 to prevent DOS. It’s not like the password is actually being stored anywhere… right? RIGHT??
Meanwhile, my company has systems insisting on expiring ssh keys after 90 days…
Fools! You have to expire the whole system!
Reinstall everything every 90 days. It’s the only way.
You are going to give them ideas…
Ironically, reinstall the whole system, make sure to add some CrowdStrike, SolarWinds, and Ivanti for security and management though…
My company blocked ssh keys in favour of password + 2FA. Honestly I don’t mind the 2FA since we use yubikeys, but wouldn’t ssh key + 2FA be better?
All well and good when ssh activity is anchored in a human doing interactive stuff, but not as helpful when there’s a lot of headless automation that has to get from point a to point b.
Yep. All the headless automation broke…
You heard it: stop imposing composition rules!
i had to login for some functions at work. i believe the minimums were 8 characters, 1 caapitol, 1 number. and we all hated it, because the passwords had to be changed every 90 days, and you couldn’t reuse passwords. eventually you are going to run out of things you can reasonably use that you could remember and then would be forced to use some sort of password manager. but OOPSIE you couldn’t install any software on the office computer so you would have to resort to writing them down somewhere. it was a mess.
fortunately corporate decided to just change the entire system adopting most of these rules, min 15 characters, no special character, no hints, no forced changing passwords unless you think you have been compromised or just want to change it. we do have to use 2fa to access some things if you aren’t sitting at the office computer but other than that people are much happier about passwords now.
Deleted
I would always just create 1 password and append a number and it’s special char, cycling from 1 to 0; like
1!,2@,3. Never stayed at a place long enough to go higher than 7 or 8.I never gave a fuck about doing this because it’s the companies fault for applying stupid policies. Whenever I’ve been allowed a password manager, they got real security instead of malicious compliance.
Stockholm1 (capitol)
90 days later:
Stockholm2
All this 2FA, SSH, token / key stuff is garbage. Rectal vascular mapping is the only legitimate security option.
“Please insert your webcam.”
Now this is security I can get behind! Err, in front of?
It took me a moment to notice those weren’t specifically security terms…
I have one in my house! 🏡 Just reverse into it and Viola! The door opens! Works for the ref too! Hands free baby!
The app my work uses to show 401k, pay, request leave, etc details, uses a ridiculous webapp that’s very slow, and on top of this, they nag you literally every 4 months to update your password. I used to be a good boy and memorize a new password each time. Now I just add a new letter into BitWarden and it’s my new password. Apparently this is more secure??
I just add 1 to the number at the end of my password every time they force a change.
I’m on 18 right now.
My favorite are some of the work systems that I need to access, but only infrequently, yet still have ridiculous password expiration rules. Nearly every time I log in, before I can access the system I have to change my password because of course it’s expired again. So I change the password, write it down because I’ll never remember it months from now when I need to use that password exactly once to login and change my password yet again.
At roughly 35,000 words and filled with jargon and bureaucratic terms, the document is nearly impossible to read all the way through and just as hard to understand fully.
A section devoted to passwords injects a large helping of badly needed common sense practices that challenge common policies. An example: The new rules bar the requirement that end users periodically change their passwords. This requirement came into being decades ago when password security was poorly understood, and it was common for people to choose common names, dictionary words, and other secrets that were easily guessed.
Since then, most services require the use of stronger passwords made up of randomly generated characters or phrases. When passwords are chosen properly, the requirement to periodically change them, typically every one to three months, can actually diminish security because the added burden incentivizes weaker passwords that are easier for people to set and remember.
A.k.a use a password manager for most things and a couple of long complex passwords for things that a password manager wouldn’t work for (the password manager’s password, encrypted system partitions, etc). I’m assuming In just summed up 35,000 words.
deleted by creator
Please ban all the stupid password rules.
Yes.
I would rather just get hacked […]
Eh, no.
