It's not just about "convenience", it is hard for the human mind to remember a truly random password. You can try all the mnemonic tricks you want but at the end of the day it requires a lot of time and repetition before entering the password is effortless. So what people do is create a stream of derivable passwords. For example, I can think of a phrase "I love beach balls bouncing on the ocean!" and then make a password "ilBBbotocean!" and when it comes time to change that password, I'll just add a number "ilBBbotocean!1". Studies have shown this is what people do. But it is easy for attackers to also derive these passwords once one password in the chain has been compromised.

The effect of that is that by requiring frequent rotation, the organization is effectively training their users to have a single permanent password and to never change it, even after a compromise. That's extremely harmful. At least with permanent passwords that are force rotated after they show up in database or there has been an incident, you have a much higher percentage of compliance with making new passwords, and the organization is safer because everyone isn't using passwords derived from the previous password.

> And no one in the security business seems to consider the overall burden of yet another step. Each of which is simple in by itself, but cumulatively they are a giant hassle, and so people look for workarounds.

This is a tale as old as time. At a prior gig, IT took away touch ID for ... $reasons. ~40% of the engineering team was already big into mechanical keyboards so it only took one person to "just FYI, VIA allows you to program macros". Is it _as bad_ as password on a sticky note? Not quite but I can't imagine that touch ID was _more_ of a threat.

Not really new. A long time ago I had to wait 2 months to have access to a shared folder on a development server.

It became so prevalent that whenever we were planning anything, if a task had to be done by someone outside of our team, we added 20 days.

Security through eternity I guess ?

I call this sort of thing a self-DoS. If the system is unusable enough, it's indistinguishable from a DoS attack. This sort of sabotage isn't restricted to the security team, anything that makes the system unreliable enough from bad design through bad performance can have the same effects as an external attack.

Very obvious, but things that seem obvious might not actually be true. It is worth verifying.

Getting organisations to act on the obvious if it requires changing is harder than you might think. Having research to point to and saying you are doing the wrong thing and now you've been told is like turning the lights on and off really quickly and moaning "Liability" in a spooky voice.

That’s fine as long as you are kept logged in or at least have an abbreviated login process after successfully authenticating in the morning.

CRUD apps can contain very sensitive data, so not sure how that’s relevant.