This video is number six of the Zero Trust Authentication Master Class series.

Transcription

I'm Jasson Casey, the CTO of Beyond Identity. And this is another part in our series kind of explaining how do we overcome the issues that we talked about before in authentication, and we got pretty tactical, talking about password issues, talking about multi-factor issues that were based on possession, weak possession, strong possession, etc. 

Now, what we're going to do is we're going to actually kind of tear down the authentication architecture and rebuild it from scratch, and we're going to rebuild it in a step-by-step fashion. And we're going to focus on how do we eliminate each of these problems and think about the categories of the problems in more of a zero-trust mindset. So just remind ourselves, how do we understand relative to the operation of the transaction, right? 

And remember, in a zero-trust world, we don't look at the world as an outside-in model. We look at it as an inside-out model, right? The world is composed of transactions. Transactions are from assets to resources or from resources to resources. Networks cannot be trusted. Assets cannot be trusted because of where they are in the network. You kind of have to bootstrap trust. 

And so, how do we actually go about doing that? So first, we'll start with authentication, and specifically, we'll talk about the password proliferation problem yesterday. So just to remind us a little bit. Yesterday, we... I keep saying yesterday, but maybe it was tomorrow for you. And the password problem that we're talking about, we had Alice, and we had the bank, right, and you know, Alice wanted to visit the site. 

And there was a prompt to log in. She supplied her credentials, username and password. The site verified those usernames and passwords, and assuming the answer was a yes, then presented a logged-in session, right, an authorized session, right? And when we blew this up yesterday, we basically said, "Well, the username and password is a piece of data, right?" 

And when we look at data, we have to measure data really in two ways from a security perspective, in motion and at rest, in term of understanding, like, what is the surface area of that password, right? How do I actually worry about protecting? We talked about things like, well, really the surface area in motion is about all of the individual connections. 

So in this example right here, we're just showing the connection from, you know, Alice to the bank. But in the real world, there's intermediate proxy servers in here, right? The bank is not really one service. The bank is usually things like load balancers, front-end web servers that may go off and talk to message buses, that may have additional services they're talking to, that may go off and talk to caches or those transparent caches, then front-end databases, and those databases kind of dump into file systems, right? 

So in the real world, each of these connections is an in-motion thing that we have to worry about, and each of these devices is an at-rest location that we have to worry about securing the password. And of course, unless the password is salted, but yesterday, we showed that salting really is a step that happens right here, so I don't really get salt protections in this part of the world. 

But that's fine. The sole purpose really is just to show the surface area of a password is actually quite large from a security perspective. Usability of a password is not great. Otherwise, you would actually use a unique string for each service that you access, and we all know that you probably don't. 

And then, of course, password managers are kind of duct tape on the problem and still don't necessarily present a usable solution. So, how could we address some of these things? Well, it turns out there's actually an easy answer around asymmetric encryption. So just a quick reminder, when we're talking about encryption, there's two types of encryption. 

Right. There's symmetric and asymmetric, right? In symmetric, I have a key. As long as that key is shared by two parties, they can converse or pass messages back and forth securely by using that key to encrypt message. 

And then they send it over here, and then they can decrypt with that same key. Now, there's a key distribution problem. I have to distribute that key, which is not dissimilar from this password problem. 

In asymmetric encryption, the idea here is you actually have two keys. You have an encryption key, and you have a decryption key. And as the name implies, they're asymmetric. They go in one direction. So in that world, if I have a clear text message, I can encrypt it with my encryption key and send it. 

And it can only be decrypted by the decryption key, right? And the cool thing there is now, because I have two keys, from a distribution perspective, I only have to really worry about distributing the decryption key. 

So that starts to actually free some things up. So from an authentication perspective, I can actually use this. Specifically, I can use it in what's called a signature, and I can use it in a signature to actually prove that I possess a thing, which is really, fundamentally, what passwords are about. 

So at a high level, and then we'll come back and dig into at a low level, let's go back to our Alice and the bank example. Alice wants to access the bank. So what the bank is going to do is the bank is going to say...the bank is going to issue what's called a challenge. 

And in that challenge, we'll simplify it, and we'll just say, "You know what, it's just a random string." Random. And then what Alice is going to do is she's going to sign the challenge with her private key. So it comes back over here as essentially random, that random number from here, and a signature. 

And it's a signature over random. And so what the bank can do is the bank has Alice's public key, and the bank can use that public key to verify the signature, that the signature here is, in fact, correct against the public key. And what this actually shows us is only the holder of the private key is able to produce the signature. 

So again, just a reminder of what that might look like from an envelope perspective, right? So imagine I have this envelope and I have that random string, right? Maybe I have some other stuff in there too, right? What does a signature actually look like? Well, the first thing I do is I don't want to produce an encrypted version of this entire payload, right, because that's a lot. 

So I'm going to shrink it down. So how do I shrink it down? Well, I'm going to shrink it down with a hash function. Remember, a hash function is a one-way function. So when I hash this, I produce what's called... you can think of it as a checksum, right? It is a fixed-length value that is a unique point of this hash function over all of this input. Now, I'm just going to produce an encrypted version of that checksum using my private key, right? 

And so that's going to go here, and we call that the signature. And that has the effect of what we call sealing the payload. And what we really mean by sealing the payload is the way we verify the signature, I read the payload, and I can clearly...I know the hash function, it's not a secret, so I can calculate, is the checksum valid, right? 

If anything has been changed, that calculation will be wrong. So it won't be valid, right? And then I have the public key. So I can actually decrypt that signature. And when I decrypt the signature, I'm just asking the question, are these two values equivalent? So what that actually lets me do now is complete this and verify that, in fact, Alice does hold the private key. 

So I could use asymmetric cryptography, specifically digital signatures using asymmetric cryptography, to let Alice, essentially, prove a portion of the authentication step she has a private key. And that private key never has to leave the device that Alice is on. So remember our data in motion, data at rest. 

With an asymmetric crypto, I can take all of the in-motion problems, right? And I can basically just get rid of them, because my private key never moves. Now, technically, there's a few things we need to worry about there in terms of, well, how do I know Alice didn't copy it out or someone's on the machine and copies that off? But let's take it one problem at a time. 

So private key never moves, right? It doesn't have to for this to work. And the public key does move, but the public key is not a vulnerability. It doesn't give anyone any ability to do anything other than verify signatures, right? So I've eliminated it in motion, and from an at-rest perspective. I've drastically shrunk the surface area. 

Because if the private key never leaves Alice's device, I'm no longer worried about anything being at rest through this entire chain except when I get back to Alice. And so that's what we're going to set up next. So really, the point we're trying to make here is when you move from shared secrets or symmetric secrets to an asymmetric form of cryptography, you can actually then use digital signatures as a form of authentication that completely eliminates a huge amount of the vulnerability that exists in passwords and shrinks the at-rest problem, right, the credential at-rest problem, to really one device. 

And next, we're going to talk about how we actually chip away at that problem.