I feel like this post was intended to inflame or shock the reader with the writers stance on password policy. But anyone who has been in security for more than 1 month knows that regular password rotation has not been a recommendation for over 5 years. Both NIST, and MS have been trying to get the world to move to long, never rotated password, so long as those passwords are dictionary checked.
Every company (all 3 of them) I have worked at within the last 10 years, the IAM team has already implimented, or was working on implimenting a system that removed regular rotation, special chars and number requirements, and relied on three things: Length, a dictionary check at the time of pass creation, and routine dictionary attacks against the credential store. This started 10 years ago, for someone to make the same claims now, is not a shock.
Please note that if you are unable to impliment such an IAM system, especially the inability to dictionary check the credentials against known lists (seclists' github is great for this), then length plus regular rotation is still the recommendation
Working at a acquisition of a big consulting corporation. Had these recommendations in place before being acquired. We're onboarded onto better security systems by new mothership.
Password rotation every 75 days. No dictionary check. No check against known breached passwords. No real reasonable rules against insecure passwords (like ac_Paul2022 is valid 'secure' password).
Additional massive "spyware" on corporate devices in the name of security.
I don't care about security since being 'on system'. I don't do anything private on these devices. So I couldn't care less about what mothership does with their spy-/securityware on said machine.
I couldn't care less about the security. I cared when I could do something about security. When I had control about the security on the device.
I worked at a small consultancy. We started without password rotation requirements, because it's more secure. We had to add them, because our clients' legal teams started requiring that their contracts with vendors mandate industry-standard security practices. Your employer was probably in a similar situation: certain practices are mandated by customer contracts, not actual security assessments.
It takes a long time for industry-standard to catch up to actual practice.
Second that, we get some corporate checklist from the customer and they want it green.
Explaining that it is not industry standard anymore takes time and if they want to take time of their employees using our system to deal with that, I am not wasting our company time to make them right.
I've had customers ask and question me about it. I write the policies and reference the relevant NIST guidelines. It's a good way to end those conversations quickly. Even fed compliance generally won't argue.
Yes, I would do exactly this. At one company, I just kept adding dots on the end for each 3 month "rotation." I didn't stay there long. I think I got to 3 dots.
I think my cynical take is to not actually care. Very few people in the whole security industry actually bother to care because it's mostly box checking regulatory requirements and/or certifications because security beyond the absolute minimum just isn't important to the job. Most places aren't being attacked or broken into, and in the slim chance it happens there's less money to say "sorry for being breached, we're $worthless_cert compliant, nothing else we could do" because customers will believe it.
The corollary of this is that, as a user, you need to do your best do ensure that when your account is broken into, that it doesn’t matter to you either.
To get there though, we need better email hiding (Apple’s Hide My Email is great for this, you can get unlimited randomly-generated @icloud.com addresss that forward to your real one) and for sites to not actually need your real name or personal information.
If done right, if randosite.com gets all emails and (even if plain-text) passwords leaked, it wouldn’t matter because only Apple can tie the email to my account, and the password would only be good on that site anyway.
If a website actually needs my real address and name for billing information, that’s another matter maybe, but even then who really cares? The existence of my home address and name doesn’t much matter if they can’t tie it to any other online identities. My address is in the phone book too… it doesn’t really give anybody new information.
Fun fact: We are being shown how dangerous this internet is. With scary looking numbers of attacks per quarter. Until one scrutinizes the slides to see that not our mothership is the target of these attacks, but that these numbers (somewhat in the range of 350 - 500) are global numbers on companies of any size.
Since seeing this I became even more of a cynic. If they want to scare us - at least they should do it intelligently.
Most of these policies boil down to regulations or compliance. The financial industry, ironically, is a huge propagator of antiquated security controls.
We all knew that the controls were bad, but we had to use them
As a fellow person in finance... yuuuup. We switch passwords every 6 months and it is super annoying. A LOT of my coworkers are doing `password1` then `password2` which... sort of completely defeats the purpose of the policy.
Why should a corporation design its information controls for users who "care" about infosec, rather than designing for the overwhelming amount of users who don't care at best, and at worst are insider threats?
I agree in principle. But actively harming security for those users that already have a secure environment in place is a sign of compliance culture. Not security culture.
I needed to have less secure passwords under new security regime. More open ports. More services being exposed to the net, more code with potential bugs running on my machine and so on.
If you want to take over any of the big firms I would probably target a tool like Tanium [0] being employed by a lot of these corporations.
Last time I checked still based on python 2.7 (EOL 2020-01-01).
This was in my case installed as well as Flash with the pretense of security. I was a bit underwhelmed.
I actually told CIO about py27. And about it already being EOL. They did not know that (neither the tool using it, nor it being EOL). And they actually did not care. And told me not to care about it, as the mix of different tools would provide absolut security.
I don't think poster was complaining, specifically, that the security policy wasn't designed for people who care about security. In my opinion the issue is that they replaced an up-to-date and robust set of policies and tools with out-of-date tools and procedures. In addition they removed agency from their employees by installing an endpoint security tool on their machines.
I have to say, I agree! Once an endpoint security tool gets installed on my laptop and my administrator privileges have been revoked, I would definitely feel like the security of the unit was out of my hands. IMHO, this makes the organization almost entirely reliant on software and policies (which likely go unread) for security.
My belief is that this will result in an overall less secure posture for the organization as a whole. As this poster points out, his password is now less secure because whatever tool judges its strength is behind the curve. Other people may be more prone to open suspicious email under the impression that the endpoint security tool will take care of it. And so on.
Every company I work at requires regular rotation and other idiotic rules which lead people to choose demonstrably weaker passwords. My company refuses to listen to reason and accuses us of trying to subvert security when we point out their antiquated process. What do you recommend?
Try quoting from the government standard, NIST Special Publication 800-63b, section 5.1.1.2, which states: “Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).”
Increment a digit at the end of your password and stick the current digit on a post-it below your monitor, like everyone does. Then get on with real work.
The level of trust justified by pretty much all of security research; the insider risk is by far the biggest security risk for most organizations, whether you are talking about physical loss or infosec.
Both password rotation and special char requirements (which often interferes with strong password generations because other systems don't support same character sets) are very much alive and well in govt contracting / vendor requirement land. Ie, they are still very very common.
In a business when the password reset request rate gets high, it usually gets easier and easier to reset passwords. I worked with a govt system as a contractor supporting a subcontractor. They had such annoying password rotations and a DOUBLE password system (users didn't understand, but one was for a VPN sort of thing and the next was for the app) that coupled with frequent rotations of both passwords and very slow account provisioning meant reset requests were crazy high.
But the good part? You could literally call the number, provide a username, and then they'd read you the temporary password right then. They'd actually outsourced password reset because the volume was so high they couldn't support it with their staff!
A) Hi, I need a password reset.
B) Sure, what's the username
C) It's XXXX
D) Do you need password1 or password2 reset?
E) I'm not sure?
F) No problem. Use AAAA for the first password and BBBB for the second.
It was basically the system routing around damage so folks could get their jobs done.
That's why it's relevant that the NIST US government standards have changed in the last few years, and government agencies who are still requiring password rotation are not compliant and will have to remove that requirement.
That's the issue, not from what I've seen for some reason. Even recently the IRS was making life harder with tighter rotation periods.
But yes, that is the hope. I did push back somewhat on a local city system that went down this rediculous path (blocked password managers, hand type password only, crazy complexity requirements and rotation for a low risk system - think looking up a water bill).
Most orgs I have worked for have had/have 90 day password rotation. It resulted in passwords being stored in a Teams channel for easy access in case you did not remember.
> MS [has] been trying to get the world to move to long, never rotated password, so long as those passwords are dictionary checked.
So why do I have an Azure password that I have to change every few months? I always set it to a randomly generated string; certainly not anything in a dictionary.
> regular password rotation has not been a recommendation for over 5 years
It's just that it was a strident recommendation for 10 years prior to that, perhaps because many systems didn't support long passphrases but it was drummed into enough heads that it is now "conventional wisdom" especially in many business and government "enterprise" shops.
Even my latest employer, an academic institution with security folks who know better, still forces a passphrase change every other year.
Special character requirements normally end with most people adding # to the end of their dictionary vulnerable password, plus a lot more of valid password reset requests that could hide phishing attacks.
Seems like the reason for this is that a lot of places don't accept them as special characters. The exclamation mark (!) and hash (#) are almost guaranteed to be on the special character list, so people likely choose them out of habit.
I've always hated the term "special characters." If you are a non-technical user, it leaves a lot to the imagination.
1. What characters count as special? Does "special" mean non-alphanumeric? If so, just say that, don't say "special".
2. Among those, which ones will be accepted by your password system? Is \ acceptable? Will ™ be accepted? What about emoji (which evidently HN comment input doesn't seem to accept)?
Most password entry prompts do not answer either of these questions, so you have to either guess or just use ! or # and move on with your life.
Please do not group password rotation and special character restriction. One strengthens, the other weakens security. The only reason I can think that rotation would be a bad idea (aside from frustration, which is another very critical issue) is if users are not using strong passwords on each iteration.
The solution is for a standard to emerge that incorporates rotation and (optionally random) password generation used across sites. No more fucking "Login with Google".
10+ years of data has strongly indicated that yes indeed "rotation is a bad idea, because users don't use strong passwords when they are forced to rotate them"
The intent of the policy doesn't match the real-world implementation of users. Users are lazy. Users will alter a single character or digit in the password and call it changed.
Most people don't use password managers, and some companies block their usage. Now add a requirement of a "secure" password.
Even assuming a silent breach happens, it's unclear what's the value-add of password rotation in the context of other solutions that are less burdensome on the user: proper hashing of password databases (in case of a password DB breach) and risk-based authentication (in case of an inadvertent disclosure, like in logs).
Another reason rotation is bad is because it put undo burden on the user. You're now combining the unneeded burden of password rotation with the unneeded burden of a randomly generated password for a user to remember.
Of course, by remember, I mean put in a .txt file somewhere.
Both of your suggests disregards the user's experience and security is only ever as good as your user's willingness to use it.
If we're going to talk about hypotheticals where the whole world is able to switch to machine-generated passwords, I'd rather it switch to machine-generated asymmetric keys and leave the problem of breaches in the past.
One missed point, the advice is even slightly better than they argue, since they only argue that it's not necessary to change it, which is just an argument of convenience.
But updating a password is itself an attack surface. More so than merely using it to log in.
It's one of the times where an attacker may be tricking you into giving it to them, either by a fake page or app dialog, or in concert with maybe they have a way to receive the verification email or text.
Also it's a less frequent operation, meaning it's easier to fake. You are more likely to notice any tiny discrepency and detect a fake in the way your normal login screen looks than some account management screen.
Basically updating a password is a riskier action than the normal daily use of the same password.
And that alone is it's own even stronger argument for avoiding doing it unnecessarily.
Agreed. I think the main new vector is a "new device". So having the user approve on an old device (where possible or otherwise use 2FA) would prevent most of the log in attacks. It also removes the attack of "look under the mouse pad" where bribing a cleaning person gets you a whole company's user logins.
In the USA, the latest government guidance from Jan 2022 is that "Password policies MUST NOT require use of special characters or regular rotation". [1] This is a strong upgrade from earlier softer language like "don't have to/should not".
In practice, this new rule contradicts almost every InfoSec stance out there, but all government agencies must comply with this new rule by the end of the year, so expect lots of conversations and changes.
The "character class" requirement really doesn't add much security. And the "password rotation" policy can actually result in worse passwords than otherwise. Those measures were effectively just folk medicine from the days when the threat was thought to be someone manually trying to brute-force your password at your terminal.
You're probably right that, in practice, the character class doesn't automatically add security if the password is sufficiently strong and random. The theory is that by introducing special characters you're decreasing the likelihood of having characters that are commonly found together, thus decreasing the effectiveness of dictionary attacks.
Of course modern dictionary algorithms will still look for characters that are commonly used as substitutes for letters ($ = s, # = h, ! = 1 etc.) so really you just want your password to be random, long and unique.
The NIST guidelines address that in a much more straightforward way: maintain a list of known bad passwords (e.g., HIBP) and prohibit users from using any of those. Character class requirements are pointless.
> The "character class" requirement really doesn't add much security.
If you're generating your passwords randomly (using a password manager) it actually reduces security because it reduces the set of acceptable passwords.
Requiring special characters also reduces the set of allowable passwords by eliminating all passwords that don’t contain at least one special character. The best practice for maximizing the set of acceptable passwords would be to allow, but not require, special characters (and to allow as many of them as possible, not the narrow subset of special characters applications often allow).
That might be the only way to guarantee secure passwords across a platform/company. Of course, then you have to make sure people don't write it on sticky-notes under their desks...
Like how the Nazis thought they were so clever for preventing the enigma machine from repeating letters in the output. You’ve just reduced your entropy, sucka !
Not to mention it makes it harder to use the password in automated systems, as lots of places try to parse (or can't encode properly) $, /, -, and others.
I worked on Identity, Credentialing and Access Management (ICAM as it's known) in the Federal space for a while.
The U.S. Fed Gov has been implementing MFA with smart cards since 2001. While there are pockets of ineptitude and resistance, the vast majority of government employees and contractors use a hard token second factor.
Security is a property of a system, so analyzing a particular password policy outside of the given context (mandatory hard token MFA) is nonsense.
Yes, and the latest Zero-Trust guidance is actually legitimately good - it enforces a security practice on all gov agencies that will be better than 99% of the private sector. The password policy is just one line, but still a welcomed slap on the face of all Old Guard folks (who are overrepresented in infosec policy-making). The rule is clear: MFA or GTFO.
In practice, when dealing with US auditors and infosec chiefs, saying that "Some researches/guidelines say X is not necessary" will not compel anyone to change because "This is always been this way, and it doesn't _hurt_". The conversation becomes categorically different if you say "The White House says X is not allowed anywhere."
Perhaps surprisingly, US government guidelines exist, are pretty fantastic, and agree with the author:
Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed.
> A rationale for this is presented in Appendix A Strength of Memorized Secrets.
The relevant part of which reads:
> The minimum password length that should be required depends to a large extent on the threat model being addressed. Online attacks where the attacker attempts to log in by guessing the password can be mitigated by limiting the rate of login attempts permitted...
>
> Offline attacks are sometimes possible when one or more hashed passwords is obtained by the attacker through a database breach. The ability of the attacker to determine one or more users’ passwords depends on the way in which the password is stored. Commonly, passwords are salted with a random value and hashed, preferably using a computationally expensive algorithm. Even with such measures, the current ability of attackers to compute many billions of hashes per second with no rate limiting requires passwords intended to resist such attacks to be orders of magnitude more complex than those that are expected to resist only online attacks.
My reading was not that it must be entirely numeric, but that there is no rule that it won't be. As in, an attacker cannot make any assumptions about the characters in the randomly chosen password, such as "well it won't be all numbers, so lets rule out all those possibilities The 6 character limit only seems to apply to randomly assigned ones, not to ones the user picks, which is where a strategy like "what about all the number combinations" is more useful.
Any kind of bias like that is potentially exploitable, though. If the rule allows "only numeric", and that's the simplest thing to implement, then someone's going to implement it that way.
Which means that an attacker now knows that moving "only numeric" to the beginning of their attack sequence may be a viable strategy. Whereas if the rule did not specify, the attack would not be able to make assumptions about the character set.
That provides one million possibilities. I don't think you're missing anything. That's pretty terrible.
The only thing prolonging your account at that point is the service's rate-limiting, assuming a naive "enter this password in the login field, try it, repeat."
On the other hand, if you have too many password requirements and the user can’t remember it, they often lean on bad password hygiene, and the password ends up being reused (and inevitably leaked) or written down somewhere.
Rate limiting can be practically strong for everyday use. Bank PINs are commonly 4 digits, though the chip+PIN system allows up to at least 6. Three attempts and the card is locked. Provided you stop users from picking obvious numbers like birthdays, it's pretty effective at preventing card fraud.
Weak passwords can be fine, provided rate limiting is extremely aggressive. You can adjust this based on access e.g. your admin account might be locked under stricter heuristics like a single attempted login outside your geographic region (Live mail does this to me sometimes). In this case the user might even have the correct password, but if something else doesn't add up then you can block.
But if you actually tried to use 6 digits you'll discover most layers never tested it, including some of the most common point-of-sale systems and many ATMs not operated by your bank. Plus, tellers at your bank won't believe you.
My debit card in Switzerland came with a six digit pin - which was a surprise coming from the UK - and it works fine in other countries (Germany and Italy at least). But chip and pin is well known established in Europe so that's not too surprising.
I interpreted it backwards, "if you want to use a numeric keypad for controlling access to something, the codes MUST be at least 6 digits long, and you MUST assign them"
Re: entirely numeric, as long as the attacker assumes that the victim may use letters in their password, all numbers is fine, it increases the total number of possible combinations an attacker needs to work through
Rate limit the requests. Do an account lockout with an email click to re-enable after 10 guesses, do 2FA on new devices and you get pretty good security.
For many systems, users can memorize 6 digits easily.
The reality is, whatever your password reset flow is is enough. If you can reset your password with a 6 digit number via text, then that is maximum needed for actual password as well in most cases.
Interesting. In most cases if hash database leaks, the ability to crack depends on two factors, not one (password and hash difficulty) assuming you are salting properly.
You can specify pretty high difficulty with argon2id etc. Ie, shoot for a one second runtime with a very high memory requirement (you can go to GB range even).
I know it's hard to imagine, but before we all held supercomputers in our pockets we all used to have dozens of ten-digit numbers memorized. I still remember my grade school friends' phone numbers.
On top of that, in many areas in the US the time between moving to ten-digit dialing and the time of cell phones becoming even somewhat popular is really only a few years or less. Some places in the US are only finally being forced to move to ten digit dialing with some places still supporting seven digit dialing.
> Starting on Monday, October 25, 2021, Texans with phone numbers in the 254, 361, 409, 806, 830, 915 and 940 area codes must dial 10-digits (area code + telephone number) for all local calls.
You were an extreme outlier if you bothered to memorize dozens of ten digit phone numbers in the era before everyone had a cellphone.
The average person doesn't even have ten good friends, much less a need to memorize dozens of phone numbers. They would buy address books / contact books to write down dozens of numbers, not memorize numbers they very rarely use.
I think "dozens" is an overstatement, but 10-20 wasn't unusual. In college, I could have given you the number for a dozen delivery restaurants, easily. Not proud of it, just saying. That's not counting family, friends, services like taxi companies and movie theaters, and work.
How many different area codes did those dozen delivery restaurants and taxi companies have? How many different exchanges? Was each one a unique area code, each a unique exchange? If not, then you're not really remembering unique 10 digit numbers. There's going to be a lot of repeated numbers in there.
Or even more niche in your outlier status if you could remember IPs of the commonly used servers without a DNS in place.
Most of the time, local networked IPs all start with the same values for the first 3 octets (maybe 2 if VLAN but then usually only one digit diff). The same was true for most people's local phone number memorized registry. Those of us old enough, we only had to dial 5 digits using (70s) the last number of the prefix before eventually moving to 7 digits to include the full prefix (80s). The world suddenly changed when we had to dial the entire area code as well (90s).
I remember 2 out of the 3 landline numbers (one is my parents, still using that) I used to know, my 2 ICQ numbers, and my mobile phone number (which is still the same now, 20 years later). I never felt the need to remember a ton of numbers, that’s what phone books (digital or analog) are for and why I now use a password manager ;)
That’s the key people are missing. There’s a trade-off (though people can easily memorize phone numbers for example) when the password gets to complicated and you have to write it down.
Worth keeping in mind that passwords do actually leak. Companies have had incidents where they were inadvertently logging secrets passed to them. I've also typed/pasted secrets in the wrong field, which can get into some database or user-interface tracking tool. I've typed my sudo password instead of a vpn password at the command line, thinking sudo login had triggered when it was instead cached. Who knows when these crumbs might turn up.
And as others pointed out, breaches aren't always known or disclosed. Is it too late if you change your password 6 months after it's compromised? Not sure - maybe people sit on their exploits sometimes, or wait for a better buyer, or sell secrets in small batches.
All that said, I've never changed a password when it was newer than 5 years old, and only do it for crucial services, but if I were a bigger target, I might do it more.
If you do not reuse passwords and one of them does leak, then the only thing affected is the site/service that was compromised. Hence the word "unique" in the title.
Scenario: Your device has a keylogger. It already happened that e.g. android device makers were overly aggressive in debug logging almost everything, including everything you type or paste on the clipboard.
Leaking a password on your side is an unknown unknown, so password rotation is not a bad practice on its own for a security conscious person: It limits a leak in time.
Mandatory password rotation is a whole different kettle of fish, as it pushes users to lower password quality. Infosec policy was required to balance 2 conflicting needs, and the past has thougt us we balanced wrong.
I think it's also worth pointing out that there are many reasons why 2FA is valuable. Even if someone ends up with your password, they would still need your second factor, which could be a TOTP token or a WebAuthn device like a YubiKey.
Even if you rotated your password frequently, there would still be a large window of compromise. Password rotation only helps with very strange attack scenarios, and passwords themselves aren't really good enough for anything where security actually matters.
I would personally push away from passwords on the whole at this point. SSO is probably more secure for most users. Plenty of websites only support username+password auth, and given how bad most passwords are... I might even go so far as to suggest that username+TOTP is instantly more secure than that, especially with proper rate limiting as you should have anyways. (Yes, I know TOTP is "supposed" to only be a second factor.)
WebAuthn takes this to the next level and promises a future where you can use a strong single factor to log in, without any opportunity for phishing or credential compromise... but most implementations I've seen still require a fallback password mechanism. There are understandable reasons for this right now, but it is unfortunate.
If your old password was compromised by a keylogger, your newly rotated password will be too.
There original threat model for forced password rotation was supposedly based on hash cracking time. This is a stupid threat model; the guy from NIST who wrote it back in the 80s admitted it was based on no research but was added arbitrarily because it sounded good at the time.
That is true, but that one secret is still at risk, and maybe that secret means the world to you. You don't know when the info will be discovered or change hands. "No need to change" could maybe be nitpicked even though I agree with it in general - changing seems to provide some marginal probabilistic benefit if done properly, and the cost/benefit probably depends on what you are protecting.
> Is it too late if you change your password 6 months after it's compromised?
I'd say no... some compromises are "2 step"... Ie. someone accidentally was logging the passwords in plaintext for a few months to some logs system (compromise 1)... and then years later some attacker breaks into the logs system (compromise 2).
Or you accidentally typed a password into a terminal and it got stored in your .bash_history... and then months later you accidentally make your dotfiles github repo public, including your .bash_history containing your password...
Also, some thieves may compromise your account but not do much evil with it (and remain undetected). And then many months later they sell your account to someone else who does do evil with it.
I am in the camp of requiring people to have strong passwords, and not requiring them to be changed - ever.
When you ask people to remember too many passwords, they start writing them down and/or forgetting them, which leads to other problems.
My oldest online account - btw it is a brokerage account at one of the big brokerage houses, where a great deal of my cash and investments sit - has not asked me to change the password in close to 25 years, which I find quite funny.
> When you ask people to remember too many passwords, they start writing them down and/or forgetting them, which leads to other problems.
Writing passwords down isn't the worst thing. If you can't convince someone to use a password manager like 1Password, getting them to use a physical notebook of unique and strong passwords is actually the next best thing, because (combined with 2FA) it protects them against the most relevant threat models for most people (phishing and password stuffing).
A business card stored in a wallet or purse is pretty good too. After all, we're already pretty used to protecting our credit cards, identity cards, and cash.
It's pretty bad to put both a debit card and it's password together.
The only reason it's even tolerable risk to walk around out in the wide random world with a debit or credit card on your person all day every day, is because somewhere else you have the means to disable it and declare it lost.
This is like storing the keys to your car conveniently right on your car.
That's an important corner case I overlooked. I still think it's easily solved using the same principles: there are places in our houses where we regularly store sensitive items in already as well, such as a filing cabinet, or key safe, or next to that emergency $100 in a book.
Writing passwords down is inevitable. Having to remember more than two truly strong passwords is a ridiculous requirement to impose on the general population, and we live in a world where we need access to dozens of different accounts which ideally are supposed to all have different passwords.
We either need password managers or we need to do away with passwords entirely.
I will go further, expecting people to remember single strong password and change it every 3 months and not write it down is too much. Because after literally three rotation people will confuse previous and current password. And they will be out of memoizable ideas.
>Idea about rotation of passwords is that you assume that your password 'was leaked/cracked' and you don't know about it and have no way knowing it.
That's really not the user's responsibility at that point. It's up to the service to store passwords securely (i.e., use proper password hashing functions) and monitor login behavior to throw up extra challenges if things look suspicious.
Password rotation is a high-cost measure placed on the user that has little (even negative) benefit, especially when there are more effective alternatives the service is better-positioned to implement. Users cannot twist themselves into knots to make up for shitty service-side design decisions.
When I have right of way on the crossroads and I see truck coming with high speed from the side I am not going to drive in front of it and then claim, it was his responsibility to stop because I had "right of way". It is also no use when I am dead or severely wounded or all my money from account gone.
I worked on a crypto-related project where we ended up just generating a strong password on the client during registration. Credential stuffing attacks are just too effective.
Nobody complained. I think it's a better solution than making the user come up with their own strong password with annoying special character rules when you can just generate one for them.
The interesting challenge was making it work well with all password managers though which often have mind-numbingly dumb heuristics about what could possibly be a password field. It's worth a blog post.
Your money is insured, your brokers are insured. They just manage the risk differently than people directly in the tech world. Even though banks are right in the middle of it.
A good analogy for banks risk mitigation is like putting up a guard rail in front of a cliff. It's up to the user how high the rail gets set. Like daily limits, notifications, initial passwords, 2fa etc.
For the most part, banks and brokers want to reduce the friction of events.
A lot of users will simply change their passwords by appending a 1, 2, 3, etc. at the end. Presumably if old passwords did sour and become compromised then Hashcat would easily crack the minor tweak on the new password.
To be fair to these companies, the reason they do passwords so terribly is because of such poor guidance and standards in the past. Even now NIST has SP 800-132 for guidance on generating a cryptographic key from a password for storage applications, which is different and often confused with guidance on storing passwords (which they don’t give advice for). There they say to use PBKDF. Also, compliance standards such as PCI don’t allow for modern storage like Argon2, so at best companies use something like bcrypt.
This is literally what I did at my last company, where we had to change our passwords every few weeks. It was so damn frustrating. I'd be fine memorizing a random string of text, but having to constantly change my passwords meant that I'd continuously get locked out until I did that.
For my own personal use, I just use a password manager + randomly generated passwords, but it seems corporations are so damn slow to pick up on these obviously beneficial things that they choose clearly antiquated standards instead.
Anything below 5 in distance gets rejected, try again, please.
While you get to change password you make 2 boxes with current and new of course and do your comparisons on it, just to explain you still keep passwords hashed.
> Unless there’s a security breach where it’s stored
These can go undetected. Imagine
1. Hacker dumps database with your username & password in it
2. Brute-forces the database offline
3. Logs in as you / Sells it to 3rd party that logs in as you
A lot of time can pass between these steps. Changing your password is a mitigation against this scenario.
The correct mitigation for these scenarios, which I agree are a problem, is to not use shared secrets. Key rotation/ changing your password is a poor workaround.
If you steal the WebAuthn database from my toy implementation, now, or tomorrow or ten years in the past, it makes no difference because it doesn't have any secrets in it, so, you don't learn anything useful. "Man, if I was this web site, which I'm not, now I could validate that the authentication was successful".
In such schemes the only thing similar to a "secret" is the Private Key, which exists only briefly temporarily inside my Security Key or other authenticator when it is doing its thing.
One thing people seem to forget is that if passwords are long and too complicated to be remembered then thave to be written down somewhere, a password manager is all your eggs in one basket.
Lose access to your password manager and you can't access any online accounts with unrememberable passwords. Depending on the use case, a rememberable password is often a better option. One you can easily type on a phone is often a priority. My WiFi passwords are long lowercase no spaces word combinations, that are grammatically incorrect. Easy to remember and type on phones or WiFi printers. Most websites won't allow that.
I find sites that ignore my opinion on password security annoying. Some sites I just don't use because of their password policy.
You won't necessarily know about every leak. If a security camera records you typing in your password (or you accidentally hit view password in your manager) today someone might find that recording and access your account two years from now. Resetting your password resets the buildup of these small information leaks that occur over time.
Best practices get better over time. Maybe two years ago that password was stored as an MD5 hash, and that hash was getting leaked to log data. Bank.com has since fixed that problem, but you don't get the benefit unless you change your password.
Assuming a single character has something in the order of 100 possible values (I.e. a US English keyboard, no Unicode etc.) then a 12 character random password would take about 11.5 days to crack if you had a billion machines that could each crack a billion passwords a second.
I.e. you’d need 10 million hours of these machines to try every combination possible, with an average time to crack of 5 million hours. I.e. a total cost of $125 million, although I bet you could negotiate a pretty good AWS discount and/ or build the servers yourself and optimize them for cracking, so let’s call it around $50 million to crack a truly random 12-ASCII character password today.
Assuming Moore’s law improvements and improvements in energy costs/ efficiency and we can reasonably assume this cost could roughly halve every 18 months, to under $1 million in a decade. That’s not a lot of money to a nation state actor, so if you’re in a position where you seriously worry about active attacks against you specifically, perhaps using passwords that are longer than 12 characters is worthwhile.
IMHO almost all organizations have terrible password policies. There are only a few requirements for a good password:
1. The password must be difficult to the point of impossible for a computer to guess.
2. The password must be memorable enough that a person can create it once and then remember it a month later.
If you don't satisfy requirement #1 then it will be hacked with a GPU farm. If you don't satisfy requirement #2 then the users will undermine your security in a multitude of ways. Almost no corporate password policy attempts to address or even facilitate option #2. They don't even mention it! Many corporate password policies are actively hostile to option #2, requiring a bunch of stuff that's hard for people to remember but only reduce the search space for the computer farms attacking your leaked password database.
I like to use phrases made of things that sound like words, but aren't in the dictionary. Make them themed to be memorable. I call them Jabberwocky passwords. Were it not in famous poem a good password would be "mimsy were the Borogroves".
While it is certainly correct to never enforce changing a password, I would argue that it is totally okay to expire it in certain scenarios.
When my company set up the Active Directory f.e. we put a LSA password filter[0] in place that checks against HIBP. The password policy was set to expire every 90 days, atleast 15 characters and dont enforce a history. The non existent history was clearly communicated and users are encouraged to just enter their existing password three times when it expires. That way there is only one place where the passwords are checked for leaks and they are already there in plain, so it is manageable and doesn't add that much attack surface.
I’m not sure that this article sufficiently addresses the following natural objection: I don’t always know when my password has been leaked, and the chance of it having been leaked increases with time, so I should change my passwords ( to new strong, unique values) to lower the chance that they’re compromised.
For people who have to change their password regularly I suggest just adding the month and year in numbers at the end of whatever password they like to use. That way there is a clue in the current month and year as to what their password probably is should they forget
My security policy is based on the most common data breaches, where an adversary obtains a big list of email/passwords and just tries them on a handful of sites (Facebook, Twitter, etc), throwing out the records that don't work.
Sure, it's technically possible to decipher the algorithm[0] I use to generate new passwords, but that's not what I'm protecting against. If someone is trying to attack a specific person, there are much more effective ways[1].
[0]: For example, if my password for HN is "1y2c3o4m5b!$", you could sit down and figure out my reddit password.
If you're worried a password will leak, how frequently should you rotate it to maintain security? e.g. Even rotating yearly still seems a chore if you do it for websites you don't frequently visit (such as sites you made 1 order from).
The "add YYMMDD" or whatever is a way of working around a policy which automatically enforces a more frequent rotation than you want.
Oh yeh it’s not ideal but the alternative is my relatives having a post-it note nearby with their current password written down - I feel this is a lesser of two evils
And when do you know that said passwords have been breached?
Companies RMA, sell off, donate, and/or dispose of older drives, RAID caches, computers, workstations - are you 100% sure everything was DBANed properly without any data still lurking in bad sectors? All it takes is one snoopy fellow dumpster diving, or going through the garage-saled hardware of your former IT guy who made backups, finding some hardcoded credentials on an unencrypted or poorly encrypted drive - or other similar act of stupidity - to potentially leverage mistakes made years ago into active network access.
As annoying as I find password rotation, I get it.
"And not breached" is the key there.
Passwords are breached all the time, usually without notification.
See services like 1Passwords Watchtower, or look manually at lists like haveibeenpwned.
I think organisations forcing people to change passwords causes greater security risks. For example - if you have a bunch password character and length requirement, you will find people writing their passwords on paper or being more flexible in storing them. Because of this frequency, people will forget their password often and require assistance of IT admins or other people often through phones and emails.
I would say, strong password is slowly becoming a myth due to organizations failing understand what it is before creating a policy surrounding it.
I imagine a world where governments get together and mandate that all online passwords use the same standard of password requirements and salt/hashing at the backend. Penalty should be 10% of your gross revenue.
While they are at it mandate some standards of customer service if your business exceeds $1M in gross revenue (must have a "get human" button and the call hold time shall not exceed 15 minutes).
I know that sounds like a fantasy utopia, but I remember a time in the 70s when there was a serious push for consumer advocacy in the US.
We effectively have this now with PCI-DSS (requirements imposed by credit-card processing companies), and it sucks because of the bureaucracy involved in making any change.
It has take literally over a decade to relax the requirement for password rotation from 3mo to 1yr for employee accounts of companies that process CC payments, despite industry knowledge and formal studies saying that frequent password rotation was detrimental and useless.
Instead of defining the process, state the outcome you want and set penalties on failing to meet the outcome.
E.g. "don't have password leaks, or it will cost $1k per account paid directly to the account holder" (or your percent of gross, split among leaked accounts). Let companies implement those controls however they wish, as long as they are achieving the outcome and penalties are actually being applied.
I agree that failures need to have significant penalties, otherwise companies will decide that the penalty costs less than the prevention (which is true today) and minimize their investment in security.
> some organizations want to convince us that with the passage of time your password becomes increasingly susceptible to attack
I feel like this is somewhat true for self-fulfilling prophecy reasons; these same organizations don’t always disclose every compromise or leak of their systems, and don’t always force a password reset when it happens because it would reveal they’ve been hacked. I’m certain I have multiple online accounts at organizations that have suffered minor, major, and ransomware level breaches.
While sharing passwords is never a good idea, sometimes it is necessary. For example, I am the treasurer of a non-profit organization, an elected position that rotates every two years. We have a savings account at a credit union that for a variety of reasons requires online access by multiple individuals who change over time. The only way to keep this even a little secure over time is to require a password change every time someone drops off the authorized access list.
There could also be software licensing issues that lead to multiple users sharing a login for software, same thing applies.
This is good for developers but there are two important unknowns if you're an end user:
1) You don't know whether the service or site employs best practices e.g. throttling. (Although you might be able to test that yourself if you're tech savvy.) So you may have to assume the worst, and there goes Point 1.
2) You can't be sure they will report a breach if it occurs, or that the password will ever show up in e.g. haveibeenpwned. So there goes Point 3.
Which a consumer of a service does not know. There's law now to force providers of services to announce leaks/breaches and there's haveibeenpwned; both are no guarantee.
Changing a password gives consumers a fresh start.
> Passwords do not age. They do not sour, spoil, or stale.
The "fresh start" does imply some sort of spoiling/ageing.
Rotating passwords (re-freshing) in the age of password managers is not that much work, for some critical accounts that may be a good thing.
the Hive infograpgh (amongst others) always comes to mind; 18 characters long, upper, lower, numerical, special. estimate time to brute force 438tn years.
not OP but I only have to remember two 18 character passwords, my laptop and KeepassXC. I use all of OP's suggestions as well as mixing languages, one being an indigenous language that only about 20K people in the world know, together with a little leet speak. I haven't been breached since the early 2000's.
You don't; except in a very limited sense if you use tools that check your passwords regularly against password leaks.
But that still doesn't mean forced regular password rotation makes you safer. Changing your password is in itself a relatively high risk activity. And the likelihood of your password leaking tends to be dependent on factors you control.
For instance, if you assume that a given service provider won't leak their password database (which is usually hashed in some way), you are being optimistic. You should always expect that this can happen and act accordingly when choosing, or preferably generating, a new password.
What? If they're not breached then that invalidates the other two points anyway - unless you can find an authentication endpoint that doesn't rate limit. HTTP proxies are expensive and trying to brute force something that is on-server is not a common attack vector.
I know its nit-picking, but the title is incendiary and warrants that.
What about an undetected data breach leaking username and passwords? Periodic password replacement reduces the window where someone's stolen password is used a long time after breach. This may not be the threat scenario for every type of accounts, but in some type it would one among the most important ones.
If it remains undetected, the rotated passwords will still be leaking. Once you detect and mitigate it, you force everyone to reset their password immediately. Periodic password rotation is pointless.
Here's a good and free tip: A unique password breach can be turned around to better know your enemy. Set-up a canary honeypot and monitor your environment for it:
Passwords and password files are better protected now than they were 25+ years ago.
- ssh did not exist or was not widely used. People used telnet, ftp, rlogin, etc. which put plaintext passwords on the wire.
- UNIX systems that used NIS distributed the password file to clients via a plaintext map which could be obtained by anyone with “ypcat passwd”. Many passwords were guessed in seconds using crack or John the ripper. Complex passwords would withstand those attacks for weeks or months with those tools using a single computer to reverse them.
- (I think) NTLM and CIFS authentication put password hashes over the wire. Various tools were available to reverse these as well. Once it was feasible to build rainbow tables, getting a password from a hash was a simple lookup.
- switched networks were not widely used making sniffing passwords or hashes from the wire much easier. Hubs would broadcast all traffic from all ports to the other ports on the hub. Coaxial Ethernet daisy chained many computers along the same physical wire. I think that “ring” networks (token ring, fddi) also passed all traffic by all nodes.
In those days, regular password changes were important because your password it it’s hash was regularly exposed.
I’d argue that today, any password you type where someone else may have a camera should be treated as though it has also been compromised. This means that if your password manager isn’t auto filling it, you should be using that password only with two factor authentication.
One problem with this strategy is that you never know if there has been a leak. Proactively changing passwords protects against such leakage, such that the leaked password must be used within the window where it is still valid.
a) Passwords should be easily rememberable. Pick four words are string them together (e.g. correcthorsebatterystaple).
b) You must have a physical security key to authenticate - a Yubikey etc.
If those two factors are not enough, then forget working from home / mobile authentication - require people to arrive in-person and work in-person, with network restrictions on top of the two-factor authentication.
If two-factor authentication isn't enough, and IP address restrictions aren't of help to enforce know-your-user when they show up in person, then I swear, God help you. At that point, you're no longer practicing security, you're practicing paranoia.
>network restrictions on top of the two -factor authentication
That is exactly what I thought was the case too until I recently entered the code Google Authenticator gave me although my mobile was not connected to the internet. And it worked.
It's vastly more likely you'll be pwned by remote passwords than local programs. Even if it is a local program, there's so many ways to store a password there's no automated way to reliably get a password. Your threat model will become a person targeting you specifically, thumbing through your files to find information, etc.
I encourage everyone in a position to run into this discussion internally to memorize a few key sections of NIST 800-63. It's come in handy more than once...
There are better mechanisms than password rotation to mitigate (even undetected) security breaches.
Password databases can and should be storing that data using proper hashing functions like Argon or bcrypt. Those are designed to be slow, so brute-forcing them even offline and in parallel becomes time-consuming. This increases the time between when a breach happens and when those passwords become useful to attackers. This gives the service more opportunity to detect the breach and force users to reset their passwords.
If attackers somehow obtain actual passwords before then, then the login system should be using risk-based authentication, where it throws additional challenges if the user appears to be logging in from a completely unexpected IP address or client.
I update my passwords from time to time. I don't trust the organizations will always say if there is breach, know there is a breach, or actually know how far and wide a breach went.
Do you trust them to salt and hash your password using bcrypt? (rather than store it in plain text). Do you use a password manager to generate strong passwords that are at least 16 chars long? If you can answer yes to both, then it doesn't actually matter if your hashed password was part of a breach or not, the hackers won't be able to brute force it. (Of course if hackers manage to steal the private key with which your session cookie is encrypted, they can still log in as you - but then changing your password won't help either).
This seems reasonable.
How often do you change you passwords?
Feels like it would get extremely tedious if you have more then a few accounts though, no?
This only applies to banking and email passwords. And most last over a year. I don't have a schedule, just one morning I wake up and go, 'oh yea, I've been using that password since 2019...'.
Yes. You can set your passwords to expire after a date (or a period) in KeePassXC. They will show up in your Health Check reports along with weak or non-unique passwords, possible leaks and more
For certain sensitive websites (e.g. domain registrar) I change passwords once a year or so, because there's really no guarantee that administration would 1) notice a breach early or at all, 2) fully understand the scope/severity, or 3) even notify their users about a breach.
Yes. For sites, desktops, everything that have some rule stating that passwords expires after 30/90/180 days, must not repeat the last 3/5/10 passwords, must have at minimum/maximum n characters, must/must not contain special symbols or some subset of it.
My current work forces updates every 3 months. It seems more like a security issue requiring this reset so often.
This is because they create another problem when anyone you talk to will say they have their password and just increment a number for every password change. That way they’re not having to remember a whole new password every few months. So there’s never much of a change in anyones password during these rotations.
I think this is an issue for things like a system login where you can't necessarily use 1Password or your equivalent. I have my work domain password in 1Password, and it's a huge pain in the ass when I need to use it in that context.
However, if you use a password manager, and have access to it, I think forcing key rotation on a short schedule actually increases security. The downside of course being that most people don't use a password manager, and most people use the same relatively unsecure password for everything.
NIST actually changed their recommendation relatively recently and no longer suggests periodic password changes without reason.
> 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.
Yes, and I believe they initially made this change in June 2017 (almost 5 years ago now). IT audit/compliance is typically 5 to 10 years behind best security practices and some standards are even slower to catch up.
There is still a specific case for password rotation which is to periodically rule out the threat of compromised passwords.
Meaning, if your password is 10 years old it's subject to any leaks or security events during that long time frame. If it's 3 months old, anything that could have happened to it must have happened in the last 3 months which is much better than 10 years.
I hate password rotation rules. Companies have iT departments that love nothing more than to add "value" by adding their own spin on what password security should be. It's pure security theater.
At every company I've ever worked that required password rotation, everyone just incremented a digit, usually at the end.
I also hate the completely arbitrary rules on length (I mean, why do some sites have a maximum length?). Some require uppercase and lowercase as well as digits and certain special characters and what special characters are allowed is inconsistent and completely arbitrary.
We need to focus on how much entropy [1] a password has without arbitrary rules. 20 lowercase letters is going to be better than a 7 letter dictionary word with one letter capitalized and a number of symbol on the end. In fact pretty much every password 8 characters of length should be considered cracked. 10 should probably be the absolute minimum.
I use parts of song lyrics or movie quotes for most my passwords, and I do the same with increasing a digit. I'm at digit change 17. The thing that REALLY kills me is when a password has a maximum length.
What Should You Do?
There’s a simple checklist of improvements you can make to keep your passwords forever secret:
If you aren’t already, start using a password manager.
Use the password manager to generate strong, unique passwords for every account.
Review old accounts that contain personal, proprietary, or financial information and update their passwords using the password manager.
Never share personal facts, like your pet’s name, when required. Instead, replace a real fact with random text that you store in your password manager for later access.
Enable two-factor authentication wherever available.
I can't argue with any of this! But there are obstacles on the path to this utopia. Password managers are becoming more and more usable for average folks, though I've seen some confusion in some of my non-tech friends/family, esp when integrated into browsers. There's also the question of market penetration. Is your grandma going to use a password manager?
Other trends I've seen:
Passwordless auth tying into WebAuthN. If a site can tie into a method secured by the OS, all the better. I'm not sure the uptake, but have seen some presentations/comments about it being a far superior UX. Also, seen some startups built (and raising $$$) around just this.
Known, trusted bigcos like Facebook (ya, I know, but they are trusted by lots of non tech folks) and Google. This has some upsides because they can secure accounts really well, and also keep on top of new security reqs like MFA. But there're plenty of HN stories about being locked out of these IdPs, so this may be a bit of a scary delegation for some.
Passwordless auth tied to email. This is great for low value, infrequently used accounts because often 'send me creds via email' is the default path anyway, usually via 'forgot password' flows.
I am very curious why public private key auth is not a thing for websites and applications. I would rather have a single password to the server that publicly hosts my public key then I can simply point websites and applications to that address during signup. Every app/site would check the server every 5-20 mins for changes to my public key in case I need to change it. Then I can use my private key to authenticate to all these sites/apps instead of trying to keep track of 500 damn passwords.
If you're logging in from a library computer, you don't want the hassle of putting your privkey file on it and wiping it later. (Or connecting a USB drive, which may be a security hazard for the library)
If you lose your computer, you still remember your password, but your only copy of your privkey may be lost. Losing hard drives is common for non-power users, because they don't do regular backups, and they often don't know that you can trivially recover files from, e.g. a laptop with a broken screen that won't boot.
And computerized cell phones are actively trying to convince those non-power users that files don't even exist, to protect their profits.
Your idea is basically "What if I was 100% trackable everywhere" which, if you're comfortable with that you're a rare exception - and if you didn't realise that was what you just proposed, well, now you know why we don't do that.
Now, public key cryptography is indeed promising, but you see something rather more sophisticated to deliver privacy and security and that's what WebAuthn is.
I really hope that password managers are a step in this direction. Once they become ubiquitous then everyone effectively already has a "master password" for all their online identities. It wouldn't even really need to be a 3rd party service. The password managers could hold the keys locally and websites could just use WebAuthn for authentication.
It's probably a bad idea to authenticate on a public machine to begin with. How can you possibly know what that machine might do with your account once you log in?
But let's say you want to do it anyway. There is no need to memorize or type the entire key; a site-specific private/public keypair can be derived from a memorized master password and the domain name (for uniqueness) via a KDF. The site never needs to see the master password, so in the event of a breach all your other logins remain secure, and there are no key files to synchronize, just a single password for access to all your accounts.
You do need to trust that the PC you're using to log in is secure, though, since it has access to the master password; I'm not sure how you would get around that without involving some other trusted piece of hardware, and if you have that you could just use it to access the site instead.
Too many extra steps, especially on mobile. And very suspectable to phishing and social engineering. Also makes it impossible to login if you lose email access (and what if you need to change your address because of it?)
Yeah it's an obnoxious process. I don't know why people are so against passwords. Use a manager (or at least something like Lesspass), and then you're fine. Passwords aren't scary. They won't bite.
WebAuthn can do full blown Usernameless, and it's very easy with devices like a modern iPhone or high-end Android.
I have no idea why this wasn't immediately huge. You see the login button, you tap it, your existing fingerprint reader or whatever verifies you are still you, whoever that is, and you're logged in, done. Much more secure than people's crappy passwords, yet much easier to use even than the crappy passwords.
I am unconvinced. What about persistent password bruteforcing? Rate limits? OK, bruteforcing is happening within those rate limits. That's how the password rots - it becomes less of a secret as many values are tried.
Key material rotation seems to be a sensible practice in general.
> it becomes less of a secret as many values are tried.
Not meaningfully. Let's take my Hacker News password and we'll imagine you happen to know (somehow) exactly what the format is, so then you start guessing.
And we'll imagine you can make 1 billion login attempts per second, which in fact I'd guess will make dang pretty unhappy 'cos the servers won't like that.
And maybe you get to do this on a billion computers, and for a billion seconds, again I'm thinking somebody would notice and stop you, but let's just say...
At the end of all that you've still got orders of magnitude less chance of guessing my password, for this web site correctly than a random ticket buyer has of winning the jackpot in a typical state or national lottery game. Get a new hobby.
I think people struggle with the numbers involved. Even astronomical numbers are too small, because astronomical numbers involve practical things, like how quickly light travels and maths does not need to be practical.
"There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers." - Richard Feynman
With a ratelimit of 60 attempts per minute (which is significantly higher than any user would legitimately ever need) you're looking at thousands of years to bruteforce a random 6 character alphanumeric password.
Yeah and if your system allows an attacker to sustain one attempt per second into perpetuity, then you need to improve your system. Just be wary of DOS attacks against users when considering things like per-user limits (versus per-IP limits)
The problem is that ratelimiting doesn't work when your password database is leaked. Brute force attacks on the front end system basically don't happen because rate limiting is everywhere. They'll try a handful of default passwords and move on.
What you're saying is true, but you need to consider a regular office drone who doesn't care about security. If you require them to change the password every 90 days, you will end up with the majority of people having passwords like conS0t01, conS0t02, conS0t03... And not only will they have such weak passwords, they will boast about this to anyone who will listen, leading users to actually tell other people their password, and how they arrive at (And remember) the current mutation.
And when it arrived at the point user themselves are confusing about "wait, is it end at 33 or 34?". They Will Write It Down On Post It. And you end up get the worst security situation you can get normally.
Every company (all 3 of them) I have worked at within the last 10 years, the IAM team has already implimented, or was working on implimenting a system that removed regular rotation, special chars and number requirements, and relied on three things: Length, a dictionary check at the time of pass creation, and routine dictionary attacks against the credential store. This started 10 years ago, for someone to make the same claims now, is not a shock.
Please note that if you are unable to impliment such an IAM system, especially the inability to dictionary check the credentials against known lists (seclists' github is great for this), then length plus regular rotation is still the recommendation