[P5fRxh5kUvp2th]

I recently had a bit of a rant about security people and how 70% of the truly dumb decisions in our industry can be attributed to them.

Your description is exactly why. Security people wedge themselves into the halls of power and then start making decisions that don't actually negatively affect them all that much.

I've literally seen a CISO that insisted everyone worked in a way they themselves did not.

[jonfw]

sadly, the job of a CISO typically isn't "make the most pragmatic decisions possible to keep our infrastructure secure and running smoothly". In many industries, it's more lke "join as many compliance programs as possible to expand the ability to capture revenue from regulated markets".

The CISO didn't make the decision to enforce password rotation- the compliance programs your sales team asked for did

[P5fRxh5kUvp2th]

To your point, password rotation is considered an insecure practice because it causes people to append 1, 2, 3, etc to the same password.

But I've seen so many companies that still insist on it.

[selykg]

I'm the IT guy for a new non-profit. We aren't separated yet from the company that created us, but we're in the process of separating. I get to decide all this fun stuff.

I had a very brief talk with the IT team for the larger parent company when I started and explained this stupid password rotation thing, as I came from a security background, they wanted nothing of it. Set in their ways.

For the new non-profit that I'm helping spearhead, I'm not sure I'll get away from the password rotation entirely, but I can certainly set it to something more reasonable, like every 365 days, rather than every 60 days or whatever travesty most are dealing with. I'm pretty pleased about this.

[zmgsabst]

NIST agrees, as if their update a few years ago.

> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret

[acdha]

This is a really useful thing to keep in mind because even if you aren't directly bound by a requirement to follow the NIST standards, being able to point your policy people at that is handy if you can shift the conversation to “bring our policy in line with NIST” where there's a question about whether they'll later look bad for _not_ having done so. Typically these conversations are driven by risk aversion and things like federal standards help balance that perspective.

[selykg]

Thanks for the direct link, putting this in my back pocket when the discussion inevitably takes place.

[als0]

Aside from password rotation being a very questionable practice, it actually can cause productivity loss. In a big organisation like mine it can take up to 48 hours for a password change to synchronise across all the internal services. There's also the issue where some endpoint software still uses the old password behind the scenes and fails to log in too many times - causing your account to be locked. I guess you can see my frustration coming through.

[structural]

I had the joy of dealing with some endpoint software like this in an organization that had mandated password changes every 30 days. Very predictably, people set recurring "change your password" reminders for the 1st of the month and the organization lost an entire day of productivity each month as they locked themselves out of their accounts en masse. So the beginning of the month was always a panicked, all-hands-on-deck day for the help desk as people were waiting on hold for hours to get their account unlocked.

[rmccue]

Our penetration testers suggested we add password rotation, and I had to quote them the latest NIST guidelines which state "Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)."

If they don't know better, it's not surprising other companies don't either.

[KronisLV]

> To your point, password rotation is considered an insecure practice because it causes people to append 1, 2, 3, etc to the same password.

A good solution to discourage this would be to have heuristics that'd make sure that the new password isn't too similar to the old one, but doing that without having plaintext in there somewhere is pretty difficult.

Another solution would be mandating that all of the passwords should be randomly generated, but enforcing that would be difficult, because everyone who isn't used to having 99% of their new account information being in KeePass databases with randomly generated passwords, probably would find that too cumbersome to remain productive.

This seems like a people problem that makes being secure essentially impossible, due to how people use passwords (e.g. "I just use one password across X sites because remembering multiple ones is too difficult" or "I just add a number at the end of my current password").

And others also mentioned the productivity loss, for when people are slowed down by the need to change their passwords. You might easily rotate Let's Encrypt certificates thanks to automation but when it comes to people, things aren't so easy.

At that point, you might just stick with whatever passwords you have, do some dictionary checks in the future, maybe have infrequent password rotation and otherwise stack on more mechanisms, like TOTP through whatever application the user has available, or another means of 2FA, because relying just on passwords isn't feasible.

[mr_toad]

> causes people to append 1, 2, 3, etc to the same password

It’s either that or they write them down. Because people are going to forget a password that changes every month, especially a password that has to comply with the complexity rules.

[patrakov]

> The CISO didn't make the decision to enforce password rotation- the compliance programs your sales team asked for did

And it's the CISO job to resist unnecessary overcompliance which is just for the happiness of the sales team.

[plonk]

You don’t make the company lose business just because compliance is unnecessary. You’ll (rightly) get overruled every time.

[renewiltord]

Isn't that just a characteristic of how they're evaluated? Any security error is the CISO's fault, "heads must roll", etc

Given that, they're likely to give you what you are asking from them: a brick with no functionality which will do nothing. You can't do anything with Brick, but Brick has zero outstanding CVEs

[greedo]

CISO often stands for Chief Sacrificial Officer...