Watch Jasson Casey, CTO at Beyond Identity, demonstrate the difference between multi-factor authentication (MFA) that is secure and phishing-resistant versus phishable, insecure MFA, along with Roger Grimes, data-driven defense evangelist with KnowBe4.

Transcript

Jasson

So, yeah, the first couple of things I wanted to do was really just do a show and tell, and then we can kind of talk a little bit more about how the product gets used and how we actually made it work and function in the way it does. But to start with, let's actually just flip over to a demo. So I actually recorded this a little bit earlier because the bandwidth in my hotel room is quite sketchy. 

So the setup that we actually have is we have our victim. Our victim goes by the name of Alice. And Alice is going to log into a work service. So what you see here is in the background. I have set up an account for Alice. We go ahead and spill the beans upfront. 

Alice's password is Feb2022!. But what we do is we have two different scenarios that we have set up in the back that we're going to try and...that we're going to phish. So one is a scenario with just kind of a traditional enterprise SSO and MFA solution. And the other is with that same SSO solution, but with the Beyond Identity authentication and kind of zero-trust access experience. 

And I'll get in and talk a little bit more about what all of that means in a minute, but just a little bit of background about what's going on. So I didn't spend too much time trying to come up with clever lures and emails to get the victim to actually click on a link. I think we kind of all understand that, that is an art and there are people that are very good at that. So I just jumped straight to we can get someone to click on this link. 

So what happens? What does it look like in this setup where I have a common enterprise SSO with MFA integration? So I'm going to go log in. Looks normal. What's my username and password? I keep it in my handy-dandy password manager. Let me copy it over. 

I love Alice and Bob as names. They, for those of you that are slightly old. 

Roger

The crypto world. 

Jasson

We're getting an MFA pop, let's make sure we take care of that. What do you know? I'm secure, yep, that's me. Because it is me. I'm trying to do a thing. At least I think I'm trying to do a thing and now I'm into my service. And just to show you, yep, this is me. It thinks it's me. 

Now, there are a couple problems with this, right? We were just man-in-the-middled, we're being relayed by a proxy just as was demonstrated a minute ago. But let's go on and see what happens. So now we're going to show the other scenario. And after we show the other scenario, we'll flip back and get a little bit more detailed under the hood. 

But the scenario we're about to do is we're going to log out, and we're going to log into the SSO that's, where we've actually integrated with Beyond Identity. And you'll see what that experience looks like. So let's say I've been phished with this link to the other setup. And I managed to land at the man-in-the-middle proxy. Now, one thing off the bat that you might notice is there's no password. 

File that in the back of your minds. We'll come back to that. Oh, crap, I forgot my name. What is it? Oh, yeah, it's Alice. Now moving forward, and you'll notice a different sequence of events start to happen. And ultimately, that sequence is going to result in a failure. 

Like, I'm unable to really move forward. And I'm going to tell you why here in a second. Okay. So here we're getting in under the hood. So this is essentially, you can think of it as the output log from the man-in-the-middle proxy. So I have two of them running up. One of them was responsible for man-in-middling the traditional MFA solution. 

And the other was trying to man-in-the-middle the Beyond Identity solution. So in this first scenario, you can see clearly that not only did I capture the username and the password, but I was also able to capture the JWT, the access token, which is just as useful, right? I can do as you saw a minute ago, log into that active session and start changing things if I want. 

Just in case you didn't know where it was, I highlighted it there, and just to show you a little bit more information about what was actually collected. Okay. Now, this is the solution where I tried to man-in-the-middle the SSO with Beyond Identity, and you'll notice I never captured a password. 

And if you remember correctly, a password was never actually entered, but also the authentication session never actually completed, it failed. So not only did I not capture a password but there was no access token, or there was no JWT produced at completion. And there you go. 

I'm showing you where you should look. All right. So before we end the demo, I would be remiss if I didn't actually show you what the happy path looks like. So I'm going to log into a service. Now, this is actually a live service. So you're going to see a slightly different sequence. 

Because I have access to certain applications, the machine is going to escalate its challenge to me. And I'll explain a little bit more detail what that is. But part of the challenges is it's actually asking me to prove I can use something that's protected by an enclave and guarded by a biometric and/or a local PIN. And once I do that, I'm actually allowed through. 

Roger

And this is the way it's supposed to work. If you're sent to a fake website, it should not work. 

Jasson

So what did we just see? Let's kind of talk about that in a little bit more layer of detail. So I'm an engineer at heart, and I apologize if any of you are rolling your eyes right now, but I love these sorts of things. I love sequence diagrams. It was kind of how I learned network protocols and network systems a long time ago. And it's, for good or for bad, it's just how I imagine the world, right? 

So I'm sure some of you have seen these before. They're just sequenced diagram. They help us visualize what's actually going on. So we have the victim or Alice off to the left, we have the adversary in the middle, and we have the SSO off to the right. So I have two versions of this slide. The first one is just maybe, there's the victim that's going to get phished and there is no MFA present. So when the victim clicks on a link, they don't go to the SSO site, they actually go to the adversary and the adversary proxies that request. 

And that ensures the adversary gets included in the response. So when the response comes back and the victim is supplying their credentials, the credentials are actually going to the adversary. And then the adversary, of course, can just proxy those credentials. And now they've captured the credentials, and then, of course, because those credentials are correct, they'll also receive the access token on the end. 

This isn't terribly exciting because it's a step simpler than what we just described, but think of it as like the building blocks, if you will. So now let's add a second factor. And in this case, let's add a push factor as a notification. In the demo, you saw that this really didn't do anything to defeat the scenario. And in this sequence diagram, we kind of show you why. 

As far as the service that you're logging into is concerned, it really can't tell the difference between the adversary and the victim. The 2FA has a direct channel to the victim. You've coached the victim into trying to actually do something that they think is legitimate. So you kind of have a willing participant or signing fool, if you will. And that's how this is actually able to be pulled off. 

So, again, up until that first theft of credentials, everything kind of looks the same, but then the SSO engaged the two-factor, whether it's an SMS push, or a TOTP insert, or, as we saw, a push notification. Because this happens out of bound and because there's no real kind of channel or transaction binding that brings all these things together, it's very difficult for any of these systems to really know what's going on. 

And, of course, we get the same result, a theft of credentials as well as a theft of access token. Now, again, this is one way of harvesting credentials. It's a lot easier to just go to password sites and get dumps if you really are interested in credentials. This is more interesting because you're getting the access token, right? The access token gives you immediate power. So let me talk a little bit about Beyond Identity, and then I'll go to, well, how did ours work to make that a little bit more clear. 

So here at Beyond Identity, we have built basically an identity platform from the ground up with the idea that we're trying to service a security audience. We want to be the first identity stack built to present security controls to a set of security admins and help them actually improve the end-user experience while actually being able to answer the questions of, what is the likelihood of the person who's claiming an identity at the time of access against the criticality of what they're trying to do? 

And what's the security posture of the device they're trying to do that from? If there's some way for us to take all of those three things and anchor them together to where we know that the parties that we start the transaction are the same parties that we end the transaction with. And we have some sort of hardware level of trust, then we could really start to change the game. And I have this bad habit of talking about slides that come later, but in literature, they call that something. 

What is it? Shadowing, foreshadowing. Anyway. So now let's go back and see what we saw. Okay. So this is the phishing-resistant flow. So, again, remember the two setups. 

Scenario number one is I took an SSO. And in our scenario, we used Okta because we love Okta. They're a great partner. We work with them in a ton of our production accounts. And we showed how to actually have a phishing-resistant SSO with Beyond Identity versus a more legacy provider. And the way it actually worked here is, of course, everything always starts off the same, right? If you can get a victim to click on a link, you're always going to start off with a proxy being in the middle of a particular sequence. 

But when Beyond Identity gets engaged to actually delegate the authentication, we actually start to run this challenge-challenge response process. So you all are probably familiar with classic password authentication, right? You want to log into a service, that service sends you, they call it a challenge, but think of it as a random string. 

And if you're able to permute that random string in a way that you know how to permute and the back-end service knows how to permute, then bing, bang, boom, must be the right password. Well, with asymmetric cryptography, it turns out you no longer have a shared secret, right? You can actually just publish may be a public key and just keep a private key. But in addition, we're not just trying to prove the victim is, or the original subject is who they claim they are, but the service they're authenticating to also needs to be able to prove to the victim who they are. 

And there needs to be some way of adjudicating that those two things are, in fact, the same thing and nothing has come between. And we're able to do that through a sequence of challenge and challenge-response sequences where we actually kind of sign the payload so you get this nice tamperproof resistance. The cryptography is anchored in hardware and I'll tell you what that means here in a minute. But ultimately, we're able to kind of catch that sort of solution because it's very obvious upfront when we go to receive that challenge, it's obvious it did not actually come from the adversary and it just shuts down. 

Okay. So what does it look like at a high level, and then we'll drill down a little bit? So most security incidents start with a valid credentials use, which is a really technical way of saying most companies aren't getting security results from their identity stacks. So how do we change that? 

That's really kind of the mindset that we've had from the very, very beginning. So we built an identity stack that could plug into really all of the incumbent SSOs that you may have already deployed. And off of that identity stack, we paired it with this thing called...what we call a platform authenticator. I shouldn't say we call it, we actually borrowed the language from the W3C, if you dig into their webauthN specification, I think they actually introduce that terminology, platform authenticator. 

But what it basically means is we have an authenticator on the endpoint, on the machine that someone's trying to do something from. And this starts to give us a precipice from being able to actually make claims about the person and the device, as well as check validity of challenges coming back to the device. We've introduced a policy engine in both our cloud and that platform authenticator so that when someone wants to access a service, you know, risk and risk acceptance aren't black and white. 

Every company has a different risk acceptance familiarity, capability, willingness. And even workers within a company or customers within a company might have different willingness or different needs. 

Or put simply, if I'm doing a low-risk activity, maybe you don't really need a lot of security controls in place. If I'm doing a high-risk activity, maybe you do need a lot of security controls in place. So our policy engine kind of lets you dial it in. Obviously, you can do it at the company level, but you can drill in and you can do things based on groups. 

You can do things based on applications that the person's trying to access or do certain things in. And the way that we roll that up is whenever there's an access request in our platform, our policy engine will send down a challenge. And a challenge isn't just to prove you can permute this random sequence of data, it also proves that you can use a private key guarded by a biometric or a local pin, and that your firewall is enabled, and that your disks are encrypted, and that this value does not exist in your registry or your Plist file. 

And that your operating system version is greater than X, Y, and Z. Like, it's almost anything that you could imagine from writing a hunt query over. You could actually build policy around to really, kind of, in a fine-grain way, carve out different levels of risk and just respond differently. And, of course, the anchor for all of that for us is a trusted execution environment. 

So this last slide is more about like how do we bring it all together? So as of 2016, it's very difficult for you to buy hardware that doesn't come with something called a trusted execution environment. Now, a TEE or a trusted execution environment, it's a categorical term. It's not a product term. 

Different companies have different products that fulfill that nature. The one you probably heard the most is a TPM, a trusted platform module. But there are other versions of this technology, right? Apple's T2, Arm's TrustZone, Intel's SGX, Amazon AWS's Nitro instances, and they all provide similar things. They allow you to create or they provide physically a tiny processor that's isolated from the main processor that you can construct asymmetric credentials in that can give you guarantees about how those credentials are managed across their life cycle, right? 

It's possible to create a credential that can't come out of that piece of hardware, that can't move. And that forms a trust anchor for you to start really doing some interesting things like basically knowing that I'm always talking to the same device. Now, as Roger said earlier, you know, security is a game of raising the cost, it's not a game of absolutes. 

And, you know, there have been some sensational articles over the last couple years about TEE technology, in general, but the really interesting and the simple use case of TPMs at the core, right, which are signing keys, have never really been part of that. 

What I really mean is they provide a really, really strong guarantee that I'm talking to the device I actually expect I'm talking to. They provide an ability to actually do things called taking measurements of the software. So you can say not only prove that the user can access a key guarded by a biometric but prove the user can access that key, and they're running a version of Windows that has been unmolested, that hasn't been modified in any specific way. 

So there's all these sorts of really interesting properties of the TPM. Anyway, we exploit that inside of our platform authenticator, we also exploit the device posture capability, and we wrap all of that up inside of our policy engine in the cloud. This runs today on all the major operating systems. It integrates into the back of your SSO pretty seamlessly. 

If you're running in Okta, it takes about 30 minutes. If you're running a Microsoft solution, it takes maybe an hour or two because Microsoft's a little higher on the complexity curve in terms of configuration management and whatnot. And we support a ton of systems in between those two as well. We've mostly been talking about the workforce solution, but we also can take charge and manage cryptographic material for like technical use cases. 

So, for instance, everyone in software development talks about code signing, and they're really talking about like, is the build artifact signed so I know I'm running something that's genuine versus not genuine? But one of the dirty secrets of development is no one's code that they're actually committing to a repository has any sort of integrity protection back to them as an identity, and certainly not to the device they did it on. 

And so we have ways of actually kind of plugging that hole without requiring the developer to even change their workflow. They just keep typing git commit, and all of a sudden, all of their commits have like a cryptographic relationship back to their identity. Anyway, that's kind of the very quick use cases and kind of how we bring these things together.