Transcription

Reece

Hello. This is Reece from "Cybersecurity Hot Takes." I am your host, an esteemed account executive here at Beyond Identity. And today, I am in conversation with Jasson Casey, our CTO. Say hello to the people, Jasson. 

Jasson

Hello, people. 

Reece

Excellent. Just as we practiced. So, today, we're going to talk about phish-resistant MFA. You know, phishing-resistant MFA has come up a lot in guidance from CISA and even the U.S. government. And I think that it could be getting to a point of where it's being talked about so much, like Zero Trust, that people are losing confidence in what it means. So, in other words, has phish resistance been reduced to just a buzzword? 

So, today, I was hoping we could talk about what phish resistance actually means to bring some clarity and concreteness to the problem of hacking MFA. 

Jasson

Resist all the phish. 

Reese

It's as easy as that, I think. 

Jasson

But only if you have that zero phish label. 

Reece

[crosstalk], like BPA free. 

Jasson

We did a webinar with Roger Grimes in another forum, and we were...this was one of the concepts that we were talking about. He had some pretty interesting stories about some various products that were claiming phish resistance but weren't actually taking the proper steps to be phish resistant. And some of the scenarios was kind of awkward. 

It was like they were confusing authentication, like trying to verify the identity of the person who's at the machine, with some of the technical aspects of phishing. And it's like, yeah, you can do that all day and be correct, I can still phish, intercept, and assume your identity unless you're doing these other kind of stuff. So, it was just interesting. 

Yeah, people are starting to just apply...surprise, surprise, people are starting to supply labels without either understanding the definitions or bothering to care about them. 

Reece

Yeah. And you were just saying that people kind of confuse the two, you know, between strong authentication and actual phish resistance. Where do you draw the line there? 

Jasson

I think it's important to understand what is phish resistance, to start with, right? Unfortunately, even the term phish resistance isn't really descriptive enough. So, a phish, at the end of the day, is me as an adversary, I have an arbitrary ability to deliver a link to you, the victim, and get you to click on that link, and then, you know, the roads can diverge, right? 

So, turns out... I don't know if I want to say this absolutely. I mean, I guess, technically, I can absolutely prevent phish resistance on you by having you just turn off everything, right? That's clearly not practical. But when we say phish-resistant MFA, we're not talking about preventing link delivery to victims. 

We're not even talking about preventing victims from clicking on the link. Fundamentally, you're not going to get humans to stop clicking on links. I'm just convinced you'll never stop. You'll lower the error rate, but you'll never stop it. When we say phish-resistant MFA, what we're really saying is, in an environment where our users can be phished and click on links, how do we prevent their authentication and identity, right? 

Which comes out of that authentication. 

Reece

So, it sounds like it's not really about... Sorry to cut you off. It sounds like it's not really about stopping user behavior at that point, which I feel, like, has been a big obsession in the security industry. It sounds like, hey, even if there is this behavior, people inevitably falling for social engineering, there are things you can do at a systems level to stop the phishing from succeeding. 

Jasson

That's exactly it. You're not stopping phishing, you're stopping from it being successful in an authentication context. And I think we talked about this, like, a while ago, around security usability, right? If you don't consider usability in the design of your security product, your users will create your next vulnerability. 

And I think this is the prime example, right? Passwords don't really consider usability, and, therefore, users will reuse passwords. They don't use high-entropy random strings per service. They blah, blah, blah, blah, right? So when we think about phish-resistant MFA, what we're actually talking about is highly technical. And the problem starts off with, assume an adversary can trigger an arbitrary phish. 

Assume that user, the victim, is going to click that link. How do you prevent the authentication sequence from essentially transferring its result onto the adversary, right? And so a phish-resistance solution has an ability to detect that scenario and stop. And it turns out the detection of the scenario is actually pretty...it's deceptively simple, but most products don't actually do it. 

Reece

Okay. So if it's deceptively simple, then why don't most products do it? Is it kind of one of those situations in human thought where the most obvious solution is the most overlooked? What does that boil down to? 

Jasson

Well, I have a couple of different takes on that. One is, I don't think...for the most part, identity products aren't necessarily security products. And in the view of many identity product managers, they're not necessarily solving security problems. I think they're solving work productivity problems. So this carefully considered expansive security view when thinking about access I don't think has been historically how the industry has approached building identity and access products. 

So, take, for example, a password, right? Symmetric secret. It's a factor that exists inside of your brain. It doesn't really talk about you in that I know your password, you know your password, and use it to authenticate. When you use that password into a computer, right, there's no real context as that password comes across to me that you're using this computer and no other computer, and that computer has a specific identity, right? 

When you use TOTP, the only information that's coming across is a number, and it may be coming across the same channel, it may be coming across in a slide channel or a multimodal channel. It's just a number. There's no context in that number that tells me about you or the password or the machine that you're using. So we have all of these. Like, they're almost dimensionless factors that are ships in the night relative to each other, they don't talk about each other. 

So, the authentication system, it sees this shotgun of factors come across, and it just assumes they belong to the same person on the same machine, right? And when we actually start getting into phish-resistant techniques, in actual phish-resistant products or solutions, in every case, there's a focus on actually building out that dimensionality, where every factor actually can kind of relate to the other factor in a concrete way that's kind of cryptographically linked. 

And the device identity is kind of also brought into the mix. So, you're kind of able to say something like, "I know the same device that started the transaction for Factor one is the same device that did Factor two, is the same device that did Factor three, same device that I fed the token at. I know I have a way for the client on the other end of the exchange to know that they're actually talking directly to the service that's issuing the challenge and not an intermediary." 

So, like, when I say deceptively simple, these are the things I mean, like when you see what the solution is, right? The client authenticator needs to be software. It needs to mechanically verify the origin of the challenge. And it needs to make sure that the origin of the challenge is, in some way, recognized to the key, right? 

So when we think about a certificate, we issue a certificate, a certificate as a subject, right? You would be the subject of your certificate. There's an issuer. The issuer would be, like, beyondidentity.com. And then there's an audience. The audience is a list of domains that when it sees the signature on a challenge, those domains would basically accept that as you. Essentially, they've decided to trust Beyond Identity as the issuer. 

So, origin verification, honestly, really just boils down to the client authenticator shouldn't sign anything on a key embedded in a certificate outside of a challenge coming from a domain from the audience list in that certificate, right? 

Reece

So, I'm hearing two things. I'm hearing device verification at authentication, and also origin verification. Those are the two pieces of phishing resistance or part of it? 

Jasson

I get you're trying to boil it up. It's not exact. You're close, but you're not exactly right. So, ultimately, we don't really care about the device identity. The device could be anonymous. We care that it's the same device, right? So, one of the hallmarks of... 

Reece

Or that the device isn't remote, because a lot of phishing attacks are executed remotely. 

Jasson

Well, in all of these scenarios, we're talking about remote devices, right? For me to be more clear, when you authenticate, when any device authenticates, it's not one transaction, it's a series of transactions. And sometimes it's from more than one device, right? It starts off being on my laptop, then part of it happens on my phone, then it goes back to being on my laptop, right? 

At a high level, the service that's authenticating you, right? It wants to know that is the key they're using valid, is the factor that they're using valid or the factors actually related to each other? And in an ideal world, every transaction needs to either come from your phone and/or your laptop. And I don't really need to know that it's your laptop, I need to know that the Transactions two, three, and four came from the same device that Transaction one came from. 

And so, like, that ends up being the problem. How do you actually solve that? And, you know, you can write software to try and solve it, but then we're getting to the space of, like, "Trust me, I'm a good dev, I'm a good coder," right? "You can look at my code, it does exactly what I say." Or you can move into more of, like, a trusted methods world, where you're really taking advantage of some of the mechanical properties of a TPM, right? 

Or of a T2 chip. And of the integrity protection of the OS to basically say, "Hey, use the key anchored in the silicon." And if it's anchored in a TPM silicon, you know it can't move. So if you know it can't move and you see that same signature across a couple of transactions, you know you're dealing with the same device, right? If you see the certificate for that signature and the certificate in it has this thing called an EK that you can tie back to a TPM manufacturer, then you've established its root of trust to an OEM, right? 

If that certificate also has an audience list, right, essentially the list of domains who will ask you to present this key, then you as a client now have a mechanized way of knowing who not to present your key to. And technically, you're not presenting your key, you're proving you have your key, but still, right? Like, there are these confused deputy-style attacks where they can't steal your key, but if someone gets in the middle, they convince you to sign a thing, and then they turn around and take that thing and present it as theirs. 

We don't want that to happen either, right? That's another scenario of man-in-the-middle. And so that's really where you have to understand, you have to be able to bind the channel itself, right? So when I create a TLS connection to a device, there's always a server certificate that's bound to a server name. 

Is that server name in my audience list? If it's not, maybe let's not sign this, right? 

Reece

That's the thought. So, we've talked about what phish resistance is. What isn't phish resistant that some people might actually think is phish resistant? 

Jasson

Okay. Phish resistance does not stop people from clicking on links. Phish resistance does not stop people from getting phishing emails, text messages, and whatnot. Phish resistance, when we talk about it from an MFA perspective, has nothing to do with you getting phished with some malware that you clicked and the malware installs in your computer and then does stuff. 

That's not what we're talking. We're talking about phish-resistant MFA has to do with the subset of phishing attacks that's focused on either stealing your credentials or stealing your access token and assuming your identity with a targeted service. 

Reece

I think that that helps clarify things. And I think more broadly, when you think about the security market, we have a responsibility to mean what we say and say what we mean. So, what advice would you give to the vendors inundating the market with phish resistance? How can we be helpful and herald in this exciting change that's going to ultimately take a lot of the burden off of users? 

What is a way to be honest about it and forthright as to what it means? 

Jasson

I don't know. So, marketing's always going to have a role in generating leads based on what people happen to be searching for and what SEO terms work. So, I don't know if I'm going to have a good answer there. And in terms of appealing to the engineer, like, showing up with a threat model that describes, like, what is the scenario, what powers are you going to give to the adversary, and what is the goal that you're trying to prevent, and how do you actually prevent that? 

How do you prevent the adversary from reaching that goal under the powers that you've actually given them with the product that you have, right? It's almost moving more towards, like, the academic-style proof, right? But honestly, having a simplified written-down version of a threat model like that goes a really, really long way in communicating the context of what threats you're focused on versus not. 

And then the immediate follow-up to that. And, you know, that should be a slide or two. And the immediate follow-up to that is then a demo, right? A demo of how you do it, and a demo of how it gets prevented. 

Reece

Show and don't tell. 

Jasson

Well, you need to tell and show. And the reason for it, you just show stuff, like, no one knows what you're talking about, right? Like, you do need a setup. Not everyone understands what a threat model is, so obviously, you got to know your audience, all that kind of stuff. 

Reece

Well, I see a good amount of show and tell behind you on the whiteboard wall there. So unsurprising that you would say that. 

Jasson

Yeah, I think...I mean, I don't know, I think most engineers think in drawings. I also think that when you're trying to be precise, when you're trying to talk exactly about the system that you want, the properties that it needs, like, English language is no longer good enough, and you actually need... 

Well, this is English language, but over here, you can't see it. You actually need mathematical drawings, right? State machines, conditions, properties, you need the language of logic, that sort of thing. 

Reece

I think that's kind of a fitting end to the episode. It's about being precise with phish resistance. Getting authentication and the architecture of it to a point of precision rather than passing off the burden to the users, who are going to open the email and click the link anyways. 

Jasson

Yeah, let's take the computer problem away from the person because they're never going to solve it the way a computer would. And then, I guess, your first point is if you actually want to really solve the problem, then yes, you do need to be precise. Because it turns out there is a root cause to phish-style MFA attacks, whether they're man-in-the-browser, man-in-the-middle, fake site interdiction. 

Like, they all actually have the same core three properties from a core problem perspective. And if you don't really understand that, your product's probably not solving it. 

Reece

Yeah. And this kind of brings us back to the beginning. What we're going to do for our listeners out there is link to the webinar that Jasson was talking about. It's a much deeper dive of this subject. And you will see demos of those man-in-the-middle attacks on [crosstalk]. 

Jasson

We do one on Microsoft Azure AD with Microsoft Authenticator number match, and we exploit it, we sail right through it, and we don't do anything fancy. Actually, we borrow someone else's work, and then we do the same thing for an Okta-Duo setup. 

Reece

Nice. So, like and subscribe this, and like and subscribe that, please. That's it for this week. We'll see you next time. Thank you for tuning in. 

‍