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