Root Causes 245: One Time Passcode as a Liability

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

September 29, 2022

A recent article from Brian Krebs advances the idea that using OTP MFA may actually be a liability to security. In this episode we explain the reasoning behind this characterization.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanSo, today we want to talk about a news article, but I think that also touches on some bigger themes that we talk about a lot. So, this is from August 30, 2022 - - it’s a Krebs on Security article. So, tip of the hat to Brian Krebs, and the, the title of it is “How One-Time Passcodes became a Corporate Liability.” So that’s how you can look the article up. And Jason, what does this article say?

Jason SorokoTim, I love the title of the article, and quite often, as you know, technical journalists are looking for that click-bait type of titles. I think Brian Krebs, the type of journalism he does is great. He really digs, and I think that the choice of title is interesting in that I’ve never heard too many people really talk about any form of second factor authentication as being a liability or, you know, a blanket problem for an enterprise.

Tim CallanWe talk a lot about it maybe not, not doing what you think it’s doing. But there’s a difference between that and viewing it as an actual liability.

Jason SorokoThat’s right, Tim. We’ve talked about the downfalls. We’ve talked about how not all MFAs are created equal. We’ve said it so many different ways on this podcast. And the reason I’m bringing it up is because, finally, amongst popular journalism you’re starting to see that, pretty extreme words being used, such as the usage of it is a corporate liability, and let’s just go over the problem because I think, Tim, this lesson almost can’t be learned enough. As soon as you’re dealing with passwords, you’re dealing with a shared secret, and we could probably go on and on about just the problems of passwords alone, but we are talking about one-time passcodes. And there’s a lot of different ways to generate one-time passcodes, as you know. So there’s not just one way, there’s many ways. The one problem that all of OTP solutions have in terms of second factor authentication is not just the fact that it, itself, is another shared secret, and how that secrets are stored can have problems, we can get into all the various ways that that can be compromised but it actually turns out that the bad guy goes after the lowest hanging fruit.

Which is basically creating a social engineered situation where a person, typically a corporate employee, is presented with a webpage which looks exactly like their standard authentication system for some internal corporate system.

They’re challenged for their password, and then they’re challenged for their OTP, and again, that OTP can come from a myriad of systems. The article, of course, from Brian Krebs just happens to bring up Okta which is just one type of OTP that’s out there, but it’s a really good example. People have been trained in corporate environments to use whatever authenticator of choice of the enterprise is, and they figure, well, since I’m being challenged for this user name, I’m being challenged for my password, I’m being challenged for the OTP. I’m gonna provide all that. Well, how does that user absolutely know that they’re on a legitimate login page and once those three pieces of information have been given away to the attacker, an example of this article the webpage is being fraudulently presented to these users was harvesting all three pieces of this information and successfully duping people who didn’t know better, the fact that they were giving away everything needed to log in as them. It really shows the problem with OTP. OTP can be given away. It can be harvested just like a, just like a password can be harvested.

Tim CallanAnd one-time passcodes, of course, exist for some period of time because humans are slow. So, I gotta look it up; I gotta see it; I gotta key in the number; I’ve gotta stop and think about the fact that I miss-keyed it and move back and do it again. So you’re normally given some time, like 45 seconds, to use that, and it’s good for that period of time, and of course, computers are not prone to that kind of error and are very, very fast. So, short of an incredible coincidence, it’s pretty easy for the, for the spoofer to automatically fit that passcode in, in the living time period.

Jason SorokoThat’s a really good point, Tim, and in fact, in the Krebs article it goes on to say that not only was the attacker capable of utilizing the OTP that was given to them in a very short period of time, as in nearly instantly, but also, the attacker was able to carry out full-blown supply chain attacks with specific privileged users. That was just an example that Brian Krebs gave. So in other words, the bad guys had done their homework, once they had the privileges they needed, they were able to go off and do some nasty things. So all the old assumptions of, oh well, the time period that this OTP has to lives is gonna limit what the attacker can do. Well, it’s just not true. It’s just not true.

Tim CallanWhat it does do, is it prevents reuse. In an OTP scenario, there’s no concept of, I bundled a bunch of usernames and passwords and I sold it to somebody. Like that doesn’t happen except as an element of something that also uses this OTP attack. But, if you have all that information, you bet. You're in. You’ve got access, and you can do whatever you’re gonna do.

Jason SorokoSo on that very point, Tim, of persistence, the bad guys have thought of that as well. Which is a lot of these systems once the bad guy has logged in as the target, quite often there are changes of passwords. In other words, the bad guy has now made it so that they’re able to sometimes make it so they can log in again, or, and sometimes downgrade attacks are quite possible being able to turn off your MFA in some systems where that’s allowed.

But also, for those of you who say well, I’ve got my stuff locked down. That just wouldn’t be possible in my system. Well, congratulations, that’s terrific, but keep in mind that there’s also other forms of persistence attacks that can happen. In other words, I dare anybody to guarantee me that the bad guy couldn’t do something with that credential in order to be able to then live in that environment for a lengthy period of time or at least, long enough for them to be able to perform whatever attack they’re going to do and the various chains of things that need to happen by the bad guy in order to complete sometimes very complex goals. I think that some diagonal thinking is what’s lacking when people are thinking about what an attacker can actually do once they are in. The ability for them to stay in for a long period of time is quite often the case, regardless of what kind of safeguards you put in. Obviously, some very simplistic systems may not allow a hacker to do much, but unfortunately, that’s not the type of systems that attackers often attack. Quite often they’re very complex systems where there’s a lot of various kinds of diagonal edge cases that the bad guy has figured out that you might not have in your, in thinking about your attack vector. It’s this kind of thinking, Tim, that I think the old tropes of well, I put a second factor of authentication on, I am safe, or the attacker can’t log in again, so I’m safe. Well, I think it's time to really think hard about those kinds of ideas, and start to limit what the attacker can actually do, and really think hard about yes, we know that some legacy systems might only ever be able to use a username and password. Some of them might only ever be ever to use an OTP, but for those systems that can be modified to use something stronger, it’s really, really past time to start thinking about that.

Tim CallanSo let me, let me ask you a question. I still find this word “liability” to be really provocative because liability, at least to my ordinary English-speaking brain, means worse, worse than nothing. So is there a scenario where having a one-time passcode is actually worse than not having it for what is otherwise the same login scenario?

Jason SorokoI think if you compare it to just a username or password, I don’t think that from an authentication standpoint it’s the liability. I think the liability comes in from people who are up the food chain in the enterprise, dusting their hands off, and saying well I’m good.

Tim CallanI’ve solved it. I have OTP, I’ve solved it, and therefore, I’m not going to give it anymore energy.

Jason SorokoIn other words, I’ll give you a perfect example, Tim, is what I like to call auditor checkbox type security, which is I’ve added a security control, and so I’m good, without any regard for the strength of that control. That’s, that is the liability that it can present.

Tim CallanOkay, that makes sense. It’s overestimating the impact of your security measures, which then can lead to greater exposure, for whatever reason than you have otherwise because you don’t take other measures or because you put too many eggs in that basket, and then ultimately, that’s how you wind you being worse off.

Jason SorokoYou got it, Tim.

Tim CallanGot it. Well that makes great sense. So good, good article from Brian Krebs. Lengthy article certainly worth giving it a read if you have a chance. And thank you very much, Jason.

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!