Street Cred: Increasing Trust in Passwordless Authentication

All right, thanks so much. So yeah, in this talk I'm going to deep dive as much as you can, deep dive in 15 minutes on something that's been covered a couple times already, which is this idea that passwordless is a great way to provide a good user experience, but at the same time, we really need to start thinking about the security properties, right? What happens during authentication? How do we increase trust during authentication? Where might an adversary go when we've got strong controls on authentication? I, I like to look backwards before I look forward. So 60 years ago, 60 years ago, the very first password debuted, it debuted on an IBM 70 94. So old school IBM mainframe. Also, 60 years ago, the very first password breach occurred on an IBM 70 94. It was like within a couple months people are already breaking passwords, right? And yet we've had to deal with this for decades.
Now, there's been a lot of different ways we thought about this. And historically, in my mind, it breaks down to two different categories. Either we're gonna ask more of the person or we're gonna ask more of the machine. We're gonna ask more of the person in terms of length, in terms of complexity, in terms of rotation, all those sort of things. Today with passwordless, we're gonna ask more of the person in terms of them having their phone available or them carrying a key or remembering to have the key, doing good diligence around their equipment. And of course on the machine, we started early on right off the bat with that IBM 70 94 saying, okay, this is great. We've been breached. We'll encrypt, okay, now that they broke the cipher, okay, well we'll use a longer cipher. Okay, now they're doing rainbow tables. Okay, we'll do salt and we'll do pepper.
And you know, we've got this long history of combating this back and forth. And I think what's important to remember when we get to passwordless is this history of adversaries working around credentials is not gonna stop, right? If we're, if we're to forecast 60 years into the future, if it was 2080 and we're in Berlin and we're in a security conference, they're not gonna say, you know what, in the 1920s or the 2020s, it was fantastic because we all moved to Passwordless and all the problems went away. No, they're gonna keep going. So we really need to think about those security properties now at this early stage when we're implementing passwordless. Real briefly, I want to give like the journey that I see many organizations go for having that path to passwordless, right? We talk about it being a path, we talk about it being a journey.
Here's what I see that journey being. I say this not because it's the only way I say this as a framework for the conversation we're gonna have in the next 15 minutes. So in the, in the beginning, right? We need to establish the multifactor, we need to get the factors in the hands of the people are gonna do it before we start reducing and removing other factors. So we establish those factors and figure out our identity use cases, workforce versus customer within the workforce, privileged versus non-privileged, you know, factory floor medical people versus office workers, those sort of things. We want to consolidate those authentication flows incredibly critical from the perspective of making sure that we don't have to maintain passwordless across dozens of different workflows and different use cases. And then we wanna increase trust and authentication, which is really where I'm gonna spend most of my time on today.
And then enable that passwordless experience and then optimize the tool set and integrate it into our seam and our SOAR and our instant response and our IM capabilities and all the rest of the capabilities. That's the the broad level journey that I see many organizations taking on this. So to break that out and think about some of the risk points along that way, first step of course is establishing that multifactor, right? If you take the most basic view, the most fundamental view that the starting point of passwordless that says, all right, today we have got multifactor and we're simply going to remove that password from the equation. I think that's a good starting point. We all know passwords are terrible. We can talk about are they in the background, can they still be recovered? But I think as a starting point, that lends itself very clearly to looking at all the various factors that are still gonna exist.
Certainly a lot of these factors still have fundamental problems, right? The bypass codes, the SMS codes still have a lot of problems with SS seven attacks and, and interception email recovery, the magic links of a lot of problems. You know, on, on that side, I think I'm not alone to say that was like a early adopter passwordless like 10, 15 years ago, early adopter passwordless. Why? Because I never bothered to remember my password. I would just go to a site I don't visit, hit their password, reset, put in another random password, and I was in right passwordless. I don't need to remember a dang thing. It's a 32 character random string. I can generate that all day long. And that recovery process that I use that so many people use effectively chains that security through a trust chain to your email address. As we look at passwordless solutions that are doing that with magic links and similar, all right, now I'm not doing a reset.
I'm still clicking a button and going into my email to launch it. I think we have a lot of those same fundamental questions in terms of what happens without account takeovers or business email compromises. Because as we trust that email address, when that email address gets compromised, we've effectively undermined passwords. So it really begins when you think about the factor side of mapping out the individual use cases and figuring out what factors are right to be put in what place. Obviously Fido does a really good job in terms of providing a number of different solutions from platform internal authenticators to external authenticators to roaming external authenticators to access devices. They do a really good job for laying these out and giving you those individual options, but at the same time, 5 0 2 oftentimes is only one of multiple different factors that we're supporting in this environment.
So very simple step one, we're gonna make sure that we've got factors in place, that we've rolled it out, that people have the factors to authenticate before we remove the passwords that we've built up in good internal capabilities for resetting those factors, for replacing those systems in the environments. We're supporting multiple factors. We do immediately, immediately run into a source of concern in an area we need to shore up. And that is, and we see this frequently already with established multifactor environments, the ability to downshift factors, right? I I today can log in and I oftentimes log in with my, my YubiKey, my Fido two authenticator. I can log in with that all day long. I can also say, oh, I don't have it. Please use my phone. Right? And in many environments, so you can also say, I don't have that either. Please call me.
So are we really operating at the security level of 5 0 2 at that point in time or are we operating at the level of the weakest factor? Clearly from an adversary perspective, they're gonna try and downshift. So that's one thing to be avail aware of. Be very, very careful of all these additional factors that we know have weaknesses in them. I already mentioned SIM swap, dki, mfa, fishing proxy, like evil engine acts, cloning, a lot of, lot of scary things going on. And I might add back to 60 years ago, right? Within a very short time period, things get broke back to the very first time we encrypted passwords. Within a very short time period, people were, were doing password ripers and rainbow tables. We know that the minute any one of these factors becomes widely used adversaries will work around it. A lot of the concern and conservation today about password evil, engine X and those sort of things, and MFA fatigue was immediately predictable by people like you who are in conferences going, wait a minute, we know where this is going. We know what's gonna happen. And so thinking ahead to say, whoa, it's all right. I've got a biometric. Also means we should be thinking ahead of, in terms of people who do biometric cloning and do you know the types of attacks on the facial recognition that we're already seeing quite frequently? This is one example, if you guys want to to read it. Telos published, how to take a fingerprint off a glass 3d, print it and use it to log into your phone. Fun stuff. Fun stuff.
But is that possible? Yeah. Is it likely right now? No. So we, we really don't need to over-engineer for that. But as we think about the trust that we need in authentication, we need to be keeping an eye on that In consulting workflows. I'm not gonna spend a ton of time on, we know we have a lot of passwords. We know we have a lot of systems that of record that aren't going on. We know, I think fundamentally, and there's a good question earlier about is this an IDP problem or an application problem? We know fundamentally the answer to a lot of that is moving towards single sign on or moving that onto our IDP or doing federated identity. So we want to emphasize that. Recognizing that we're gonna have weaknesses in step one with people with low factors. We're gonna have weaknesses in step two with applications that don't support web authentic today or don't support SSO or don't support strong factors.
And while, and that typical enterprise is running 1400 applications, oftentimes when I'm doing advisory work and say, how many are you protecting through your idp? How many are centralized? They're like 200, 500, right? Which means there's probably a thousand applications that are currently vulnerable in the ways that adversaries can get in. So things to be concerned about and watch for this stage are legacy protocols. Areas where we can't enforce MFA, that adversaries can get at on protected API services, where I can get a session token and pass that in all those unknown applications or unprotected applications that are not plugged into our environment yet. And of course SSO vulnerabilities. If I can't steal a password, can I steal an authentication token? Can I hijack a session? There's a rise that we're seeing right now in phishing that is no longer stealing passwords and that's only gonna increase when everyone has phish resistant credentials.
But rather gets people to click on a button and allow in, you know, OAuth, right? Oh yeah, you're totally trusted to read my account. Those types of attacks we're gonna see on the rise. So where this all lens up is putting more controls around that authentication path. First off, that device trust, which was mentioned earlier, is so incredibly critical. If nothing else, from the standpoint of attack surface reduction, there are 16 billion, billion devices on the planet today. Most likely those 16 billion devices can log into your external services. If you're a workforce with a, you know, 10,000 employees, you probably have 20,000 devices. Just getting from 16 billion down to 20,000 is an incredible attack surface reduction, it's even better if you say, I only have two and only I can log in with these two credits. So that device identity is critical. And then behind it, doing good analysis of the behaviors.
So there's two ways to slice this. First is the traditional if and else policy sets, right? We know we should be looking at whether or not a device is is known or trusted. Does it have an MDM agent? Does it have a certificate? Is it domain joined? We know we should start there so we can do that at tech surface reduction. There's additional factors and when you're looking at passwordless, you can evaluate them. What else can we slice and dice? Can we look at the MDM to say, what's the status of this device? The os, the hygiene of the device. Can we ensure it's not jailbroken, not infected, right? Those those things we know we should not trust and we want to start wrapping those in so that we can go ahead and make sure the adversaries are not working around them. One of the incidents a few years ago that I was involved with had to do with a bank theft.
The adversary got on the end user's computer, infected their computer, they didn't have good endpoint protection, just lie and wait, right? The accounting team had a good password, they had multifactor, they're doing everything right. They just waited. The adversary just waited for the person to get on that computer, log into the bank. Everything else was good. From an oth perspective, we're golden from a security perspective, not so much. The second part of this is that application of ml. I'm a big proponent of ML after the fnl, right? If we can eliminate everything we know should not be in the environment, then run it through an ML environment, I think we have better signals of truth. I don't need chat G P T to tell me that I should not allow a jailbroken foam, right? I think that we can, we can just codify that. We can avoid all the the guesses.
The other thing is I think when we apply ML to this, we need to apply ML not as this ubiquitous environment that's ch looking at all the actions that's checking everything, right? This robot that's sassy and making our meals and and pushing around a vacuum cleaner rather, we need to look at it in terms of a very purpose-built ML environment that is looking at very specific items. The larger the ML application, the longer the training is, the more brittle it is, the more false positives. If it takes three months or six months or 12 months to train your model, it's not gonna keep up with your business. And oftentimes it's going to create a lot of false positive to rife through. So look for ways that MO is very specific, purposely built to look at the devices, the authentications, the actions, and build on top of that to reduce the risk.
I think about like the pyramid of pain, right? We effectively want to use all the rules to get rid of the low stuff, reduce all the noise, and then apply the ml. All right? Then we get to the passwordless experience, which again is not something I'm gonna spend a ton of time on. We're gonna take these pieces, we're gonna snap 'em together. We're gonna look at where people are using multifactor and behavior analytics. Remove those passwords and give them better experience supported by strong platforms, device trust, behavior analytics, and adaptive policies. So in conclusion, when we think about passwordless from an English perspective, right? We love to add less to innovation. What are we doing? We're removing the password. Password less. A hundred years ago, I'm from Detroit, a hundred years ago, high tech and Detroit was a horseless carriage. What is it? It's a carriage without a horse. Does that describe cars and all the innovation we've had and health and safety and everything? Absolutely not. But that's how we thought about it. A horseless carriage, you would think that automotive would've learned that. But of course now the big thing is driverless cars.
We make the same mistakes again and again. And we know that with passwordless, if we just think about it in terms of removing the password and not in terms of increasing trust, we're going to end up in a situation again where adversaries are able to break in and move around and compromise. If we focus in on this moment in time to shore up behind defenses, we're gonna be in a much better spot. Thank you very much.
Thank you. Welcome. For such an interesting presentation. I don't think we have downtime for questions, so we will just proceed with the next session.