NIST to forbid requirement of specific passwords character composition
mastodon.social
mastodon.social
"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.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.
"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!
Are there employers that follow this advice? Mine won't (and won't say why).
These days I work in tertiary education, so there's a complete spectrum from people who probably have memorised a unique sixteen alphanumerics password twenty years ago to folks who needed a service desk worker to help them walk through resetting after having forgotten their password was the name of one of Henry VIII's wives. And there's likewise a spectrum between "I hand-built this optical splitter and splice so that I could steal the exam answers without any trace on the network" and "I wrote the formulae on my thigh in permanent marker and then wore a skirt with a big slit down one side" in terms of the technical sophistication of attacks.
Edited to add: When I did work for the CRA with the rotation rule I would write down each of the passwords in columns in the back of my log book since otherwise I might forget one and that was a huge pain to get reset, it's just not realistic to memorize "random" values you'll have to replace frequently. And of course they had two "Single" Sign On systems because of warring management, so that's two passwords to rotate.
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.
The last time I worked anywhere with periodic password change was 8 years ago and they were phasing it out. The same place would reset your password to Monday123 if you got locked out (whether you needed a password reset or not) and forget to set the "force change" flag.
About 18 months after me raising this issue and referencing both NCSC and NIST, the rules at the org I'm contracting with were changed.
I have no idea whether my suggestion made any difference.
> Covered entities must train all users and establish
> guidelines for creating passwords and changing them
> during periodic change cycles.
Frequent changes mean more people write them down.
Which has a side effect of NIST not even following its own guidance!
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!!!
The other message I get from sites like this is, “Our developers have no idea how to escape SQL parameters even though this has been standard since the 90s [80s? 70s?!] so we just do “‘“ + password + “‘“ “
https://symbl.cc/en/unicode-table/
Just scrooooool...
- 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).
I just open my password manager on my phone and type it in. On these passwords, I am likely to avoid special characters, since they are a pain to type on these 'keyboards'
Surprised it's not a default option for modern password managers, to be honest.
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.
No need to write any of them down! Work smarter, not harder: WelcomeDecember2023! -> WelcomeJanuary2024! -> WelcomeFebruary2024! -> WelcomeMay2024! -> ...
(don't do this, obviously)
The funniest password sticky note I've seen was someone whose password was the name of their child and their birth year. Not a great password in general, but apparently they didn't know their kid very well because they had to write it down and stick it onto their monitor.
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...
Unfortunately that opens you open to a social engineering attack, 9 times out of 10 if you call the helpdesk for a password reset and they ask you the questions and you answer "some random junk I don't remember" they'll reset it for you..
(I'm sure a determined enough attacker will eventually find an agent willing to accept the former excuse, but if it reaches that point, I think I've already lost this battle.)
Which involves you speaking a pin over an ordinary insecure phone call.
> ordinary insecure phone call
I just treat those as another password input that I save in my password manager (e.g. Bitwarden).
I use a password manI till use random security questions though, better than the alternative.
One time I was trying to set up a security question and it kept saying the info doesn't match their records and it seemed they were actually validating against public records. How friggin stupid.
Agent: "I'll need to ask for a few details first. What was your first pet's name?"
Me: "ZD4Fbyed6fzoUcmi"
Agent: "Thank you."
So I suppose my answer would have to be "This one".
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.
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.
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-bcry...
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.
The login form of course used the entirety of the password, not truncating it. Fun stuff.
It also doesn't sanitise or warn about the password having impermissible characters that will mess up the user's account the SQL Server that backs GP. Then, after an admin tries to reset the user's password (typic'ly to something like "Password1!"), the user can log in with the insecure 'temporary' password as many times as they want, but cannot change to a new password. When the user tries, GP claims success and says to use the new password at next login…but when logging out announces that the password failed to change.
I found out I could just enter the first 20 characters and log in. I've had other websites that simply broke. The worst one had a password reset page that also didn't verify their own password length limits, sending me in a frustrating password change loop.
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.)
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.
Having password masked makes sense by default, but I agree users should be able to see passwords explicitly by tapping an "eye" icon.
And those of us unfortunate to use applications that forbid copy-paste on password fields.
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 :)
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.
*) plain-text here means any and all methods that give the attacker access to the original password, including modifying client-side JS.
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.
* 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
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.
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).
I’ve submitted many applications with glaring security holes in them to pen testing and never heard a peep.
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.