Root Causes 342: Don't Change Your Password for Two Years

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

November 17, 2023

The CA/Browser Forum rules stipulate how often forced password changes for CA employees are to occur. They don't, however, specify a frequency at which these forced changes must occur. Rather, they set the MINIMUM time before forced password changes can happen. Join us to learn why.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanThis is gonna be a down in the weeds episode and this is gonna be a down in the weeds CA/Browser Forum episode. You know I love those. So, on this occasion, we just thought it would be interesting to share a very little known fact about the Baseline Requirements and talk a little bit about the implications of it. And this little known fact is that in the network security section or the network security Baseline Requirement which is one of the BRs that CAs are expected to follow, there is a requirement that password changes are not forced to happen. This is for people, this is for employees of the CA who are involved in validating and managing certificates. That access password changes are not required, forced to happen, more often than every two years. So, think about that, Jay. This isn’t a requirement that says that they are forced at a certain frequency. It’s a requirement that says they are forced not more frequently than a certain number. Certain time. So what do you think of that?

Jason SorokoI’m thinking back to two things. One is, I remember way back in the day and I’m talking 2008, 2009, 2010, and a little beyond that. I remember back when the advice all the way into the standards bodies was, oh, you’ve gotta swap your passwords like every 30 days. And I remember telling people, hey, would you like me to show you a demo of keylogging where the act of changing your password was it simply made it even easier to harvest that password. And then the look on people’s faces to tell them one of their most beloved rules driven into the head of every IT department head and employee, to look at the people’s faces when I was telling them that their baby was so ugly in terms of the - - how could you say to me that my sacrosanct rule doesn’t make sense and in fact, makes life worse. Well, it wasn’t that much longer after that that NIST of course deprecated their advice on password changes. And actually no longer advised change your passwords often. And it’s just amazing to me that it even took that long or that I have to have that much of an argument with that many people. So, it’s interesting to me that this actually goes one step further, what you just said. Which is to actually limit the number of changes.

Tim CallanLimit the number of forced changes. You may change it as often as you want. If you want to change your password, great. You may change your password. There’s no problem with that. But in terms of forced changes, it’s what you said. Unwilling password changes themselves carry risk. There’s the risk you talked about which is I get social engineered. I use a forced password change spoof to convince somebody to give away their password and now I know what it is.

The other risk, really simply, is that passwords are hard and if you make them too hard then what happens is people choose other solutions that are fundamentally insecure. The biggest one is password reuse. They say I cannot conceivably remember all these passwords so I’m gonna use the same password everywhere. Password reuse is a huge problem. That leads to credential stuffing. I go and I steal something for a relatively low value site, and I turn around and it’s also the same exact password that’s used for a high value site. And so credential stuffing is a big outcome.

Another big outcome is that people just store their passwords in insecure ways that we always joke about the file sitting on the desktop of your computer called passwords. But people do it if they have no other choice. If there was no other way for them to or if they perceive that there is no other way for them to be able to access the things that they need to access. So, there is very cogent I think and powerful argument to be made that forced password difficulty inherently reduces the security of the log in process.

Jason SorokoI think that’s been shown. What was inherently true to us more than a decade ago, it took people a long time to catch up to that. Then, of course, these things are now demonstratable. It’s true. It’s just interesting to watch these things that are considered to be just absolute mom’s apple pie guaranteed, like this is just the way it is and it’s not. I find it interesting, Tim, that we are still talking about passwords. They’ll be with us for the rest of our careers, that’s for sure. They’re gonna be around forever. Don’t forget folks why multifactor authentication was invented. It’s because passwords themselves very, very problematic. Very insecure. And we’ve had whole episodes on this.

Tim CallanWe’ve talked about this a bunch.

Jason SorokoBut I would like to see, Tim, just maybe the last comment for me about this is I’d be interested to see when the standards bodies, people who write things like you just said, when are they gonna start saying things like what, any kind of net new system maybe needs to be a non-password based authentication scheme. And whether if it’s business to consumer WebAuthn based passkeys have shown themselves to be very effective and of course, in the enterprise world, all kinds of certificate based authentication that’s out there. There’s a ton of great ways to authenticate now that are not password based and I’d be interested to see when various kinds of guidance or various kinds of standards that are written actually write out passwords altogether. Maybe it won’t happen, but I’d be interested to see if that trend every starts.

Tim CallanI think that’s interesting. We certainly haven’t seen it yet but if you look at this thing from CA/Browser Forum it feels like it’s a step in that direction doesn’t it? Where there’s a real clear cogent recognition of the danger with passwords and some general prescriptive, or proscriptive in this case, guidance about how to mitigate that danger in a pretty unabashed way. And that is refreshing. And it is a start. And it is a security-based standards body recognizing the trouble with this particular strategy and really saying what you have to do to at least minimize that.

Jason SorokoGood on them, Tim. Good on them. A lot of what you’ve told me lately about CA/Browser Forum and decisions that have been made and various kinds of talks that have been happening there. A lot of them just sound very, very reasonable and definitely in the spirit of doing the right thing. You diving down super deep underneath the dandelions to find that nugget for us, that again shows you the level of thought that has gone into a lot of what’s in the BRs and good on them.

Tim CallanAlright. So we both kind of hate passwords. Everybody kind of hates passwords. But this forced complexity, forced changes and it’s not just forced changes. I was thinking I just had to log into something just yesterday. I had to create a new identity for something. It was a trivial stupid thing. I had to go in and fill out a very short form. And to do that, I was forced to create a login and so I went in, and I tried to create a password and it turned out that I needed the high degree of complexity – upper case, lower case, numeral, non-numeral character and I was like really? I’m literally gonna go into a form, I’m gonna fill in six questions and I’m never gonna use this ever again. Is that level of complexity really warranted? You and I just talked in a different episode about sort of braindead application of what under certain circumstances could be a good idea, but it becomes a bad idea because you are not thinking. That struck me as one of those not thinking moments where whoever put this together didn’t say you know what, this is ridiculous and it’s probably doing more harm than good.

Jason SorokoTim, let me go into the weeds there with ya. That kind of put a character and an upper case and a lower case and all that kind of malarkey, that was to help to make guessing difficult. And rainbow tables that were based off of guessing that could help to foil them completely or make the amount of time it would take to break a password a lot longer. Now the problem is this. And I’ve given this demonstration so many times that I hope I never have to give it again, but I will if necessary – folks, with keylogging and credential harvesting -

Tim CallanIt doesn’t help.

Jason SorokoYour special character doesn’t matter. Your password will be harvested. Period.

Tim CallanYep. Absolutely. In a key log scenario, it doesn’t matter. And in a credential reuse scenario, it doesn’t matter. Like in both of those cases it’s useless.

Jason SorokoYou could have an incredibly complicated password that if you copied and paste and reuse, guess what? That guy has got it.

Tim CallanIt doesn’t matter.

Jason SorokoAh. It’s fun.

Tim CallanSo, anyway, there you go. That’s probably all I have to say on that, but it is a very little known fact about the BRs and I thought it was telling and indicative and worth discussing here.

Jason SorokoThanks, Tim. Again, good on the CA/Browser Forum and the folks who write the BRs and just a reminder about passwords and the nature of passwords. It’s a doubleheader there.

Stay informed with expert insights

Subscribe to Root Causes for engaging discussions on PKI, digital security, and best practices for protecting your organization's critical assets. Don’t miss an episode!