Here’s a rant that makes me look pretty stable. 🙂 Nick Selby’s post, “Do You Make Users Rotate Passwords? Well, Cut It Out.” I agree with the general sentiment, and I get the annoyance, but not so much the general way this is presented without making some qualifications.

Just to get the elephant in the room out of the way: All of this discussion is somewhat moot once we throw in the requirement of multi-factor authentication. Which makes sense, especially as biometrics (slowly) continues to make headway, which is like a password we won’t ever be able to change.

I’m also not making any assumptions on password strength, either chosen or forced. I can’t expect every user to practice good password hygiene, so I can’t really add that to my arguments. I’m also not going to make assumptions on complexity requirements forced on users by the system.

OK, let’s first make some distinctions: corporate/employee* vs consumer sites. There are two major types of accounts I have in mind with this discussion. First, accounts that an enterprise uses to identify its employees, usually set up and managed by IAM/Help Desk folks and rotated every 90 days or so, and removed upon termination. These employees typically come to an office and sit at a workstation to log into. Second, there are accounts used on consumer sites such as Gmail, Amazon, DreamHost, FaceBook, etc. These are usually set up via self-serve and probably don’t force changes except when compromise is suspected to some degree.

In the former, there are arguable times when these account passwords may get divulged or known, such as a Help Desk worker doing “something” on your system to troubleshoot an error over a lunch break and wants to log in after the screensaver kicks in (hey, another rant-worthy piece of bait!). There are too often small one-offs where an account password is shared. I hate it, but I understand it happens. There are still two use-cases for enterprises to use proactive password rotations. If a user has a shared password and needs that friendly reminder to change it, or if an unknown compromise of a password has occurred, the forced rotation of a password will close both of these gaps.

For consumer site accounts, users are left to shoulder the responsibility of the confidentiality of their passwords. If they share it with someone else, it’s on them to change the password after usage expectation has ended (ever “borrow” someone’s Hulu account longer than intended?). For consumer sites, the onus for keeping your password to yourself is on the user, with the only exception being a failure in the security of the site, which can have two outcomes. First, a compromise is suspected/known and all affected users are asked to change their password. Second, the compromise and exposure of a database that contains user passwords in reversible format, but where this compromise may not be known for months or years.

In the past, this conversation has sort of been about rotating passwords faster than most attackers can crack accounts, but I’d argue that’s less the case, and the real way it should be worded is to limit the window of opportunity for an actor to possess something that is still valid that they should not possess. Whether that means cracking times or exposure to an unknown compromise, I don’t really care.

Has password rotation ever “increased security?” I’d argue not really, but it helps deal with *decreased security* scenarios, namely someone has your password and you didn’t know it, or you did, and failed to change your password after the need to know it has passed. In the past, this also includes the scenario of password cracking. On the other hand, perhaps rotating passwords at varying levels has helped prevent situations where users use the same password for many accounts. Rotating passwords at varying times may decrease password re-use across accounts and actually be slightly better for security, but that’s just strange to think about.

Users create predictable variations from existing passwords, though! I suppose, if you know the base form of that password. For some, it’s easy to guess. New account in April? Try Spring18 or Spring2018. Then things get a bit more predictable, sure. For corporate accounts, at that point we’re already starting to get close to account lockouts or other alarms. For consumer sites, it’s harder to guess that base form, in my estimation. That said, I would say this argument has some weight. I’d bet some old passwords for users, if cracked, probably would inform their future choices (Bulls2015 may today be Bulls2016 or Bulls2017 or Bulls2018). But I suppose a cracked password that requires guesses to get the current password is better than a cracked password still being valid?

Users hate it and are inconvenienced! This is less a substantive argument and more a commentary that security and convenience are always at odds, and finding the sweet spot between them is a dance between objective and subjective discourse. Ask 20 infosec pros any scenario and you’ll get 22 different answers, all of which are varying shades of correct.

Why 90 days? Why not 30 minutes? I don’t know, I don’t think that’s the point? I think this is just acknowledging that security is not about finding *THE* right answer, but finding what works between the goals and people. Ok, fine, I think 30/60/90 days requirements back in 2003 were about cracking times for typical Windows account hashes. Roughly. Very roughly…

At any rate, all of this is pretty anecdotal, as is probably 99% of the discussion on this topic. Even places that try to say there is “lots of evidence” one way or another never really seems scientific or defensible from twisting the statistics around to form an opposing hypothesis or just have too small a sample. (Yeah, this is my way of dismissing stats and not wasting my time pouring over academic papers to support whatever my position is or will be. If paid to do that, I’ll be happy to!)

(Now, all of this said…I’m playing a little bit o’ Devil’s Advocate here. I won’t defend either position on password rotations terribly hard or to the death. But I think defaulting to password rotation in corporate account cases is the better approach and defaulting to unchanging passwords for consumer sites is also the better approach, with MFA swinging things away from rotations.)

* There is also the small slice of the puzzle with actual shared enterprise accounts or service accounts. The former being maybe a shared login to something low value (for instance, each concurrent user is a cost or something). The latter being your normal service accounts where various admins may be able to retrieve the password or set it up on a new server. I won’t deal with this, since it should be obvious these are rotated regularly, especially as employees leave the enterprise or lose their need-to-know.