7 ms·
NIST to forbid requirement of specific passwords character composition
- bediger4000 2y agoFinally! A best practice that makes sense! Now let us see the password as we "type" on rinky dink cell phone virtual keyboards!
- can16358p 2y agoFor 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.
- bowmessage 2y agoWho is typing passwords these days?
- pjmlp 2y agoThe munggles, the large majority of them. And those of us unfortunate to use applications that forbid copy-paste on password fields.
- f1shy 2y agoThat is yet another point that they should have taken...
- makach 2y agoEveryone? Just consider your mobile phone when doing anything that requires some sort of security elevation.
- adastra22 2y agoIf you're following NIST best practices, you're using a password manager instead.
- nixosbestos 2y agoMy passwords are 30 characters of gibberish. I'd yeet my phone before typing a password on it. Not to mention, the obvious.
- justinclift 2y agoEveryone on sites that forbid pasting into the password field. (!)
- schoen 2y ago"Your password validation rule must not contain a 'your password must contain a'"?
- febusravenga 2y agoMandatory game for those who managed not to see it already: https://neal.fun/password-game/ https://neal.fun/password-game/
- acchow 2y ago"your password is on fire!!"
- hsdropout 2y agoThis has been in their guidance since at least 2017. "Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator" https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S... Also worth pointing out that NIST doesn't set policy, so unfortunately this doesn't directly "forbid" anything, though many other policies reference 800-63.
- sophiebits 2y agoIt seems it’s been upgraded to SHALL NOT this year.
- hsdropout 2y agoAha good point, my bad.
- cheriot 2y ago> 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).
- briandear 2y agoIt’s because the CIO or whomever is running the show is a relic from the 1990s. I can tell a lot about a company by their password policies. There also seems to a direct correlation to silly password and “security” policies and the usage of Microsoft products such as Teams and Outlook.
- mschuster91 2y ago> It’s because the CIO or whomever is running the show is a relic from the 1990s. More often, it's because the "cybersecurity insurance" is a shitshow. When you as a CIO deviate from their requirements and get 0wned, you're getting stuck with the bill.
- askvictor 2y agoAlso forbids 'security questions' e.g. "What is your mother's maiden name?"
- tomalaci 2y agoIt is ZD4Fbyed6fzoUcmi. I just treat those as another password input that I save in my password manager (e.g. Bitwarden).
- Strom 2y agoSuch answers are weak when verified by customer support. An attcker can try saying oh I just entered a bunch of random letters, I didn’t think I’d need to remember it and an unsuspecting non—security-expert customer service rep confirms the answer as accurate.
- db48x 2y agoYep, you pretty much have to enter a name when the question asks for a name. Doesn't actually have to be your mother's maiden name or whatever though.
- alserio 2y agoThen my mother maiden name is "I use a password manager: match this EXACT random value [adequately long random value]". Fortunately, I'm rarely seeing this pattern nowadays.
- throwaway984393 2y agoToo bad it won't get adopted by existing systems. I know huge companies still doing mandatory frequent password changes despite us telling them it goes against NIST for years.
- kelnos 2y agoYep. 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.
- JimDabell 2y agoI still see bullshit like this from pen testers, who really should know better.
- _dain_ 2y agoWho? Name and shame them.
- JimDabell 2y agoQuite honestly, I can’t think of any that don’t give bad advice on passwords. It seems to be pretty universal that they aren’t aware of best practice and cargo-cult the bullshit instead.
- JambalayaJimbo 2y agoA lot of pen testing companies are glorified but box checkers. I’ve submitted many applications with glaring security holes in them to pen testing and never heard a peep.
- snorremd 2y agoThis! 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.
- adgjlsfhk1 2y agoalso raises the suggested max password length to a much more reasonable 64 (many sites have a max of 20 that makes passphrases impossible)
- danpalmer 2y agoI 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.
- beej71 2y agoI don't get the max length restrictions some sites have. Why?
- BenjiWiebe 2y agoYou could have a reasonable length limit (1kb maybe?) so you don't spend too much CPU time hashing the password.
- kouteiheika 2y agoThat's what you gotta do when you store your passwords in plaintext and the password column in your DB is capped at a certain length.
- tetha 2y agoPersonally, I'm worried about the CPU of my application servers if a cost-oriented hash function has to process your 4GB large password. Though imagine how much clout we could get from all the bogus DoS CVEs this could find. But jest aside, imo there should be a maximum limit to avoid possible nonsense, but that limit should be at 1k - 2k characters or something outlandish.
- mnw21cam 2y agoI don't think the compute time varies that much with the length of the password being hashed for these cost-oriented hash functions.
- deleted 2y ago[deleted]
- mndgs 2y agoFINALLY. Good God, how annoying those website signups with "a good password must use a, b and c" are... It seems a lot of site devs know shit about what a good password is.
- M95D 2y agoWhy 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.
- TeMPOraL 2y agoUncaring devs will stay uncaring, but I feel the bigger problem is still corporate. NIST recommendations carry little weight with corporate IT security. Certifications, compliance, and insurance do - so little will change until the revised recommendation works its way through the entire mutual appreciation society of audit agencies, "cyber" insurance providers, industry certification bodies, certification consultants, and a whole mud ball of enterprise middleware companies. I mean, take Microsoft ecosystem (Windows, SharePoint, Exchange, and other auth infra): it never had any bullshit password policies enabled by default - but every corporate Windows machine has them, because someone in corporate IT is setting it as central policy, and they're doing it because they "know better", or because the company is trying to get/keep their ISO:2007-whatever SOC2 stamp (or trying to secure a deal with another company that is), and some consultant came up the other day with a questionnaire asking if corporate systems are Secure, by for example implementing Specific Bullshit Policy. Easier to implement it and call it a day, than to contest every other checkbox on the questionnaire...
- hinkley 2y agoAnd no white space characters. That one makes me want to hurl obsceneties until the author’s eyes pop out. Goddamned amateurs.
- BenjiWiebe 2y agoI 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!!!
- makach 2y agoThe requirements could be even more clearer * max 64 chars “should” requirement? vs. no truncation? * what about pin-codes? * the password process is still very much a hot mess, standardize registration, IIA, updating, cancellation * protection of passwords at-rest, salt your passwords
- phire 2y ago> 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.
- tsimionescu 2y agoTruncation means accepting the long password, but only looking at the first N chars. It is never acceptable. Max length requirements are absolutely required, but they must be enforced by refusing the password, not by truncating.
- matrss 2y agoThere definitely doesn't need to be truncation. A upper limit yes, to avoid the potential for DoS, but no truncation. That limit should be reasonably large, 1000 characters or something maybe. I've seen a service whose registration form accepted my 64 characters long randomly generated password, but then the login form apparently truncated the password to something smaller, silently, and just said my password was incorrect. I then had to guess what was happening and reset my password to something shorter, which worked. If you must have a stupid password policy at least make it explicit (well, and consistent).
- fallous 2y agoGreat, NIST put out objectively bad password guidance for a couple of decades and then decides to change it to a more sane solution. Too bad a GIANT swath of password-protected software was built on their prior incompetent guidance and will take decades for all of that software to change... if they change at all.
- AmericanChopper 2y agoThese 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.
- PoachedEggs 2y ago> probably a net downgrade in security posture, as user friction just normalises a culture of circumvention There is even a CWE for this concept: “CWE-655: Insufficient Psychological Acceptability” > The product has a protection mechanism that is too difficult or inconvenient to use, encouraging non-malicious users to disable or bypass the mechanism, whether by accident or on purpose.
- AmericanChopper 2y agoHah, how interesting. I can’t believe I’ve never seen that one before.
- benatkin 2y agoThat enables passphrases! accurate donkey charger glue
- lofaszvanitt 2y agoCan't we just leave passwords behind once and for all...
- tsimionescu 2y agoNot without losing a lot, for most applications.
- wtcactus 2y agoThank God. I’ve been noticing this downward spiral for more than a decade now. It’s becoming unmanageable to use authentication. It’s MFA, passwords and passkeys in multiple forms. I have to reach several times a day for the phone to get yet another MFA from the Authenticator or SMS to login the same site I’ve used yesterday. Constant nagging for “security“ from everywhere, and on top of these, these unproductive password changes requests described in the article. I been thinking about it the last months, and we really need a paradigm shift when it comes to authentication. I’m not knowledgeable enough to know what, but I can see the problem pilling up in front of my own eyes.
- dguest 2y agoDirect link to source https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver
- jand 2y ago> 9 Verifiers SHALL verify the entire submitted password... Is this "don't microwave your hamster"-requirement a result of the bcrypt trouble [1] or how comes? [1] https://security.stackexchange.com/questions/39849/does-bcrypt-have-a-maximum-password-length https://security.stackexchange.com/questions/39849/does-bcry...
- entuno 2y agoIt 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.
- hashmush 2y agoPerhaps old stuff like LM/NTLM: - https://en.wikipedia.org/wiki/LAN_Manager#LM_hash_details https://en.wikipedia.org/wiki/LAN_Manager#LM_hash_details - https://en.wikipedia.org/wiki/NTLM https://en.wikipedia.org/wiki/NTLM
- nielssp 2y agoRan 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.
- mandevil 2y agoMy 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.
- nottorp 2y agoLittle story: My wife's bank was using a numeric id as the login until last month. They had token based and then app based codes instead of passwords, which was decent. This month they forced her to pick an user name instead of the numeric code to login. They required her to have at least one capital letter and a number. In the user. According to Gemini it's the 8th largest European bank :)
- mindslight 2y agoJust signed up for Discover credit card online access the other day, and they wanted a number and 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.
- anilakar 2y agoI'm still waiting for NIST to deprecate plain-text* passwords in favor of PAKE, and W3C to come up with a mechanism for that. *) plain-text here means any and all methods that give the attacker access to the original password, including modifying client-side JS.
- gazby 2y agoThey'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.
- GoblinSlayer 2y agoAdoption of PAKE was hampered by patents. Password managers solve the problem anyway.
- deleted 2y ago[deleted]
- Sammi 2y agoSo the argument of whether this increases or decreases entropy goes both ways: 1. Requiring certain characters is a limit on which characters are selected. An attacker now knows to look for at least one digit, upper case char, and one of 10 special chars. This is a smaller selection of characters than the whole of all characters that were available before, so it decreases entropy. 2. Most users choose weak simple passwords with low entropy. Requiring users to use some characters that they wouldn't otherwise increases the entropy as it increases the selection of characters in the password. I actually don't believe 2, as most users will just start with an upper case char and end with 1!, so the entropy will still decrease for most users, as they will choose easily guessable placements for these required chars.