Informal security chat with Beyond Identity's CTO Jasson Casey, Founding Engineer Nelson Melo, and our host Marketing Empress Reece Guida about how strategic friction can be good in multi-factor authentication.

Transcription

Reece

Hey, and welcome to "Cybersecurity Hot Takes!" I'm Reece, a marketing manager, joined today by Jasson Casey, our CTO, and Nelson Melo, our founding engineer and global sales engineer guru. Today, I'm going to come up in here with a hot take that says, friction when it comes to authentication is not a bad thing. What do you guys think about that?

Nelson

I feel like Jasson has been doing a lot of talking about friction lately.

Jasson

Be careful.

Reece

What a frictiony response, Nelson.

Jasson

Let's see. Oh, wow. It's snowing again. Is friction a bad thing? Friction, it depends, right? The wishy-washy answer that everyone always wants to hear. If something of consequence is happening, if someone's trying to move a large amount of money, if someone is trying to turn on or off the dam control, so to speak. Introducing friction just to slow things down and make sure that you are executing the right command for the right person in the right context is not a bad thing.

If the risks are low, if you have strong confidence in all of those items, the risk of the claimed identity, the risk of the device they're operating from, and the criticality of what they're trying to do, then getting out of the user's way is a good thing, right? Like, I think the thread that we were pulling on the other day was security products that don't consider UX or design for the end-users ultimately encourage their end-users to create vulnerabilities and workarounds and defeat the security control to begin with. And I think passwords are a great example of that.

Passwords are also a great example of a high point of friction, which is why, you know, the path of least resistance for end-users is really just to remember two or three passwords and just keep using them over and over and over again in simple permutations. Doesn't really solve any problems for them from a security perspective, but it's easy to remember. And by the way, no matter how those passwords are created, they're probably available on some download off the dark web.

And even if they weren't, it's fairly trivial to phish in man in the middle people as they authenticate into services and then use an MFA. So, friction is a good thing if applied directly, but I do think there's a false trade-off between good security and low end-user friction.

Reece

Yeah. And Nelson, when you're building for friction, how do you think about it as a lever that can be turned on and off? Because sometimes I don't think friction should be a thing at all when you're logging in if it's not risky, like it pisses people off and it alienates them. So how do you code for that? How do you build for those scenarios?

Nelson

It's an interesting question because I was talking to a customer the other day and they used an analogy that I kept thinking about and I think it's pretty good. I live in an apartment and when I'm trying to enter my apartment every day, I just use my key. There's no weird friction associated with that because it's a thing I'm supposed to be doing every day. I'm just going to work and using my key to access my apartment.

But if I'm coming with a bunch of people, somebody at the door in the building's gonna stop me and say, "Hey, you're trying to get 100 people into the building, what's going on here?" And if I lose my key, I don't have access to my door anymore. I can call my wife and say, "Hey, can you come over and use the key?" That's a little bit of friction. But if we both lost it, I have to call the super and there's even more friction associated with that.

So that analogy happens in the real world every day. And it sucks that authentication doesn't use something like that. Just grade the level of requirements you put on any transaction based on the criticality of the thing you're doing and how common that transaction is.

Reece

Yeah. So, with that in mind, how would you guys respond to this statement or philosophy, frictionless by default, but friction only when needed? Do you think that that's something that those are rules to live by, or is it not that simple?

Nelson

I would add a little bit of context, right? So every now and then someone might get confused and translate no friction as in no authentication. And that's not really what we're talking about, right? But with the introduction of modern technologies, like secure enclaves and using local authentication, whether it's biometric-based or local PIN-based to guard an asymmetric key that you then use to authenticate yourself to a remote service, like all of that can happen silently without the user even understanding anything I just said, and provide an incredibly high degree of trust of the claimed identity and the device it's operating from. But it's not perfect, right?

And sometimes you might wanna dial-up even over that and engage the end-user in some way and say, hey because of the thing you're trying to do right now, I just wanna verify one more time. Hey, flash your finger, flash your face, put your local PIN in, do all three, do the hokey-pokey. And then we'll proceed. If it's a risky operation, if it's an infrequent operation, if it's an operation that seems out of the norm for this particular person, then friction's not necessarily a bad thing.

But friction within context of what is the likelihood of the claimed identity? What is the security posture of the device someone's trying to operate from? And what's the criticality or the importance of what they're trying to do? And then friction just becomes a slope given those variables.

Reece

So what are some tactics along that slope? Like, you mentioned PIN, biometric, how would you rank like easy friction versus like, you know, hard friction, asking a lot of the user because the risks are high? Like, what's the spectrum look like? And where's there room for innovation along that spectrum?

Jasson

Nelson, you wanna take this one since you interact with like deployments the most?

Nelson

Yeah. By far, the lowest friction is doing nothing and using environmental factors and stuff, you know, about the device and the identity for low criticality applications. But then you can use a pin, that's a little step up, a biometric is... I'm sorry, the other way around, a biometric first and then a PIN is a little step up. We've seen solutions that try to do some sort of identity proofing and then you have to show your face or take a bio-hash.

We've seen solutions that try to do some government document-based authentication and then use that again when they're trying to set you up. And eventually, you start to get to combining those. So maybe one on the other at the end of the biometric, or maybe you have to be in a certain network to be able to access. Those are the major points I see.

Jasson

And then I would say there's other things you can do that may or may not show up as end-user friction. So, for instance, it's not just about the claimed identity, it's also about the security posture of the device. If someone is trying to retrieve sensitive data, if someone is trying to...let's say it's someone in your service who's a contractor and using a contractor-supplied device, and intentionally they're about to pull down some of your customer's data because that's why you hired them, to help you grow that customer deployment faster.

You probably wanna make sure that the data controls that are expected, that you probably signed up for when you sold that customer your service, are in fact present on that contractor's device, which may actually be a little tricky for you to do, right? You probably aren't pushing your tools down there. So, if you could somehow take that into consideration in a lightweight authentication scheme, you're increasing your understanding of the context, right? And as a result, maybe you don't need to impose user friction.

Sometimes maybe that's not enough and you wanna actually interact some way with what's on the device and what cloud services might know about the device, the device's history, and the person and the person's history. And while those are kind of all queries that don't involve reaching out to the end-user, they can impart a latency on access. So the end-user would see that as things taking a little bit longer to access, which would certainly show up as end-user, right? They're hearing the elevator music for a little longer than they're used to.

But again, you're gaining more contexts to make sure that you can move forward for whatever this end-user is trying to do with the confidence that it's who they say they are and that they're prepared to receive the data or do the thing they're trying to do relative to what it is they're trying to do.

Reece

Yeah. You know, I think it's worth mentioning the memo from the OMB and U.S. government about how agencies are required to use phishing-resistant MFA. I'm sure that filled a lot of organizations with dread because for most people, multi-factor authentication equals friction. So do we see this moment in time as an opportunity to change things up, and what does this mean for MFA friction and authentication at this juncture?

Jasson

So the OMB put out a directive and the result of their directive was they were basically saying most of you need to get MFA in place, and for those of you that haven't... or for those of you that have deployed MFA, most of them are insufficient. And the reason... so the audience of this, by the way, is federal agencies. But essentially, what they're saying is existing access and authentication solutions have largely been security theater. They don't prevent bad things from happening. They don't even tell you when a bad thing has happened. You probably have a bunch of other products to do that. And then you go after the fact and try and figure out what happened to revoke credentials.

What the draft does is it kind of lays out a zero-trust architecture approach. It clearly calls out identity as a necessary component of that approach. And what they're trying to eliminate the case for is phishing and man in the middle and password stuffing and ATO for initial access, for initial login access. There's other things in that document, too, but they're moving at light speed for the government, right? They're saying these agencies need to have this in place by the end of 2024. And it must be in place for all of their internal usage and it should be in place for their external usage. And what it is specifically to identities and access, it really is trying to provide it as trying to nudge people to deploy solutions that aren't trivially phishable, and trivially exploitable.

And when we say trivially, what we mean is go to GitHub, download one or two specific tools with a minimal amount of configuration, i.e. a very unsophisticated level of exploitative capability, start phishing and stealing access tokens from targeted users regardless of whether they're using all the modern SSO solutions with the modern MFAs plugged into them. And we have demos where we show doing this with major name brand SSOs and major name brand MFAs with push notification plugged into the back, right?

And the memo clearly says, you know, the SMS, magic link, email pushes, TOTP codes, like, these aren't real protections in a world where SIM swapping is a thing that happens on phones, phishing with man in the middle proxies, all sorts of sophisticated ways of pulling up the man in the middle proxies to not just get at the credentials, but to actually steal the access token of a valid user and a valid set of credentials resulting in a valid session.

Like, they're basically saying that model is completely broken. You've gotta move to something that can do bidirectional authentication of the client, the server-side of the connection, but somehow ties that across layers in the OSI stack, right? It's not just about the transport channel, but it's the transport channel matches what's going on at the application layer. And there's only a handful of technologies out there that actually support that. And most of them are less than 14 months new in the marketplace, with the exception of the federal government doing things like PIV and CAC cards and whatnot.

Reece

So, Nelson, how would you advise organizations to take friction and MFA into consideration? Like, if you could just say one helpful bit of advice to people out there other than, you know, buy Beyond Identity, something more nuanced than that.

Nelson

Take a look at solutions that are hard to phish. Hopefully, one that graduates the level of friction they impose on transactions depending on what the user's trying to do. Anything that's based on user-initiated actions is typically harder to phish rather than something like a push notification, which can be spammed, or an SMS that can be compromised.

Reece

Words to live by, Nelson, as always. Thanks for chatting this week you guys. See you next week.