The only employer I've had which had a dumb rotation rule was of course a huge American Credit Reference Agency which due to ordinary incompetence lost a lot of people's personal information.

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.

It’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.

I've found it commonplace these days at least in europe that organisations use SSO via an identity provider that requires MFA for everything they can - even clients who are banks and utilities that usually move at a glacial pace.

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.

I wonder what will happen if I post a provocative „Why is our IT department violating NIST password recommendations?“ in public slack.

Yes. My very large employer hasn't required me to change my password in over two years. But at the same time, 2FA requirements have changed to more secure forms (going from having to select one of 3 numbers on a prompt to having to type in the number, for example), and some resources can only be accessed using a hardware key or even a special laptop.

I've encountered situations where the requirement to rotate passwords was obligated by contractual agreements. For instance, this is still the published guidance documentation on the HHS website for HIPAA compliance (https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/ad...):

  > Covered entities must train all users and establish
  > guidelines for creating passwords and changing them
  > during periodic change cycles.

From the employer POV, employees cannot be trusted to discover their passwords are compromised, so updating them limits the duration the leaked password works.

Aha good point, my bad.

For this particular issue, it took a while but the NIST password policy does follow 800-63 now. They changed it a while back.

The funniest password requirement I've seen was "must include a special character" but the special character selection was limited to #!$& and of course attackers know this requirement too. Combined with most people putting it at the end, that gives a little over 2 bits of entropy...

Wait till you meet websites that simply truncate your password at 32 characters or 16 character without telling you and leaving you to figure out, why you cannot log in with your just a minute ago set password ... and what that says about how they store passwords. Either they are complete idiots and do not understand what hashing will do, or they are even more idiots and store passwords in plain text in their database, so that the length matters this much.

My default PW gen rule is only alphanumerics, far too many websites have issues with special characters. It’s also 24 in length because that tends to fit most, while 32 gives me frequent errors.

Do you know how long is the UNICODE? That's going to be a very looong list (on some sites)!

https://symbl.cc/en/unicode-table/

Just scrooooool...

> where you can't use a password manager (Such as a smart TV, games console, ...)

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'

You should only rely on your memory for passwords that you use frequently. Rarely-used passwords should be kept somewhere safe and well-maintained, such as a password manager and/or on paper.

> forced monthly rotation that had to be significantly different than the prior one

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.

Pretty bad, but use a password manager and generate random passwords, unique to each account.

I really, really think that flow was designed to try to get more re-purchases of Minecraft.

Uncaring 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...

> I just save these as random values in extra fields in my password manager

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..

my bank offers phone banking.

Which involves you speaking a pin over an ordinary insecure phone call.

Such 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.

Sad part is they're stored often plain text and agents can read and even sometimes use their own judgement so a little social engineering acting like a confused older customer could be an easy bypass - especially if the agent sees it as a keyboard mash.

I 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.

I do this. And once I had a customer support agent ask for it. The conversation went like this:

Agent: "I'll need to ask for a few details first. What was your first pet's name?"

Me: "ZD4Fbyed6fzoUcmi"

Agent: "Thank you."

That's hilarious, actually.

So I suppose my answer would have to be "This one".

I had a relative that just answered "butter" for everything.

> 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.

Similar problem with Microsoft Dynamics Great Plains. I think the save-password window accepts more characters than get stored, so trying to log with the seemingly correct password a few times gets you locked out.

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 ran into that with Paypal. Login limited my password length to something small (I think 20 characters?) but the signup page accepted my random 32 characters just fine.

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.

I don't get the max length restrictions some sites have. Why?

The munggles, the large majority of them.

And those of us unfortunate to use applications that forbid copy-paste on password fields.

Everyone on sites that forbid pasting into the password field. (!)

Everyone? Just consider your mobile phone when doing anything that requires some sort of security elevation.

Truncation 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.

There 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).

"your password is on fire!!"

I still see bullshit like this from pen testers, who really should know better.