Hi folks, Ed Amorosa here. What I want to do in this video, is I want to take you through the basics of the authentication protocol between Alice and Bob, where Alice is the client, Bob is the server. Alice is reporting her identity to Bob and Bob is going to try to authenticate. Fair enough? So that's what we're going to do. The first step in every authentication involves Alice reporting an identity to Bob. It's called the identification step. A lot of times, we just say it's like hi, Bob, I'm Alice. And it might be reporting a user ID, an email, a mobile number, whatever it is. And we've said previously, whether that identifier is secret or not is kind of contextual. It may or may not be a secret. Probably not, but it could be. So let's assume that first step I say, hi, I'm Alice. In the second step, Bob then goes back to Alice with a challenge. So step two is this challenge step where Bob says, hey, all right, prove it please, tell me who are you, prove it. You say you're Alice, I need to validate that, so provide some proof and that challenge step is so fundamental to the whole concept of authentication. Because that's what we're doing here, we're asking you to validate, so that's the second step. The third step are unusual, rather than sort of providing the answer in step three, we're going to call out a computation step, where you actually creating or deriving or doing something to establish the proof. Now, it could be a simple as you looking up your password in your brain, but it could be something more, there could be some puzzle that you're doing, there could be some operation you have to do. Again, you're being challenged and now you're computing the response. And again, it could be as simple as just looking up your password. So that's the third step. Fourth step is the response, that's where I provide back. Alice provides to Bob the response, the proof. You said prove it, I looked it up at this computation, and now I'm going to supply it back to you. Now Steps two and four have a very special relationship because it's a challenge and it's a response. And a lot of times, we refer to an authentication as a challenge-response activity, the kind of foundational nature of those two steps. So that's step four. Step five is a validation step. That's where i'm going to be Checking the proof you supplied to me. Hey, is it any good? Does it make sense? Does it not make sense? What did you give me? And then finally in step six, I'm going to tell you, pass or fail. [LAUGH] Either I believe you or I don't believe you. And that validation stuff's a little tricky, right? because I'm going to be looking checking something, checking your challenge, doing something to see if you did it right. And I'm going to notify back to you in step six. Look all authentication follows this basic schema. Now, multifactor is probably going to be doing this multiple times. But this is the skeletal view of how it works and it's important for students of authentication, students of cybersecurity to have this basic schema in mind. And to think through how one two factor and other things potentially provide an instantiation of this. But for the most part, we'll work with one factor and a lot of the examples we'll do a single factor just to go through this. Now, what we draw in the chart here, is an onlooker who we call Eve, for eavesdropper. It's sort of common in cryptography and in cybersecurity to have Eve be the bad person, Eve for eavesdrop. There's three places that Eve can try and break this sort of scheme, and what does it mean to break the scheme? It means to lie or spoof. If I can tell Bob, I'm Alice, get Bob to believe it, and I'm not Alice then I've spoofed the system, I'm lying successfully, I've broken the authentication process. That's the hack to this. So the first question is, could Alice do this to the client? And we tend to think of the client, the network, and the serve as kind of zones in this, and we highlight them in the diagram as zone 1, 2 and 3. What can Alice do to subvert something like this in zone 1? Well, steal the proof. [LAUGH] Let’s say, Alice is using her mobile or something as a way of authenticating. If I steal your mobile, then I can do it as you. And so a lot of real successful hacks to authentication will include a client. In zone 2, is there something Alice can read sort of in context of the protocol? Can she collect information, read the information that's being provided, and use that as a basis for a hack? Well, it's certainly a possibility. And then third, can I look at the server? Can I somehow do something in the server, read or recompute the proof, or do some sort of a hack? What you're going to find in authentication is that, it tends to be easier in zones 1 and 3 than in the network, because we're going to be using a technique in authentication called cryptography. And that cryptography is going to be designed specifically to make it hard for Eve to collect information between Alice and Bob on the network for the purpose of spoofing Alice's identity, as she validates her reported identity to Bob. Do you got all that? [LAUGH] It's a big mouthful. But you'll see as we go through this, some protocols are really weak, like password's kind of a joke. But as we get into more cryptographic implementations, they get kind of interesting, you've heard strong. Like there are protocols that are extremely difficult for hackers to spoof, both in zone 1, 2, and 3, they really get very strong. It doesn't mean they're always easy to use or cheap to implement, but they can be very strong. So in a subs con video, we'll dig into this schema using passwords as our example. So I'll see you in the next one.
