 All right, folks, I'll be five minutes of homework questions, and then we'll get to the next thing. What are you saying? I got to this step, I turn in the key, and it gives me this. And you say to download, how do you download this? How do you download the key? I turn in my gbg file, and then it gives me my public key and my adversary key. And he said to download that, but I couldn't give it to him. Well, you have the key you're looking at, right? Yeah, and I say I backed it out of it, but just like a text, but that's not like... How's that not the key? That is, oh boy. So that's it. You're saving it as a text file? Yeah, it doesn't matter. I thought it was a gbg file. It is. That's an ask-it-or-gbg file. Okay. Yes, so you can copy that to your computer, you can do files saved as, saved as, whatever you want. But yeah, it's a good question. Other questions? Yeah. So, if you're trying to get something signed, you have to save it. That's good to say. You're going to separate people. Okay. And they will sign it. Yeah. How do you know if they're going to sign it? They have to send it back. They have to send your key back to you about their signature. Is there a way to work those two texts? Yeah. Yeah. Yeah. Hey folks, do you want to help them out more? Or do you want to talk to each other? Thank you. Is there a specific key to the command that will turn a Harvard file back into the, what are you calling it? What is the version of the file? Why? Because it's easier to get information from that version of the file. You just import it and then you can export it however you want, right? So your key ran past all your keys. So when you import it, you take a key in and you can export it as correct, exactly. You can also use gbg to interrogate that key to tell you something you need to know about that key. Okay. It adds a new signature to your public key. It doesn't fundamentally change your key, right? When you have your key, which is always the same, your fingerprint change doesn't have to be the same. When you have additional keys to metadata where everybody attests that they trust and they sign to it. What does it mean by key rings? Key rings, the key ring is just like a gbg concept of you can have as many keys as you want, right? So when you're on gbg, you can have as many keys that are your keys that you actually own. All the public keys that you import go into this long key ring. Yeah, just like the concept of literally like a ring of keys. Yeah. Can you or the TA test? It's from other students in the class. That's part of the assignment description. Yeah, you actually have to talk to each other. Words. People. That's like on minute 20. That's all the questions. And so for signing fake keys, is it such a long fake key that you lose 10 points in the lab? No. Right, that's it. Okay. 10 points of your score are based on not signing fake keys. Okay. If you sign zero fake keys, you are guaranteed 10 points. Okay. So it's not like all of them? Probably not. So if you don't do the assignment at all, then you sign no fake keys and you get at least 10 points. I do not have that happening. I guess technically yes. But yeah, I don't know. Don't play yourself in that situation. More questions. Yeah. I mean there's a link on the assignment description to the server's key. You should download that. But you can look at that, right? Import that in your key range. You can look at what the submission server's key is. You can see all the things about it. The fingerprints of the username. I think it's something just like CSE 365. Oh, right at the buzzer. All right. Yeah. But given the public key. Yeah. I'm assuming that has the person at the end of the step. Maybe. You tell me. Okay. So we're going to... So we're going to type in the public key and decrypt it. We're going to get the name and verify it's actually the number. Before you sign it? Yes. Right. So you can download. You should be getting their public key, right? You import that in the GVG. That doesn't mean anything. You have to actually take another step to sign their key. Right. It will show you everything like key ID, name, email, all that stuff. It's up to you to verify that before signing it. Once you've signed it and then send it back to them, then that's on you. Yeah. Can you unsign that key? No. Yeah. If someone sends a signed key back to you, how do you import just their signature? Or do you just override it all the way? It doesn't override it. It's smart. It just adds any new signatures that is present. So it's important that it's smart. Okay. Cool. All right. Cool. Now let's move on to the new stuff. So now we're going to talk about authentication. So what are these? So we've talked about in the past this concept of authorization and authentication. So what are the differences between these two concepts? Okay. So authentication is trying to verify somebody's identity, right? I say, who is this person? And authorization is what are they allowed to do on your system? So what are some types of authorization enforcement things that we've looked at? Group permissions in Unix. So like file system permissions in Unix? Yeah. Access control lists. Access control lists, discretionary access control, mandatory access control, originator, is it controlled access control or originator access control? Right. So you can think about these as, just like you said, answering these two questions of who are you and not in like a philosophical sense, but more in the sense of what is your identity to the system? Right. And authorization is what can you do? So this is the core idea that we should look at. So you have one without the other? Yes. Okay. Yes? What? So it must have lots of yeses and all of that. Yeah. I mean, you're just like, you could say someone is who they are and you don't want to find it. Some specific thing to verify is who they are. Okay. So you could have a system that has authentication of knowing who is who, but not actually restricting what anybody can do, right? You can have a system that doesn't check who you are, but limits what people say they can do. I'll pose a question in different ways. Any of these useful to securing a system on their own? No? Why? Why no? Because it doesn't matter who is authorized or just a matter to have a list of who is authorized to do what, if anyone could be any one of the panelists. And in the reverse, it doesn't matter who they are because you don't know what they're allowed to do it. Yeah, they're not restricting what they're allowed to do and they don't even send who they are. Although, you know, this breaks down slightly, right? So something like, let's say Wikipedia. Can you do stuff to Wikipedia that doesn't require authentication? Is that breaking the security of Wikipedia? Or are there all leaf hackers? You can go to the edit page. Why is that different? Okay, maybe afterwards somebody verifies the information that you give. Sensitive pages can be locked down by administrators and you actually need to know who you authenticate and administrator. So I was a little excited because I understand that if you put some nonsense on there, someone else will probably change it. Hopefully, somebody will change it. If you put nonsense on there. Any other thoughts? Technically authenticate through your IP address. Actually, is some form of authentication in the sense that they know your IP address, your authorization is as a guest, right? So they're not authenticating your identity to the system. You're essentially a guest on the system and I would also say they audit, right? So there's a log in the edit list of, even if not what person, what IP address, at what time made what changes. So somebody could easily reverse your changes, right? The other way to think about it is this is core functionality of Wikipedia. You don't have a wiki if everyone can't edit it or at least the Wikipedia side. Alright, so we're going to study different types of authentication. We're going to look at kind of what that means and how we... So what's... Before we get into kind of all these details here, what are some authentication systems that you're familiar with? Your username and password. Your username and password? For what? To what? Like sending to those websites like e-mail or AISMI ECU. Yeah, okay, so let's use e-mail, like Gmail, right? So why is your username and password important there? So you can access accounts, but how do they know that those accounts are your accounts? You would be the only one that knows that password. You would be the only one that knows that. You created it when you first created the account, right? So they're linking that account creation step and on their side they create some account. And later on when you try to access it, you can give them that same password that you originally had when you created this account. Cool. What other authentication systems do you have? Some sites is like a six-digit code that they'll send to your phone. Yeah, so sometimes some sites may send codes that they send to your phone over SMS message. Yeah. Token-based. Token-based in one sense. Oh, interesting. Okay, so yeah, so you could log in once. Yeah, it's kind of sometimes generating a unique next password every time you log in. They give you your next password. Next time you log in, you use that password and they give you a new password. What other styles? Biometrics. So fingerprints, right? Face recognition. Anybody have a phone that recognizes their face? Or a computer that recognizes your thumb print? These are all different ways of authenticating trying to see who a user is. What about something like, how do you share, let's say, files on... Wow. Yeah. So how can I share with you a file that's on my Dropbox? You send a link to my email and you're assuming that email is my email and nobody else has access to it so that you have a person access to it. Right, so I can generate on Dropbox or any of these cloud systems a link to a file and I can share that link and anyone with that link can then now access this file. So I'm not necessarily authenticating who you are but you can access this file with this link. Okay, this makes sense. So we are going to define some terms. So we first, in terms of talking about authentication, this will allow us to compare and discuss different types of authentication systems. So we'll talk about password-based systems, two-factor authentication systems, all these different types of systems. So we have the principle which is a unique entity and an identity which specifies a principle. So the key difference here is that a principle is the actual, unique, whatever entity in this case using entity, it could be a person, it could be a program, it could be a process, whatever. And the identity is inside the system, right? So you are who you are, when you're accessing your Gmail account, Gmail is linking your principle with their identity in your system of your email account. Yeah, so the key is in this internal representation, right? So each of you can think about, like, you all have ASU ID? Are you that ID? Is that your person? Is that, is an ID? What is that ID? Yes, it's your representation inside ASU's system, right? It's just a unique number that uniquely identifies you in their system, right? So in that case, you the person or the principle, your identity to ASU is your ASU ID. Similarly, the same thing with, you know, email accounts will have an identifier, all these kinds of things, right? Some uniquely for the system to identify you. So we have a subject that acts on the system on behalf of the entity. We'll see more clearly how this works. And the key thing we're talking about here is authentication essentially binds an identity to a subject, right? So that says, okay, this user, so the subject here would be the user acts like your browser, right? The browser again is not actually you. It's a software program that's running on your system. You access my ASU, right? And then the authentication system binds your identity, your ASU account, with your web browser depending on the information that you give it and how it authenticates it. Okay, and so we've talked about a different, so we've actually talked about a lot of different types of authentication systems here. So let's kind of bring it down a little bit. So what is, so when we talk about a password, right? So what is a password actually checking? We're going to retread it a little bit. Right, so it's some secret value that only you should know, right? So a password should be a value that it's checking that you know something. So is, wow. So, and this is different ways of thinking about different authentication methods of something that you know. And there's kind of an implicit requirement here. Should it be your name? Should it be the name of the account? Those aren't private information that only you know, right? So in here, in here is the something you know, comma, that nobody else knows. And again, so why is a password, think about it, why is a password something that you know and other people know? Because it's unique to you. So it's unique to you? Or why is it unique to you? Well, the decor was that you don't share it with people. It's supposed to be secret. Yeah, so you created it, right? Inside your brain, you created some password. You remembered it in your brain. And then later on, they asked you about this piece of information. And if you haven't shared it with anyone, and nobody else has stolen your password, every type of data, whatever, it's something that only you should know. Now, how does this break down? Yeah, so social engineering, which is kind of a theme of your homework assignment, right? So if somebody tricks you into you giving them your password. Oh, I should have done this earlier. By the way, maybe I'll post something out later too. Ground rules for the assignment. So no actual breaking into anybody's computer. No physical harm to anything. Okay, set those ground rules that everything else is fair game. Alright, so don't commit any computer fraud, and don't commit any physical crimes or fraud. Alright. Okay, I'll re-close this. Okay, sorry, I forgot about that. Okay, so, now think about those other ways that we talked about of authenticating to a system. So for instance, receiving a six digit code over text. Is that, what is that actually testing? Yeah? You're in possession of the phone number, right? It's not testing something that you know, right? Because this code, you don't know this code until you get the text message. Right? But it's testing that you own a device that can receive text messages at a specific phone number. Yeah, do you have something to add? It does like fingerprint involved in that possession. Almost. There's a split of a difference there. We'll talk about that in a second, right? So, and this is kind of broadly this area of what do you possess? So what do you have? Right? So that could be a phone. Anyway, I have two back-up notifications with my ASU. You use Duo on your phone. So what does that do? Somebody walk us through what happens. Yeah? Right, so you log in on your computer and then rather than a text message being sent, they send a push notification to your phone that you have to accept on your phone that allows you to log into the system, right? So this is testing something you possess. You possess a phone where you've already logged into the Duo app, which is not the website that you're logging into on that device. But it's testing that you actually possess the phone. What other things would it be able to do, things that you possess? So a government computer to have a card? Yeah, exactly. So government computers, you may need a key card, also corporations. When I was at Microsoft, you had to use your key card to access the VPN. Yeah, I can't really say the CAC is that the name of the system. Yeah, so your card, also, anybody who used two background notifications on Gmail? Yes, well you should answer this class. So I can show you here. So this is a bunch of randomly changing the Google Authenticator app. It's a bunch of randomly changing codes. And I can freely share these to you because they update every minute, 30 seconds. And even if you have one of these, it's only valid for that 60 seconds. And a new one is generated that's completely different from this one. It's similar of a UB keys or RSA keys, if you've ever seen those, that have randomly generated numbers so you try to log in. Some banks have this where you log in and you have to prove that you still have this physical device because there's some private secret data there that's shared between you and the bank that they can verify that that's actually that device. This is again verifying that it's something that you possess. Another example of this would be you can, it's actually kind of, well, it can be a security vulnerability, but you can authenticate and unlock my computer by kind of my watch. So the watch will actually unlock the computer, so it's not authenticated me, right? It's not authenticated. Something I know is that I'm possessing this watch. You do, yes. So that's, so there's multiple things there, right? That way if you can't just rip, if you ripped off my watch and then tried to go and open my computer because the watch auto locks when it's not on your wrist or it detects that it's not on your wrist, I suppose you could cut off my arm and then quickly go, but I will just give you access to my computer if we're ever in that situation. Okay, so what's the difference between, let's say, the what you possess, right? Like a text message to your phone to prove that you have that phone number. What's different between that and your fingerprint? Something that you have versus something that you are. So like somebody else could take your phone, but they can't necessarily take your fingerprint. Yeah, or I think about a different way rather than taking, I would say that the difference is not can you change it, right? So when you change your fingerprints, I mean you have 10 of them, but after 10 you're kind of, I don't know if the toe prints work, but maybe those are a thing, right? So the other thing that we can think about is what are you, like what are factors of you, right, that are supposed to be unchangeable. So what are these types of things? So we talked about fingerprints. What else? Retina. Retina, so like a retina scan of your eye, which I've only ever seen those in movies, but allegedly they're real. I've heard they're real devices. What else? Yeah? Your veins. Your veins? Yeah, because they scan your whole head, and it's like a x-ray. Whoa, that's good. Okay, veins are a hand, I would say. Or generally, yeah. The structure of your face in terms of like the face recognition systems, right? Can you just easily change your face? I mean, you can, but it would be very, very extensive, right? It's more of a what you are than what you possess. Have you ever seen the movie Face Off? I have. I'm just saying this is a real one. Yeah, so, and so this is another aspect, right? We can see how this compares. It's not something that you know. Your fingerprint is not something that you know. You can't just like, I don't know, write down your fingerprint, right? It's not a secret that only you know. It's something that you have that you can put on a fingerprint or a fingerprint. Yeah. So, what's even got to do with you, though, is I still feel like it could be something you possess, because for example, if someone were to take a fingerprint by scanning into their system, they could easily make a replica of that fingerprint that worked on a fingerprint. Or, heck, the face scanner, or at least the ones on red to the lower end stuff, you can hold a picture of the person that was in that mode the most of the time. Right, so this gets into more, that's why I wanted to not do it on mode. It's more about how easy is it to change it and get a new thing that you possess. Right, so with a phone, if I lose my phone or whatever, I can just get a new phone and say this is not a phone I possess, or a new UB key, those type of things, right? I can get new devices. I can't change who I am necessarily, easily. And which become the problem if it's stolen, right? So, if somebody steals your fingerprint, sure you can deactivate it into the other ones. And there's problems with all these methods, right? You know, they try to do crazy things, like, so to go off that analogy, the first face authentication, you could just easily, literally print out a picture of a person and just put it up to the screen, right? And then you could unlock their device and authenticate as them. They got around that by trying to do what's called liveness detection. So this is a whole area of how you tell that that thing you're looking at is alive and not a fake piece of paper. So they developed this basically by kind of looking at the eyes and seeing if there's movement. And so what they were able to do is you print out a picture of the person's face and you just put little black dots behind it and cut out the eyes and then you move those black dots a little bit. It acts like the eye's moving and it logs in. Or, like, I think the iPhone now, I want to say, does like 3D reconstruction of your face using some crazy sensors, right? So you can tell the difference between a picture that you hold up and the actual person. But then I could take a picture of you and create, use a 3D printer to create a 3D version of your face. Yeah. I know in the settings, like on iPhone 10 at least, there's a setting you can toggle called like require attention or something. So I think it feels like a security concern and you can just like fold the phone up to somebody who's like sleeping. Yeah. So the required attention is really cool because, yeah, and that's other bypasses, right? Of like making sure the person actually wants to unlock their phone. So that way you can't just hold the phone up to me and it will unlock. This was, I know, a problem in our lab at the PhD with fingerprint unlocks of phones. Somebody falls asleep and you'd unlock their phone with their fingerprint. With the faces. So then the arms race to detect lightness of faces try to look for the like blood vessels in your face to see if those would like pulsate lightness detection. Of course you can also fake it. So you can look up a bunch of cool research that I've done on this kind of cat and mouse game of deciding, for a computer system to decide if your face is alive or not. But for a lot of people, the benefit, you know, if the alternative is you either have a passcode on your phone or you don't, like you don't have any passcode or anyone can unlock it, or you have facial recognition where your phone is actually locked and encrypted. Even if it's bypassable, it's probably still better. In my opinion. Okay, are these the only three things? So anytime we want to authenticate to a system, these would be the three things. I think you could say like where you are. Where you are, why? I have the ASU two factor authentication. I can have it in my work computer. Okay, cool. So yeah, so you could, okay, that's an interesting version of where. So yeah, you could say where are you in terms of, has this subject authenticated before? Exactly. So yeah, so your physical location could actually change your authentication. It could be where are you in terms of using credit card? Yeah, so it could be different ways. It could be an internal IP address that's only accessible inside the company. It could be an external service that's limited by IP address. You have a whitelist specific IP address that's better only visible there. Yeah, the last place you blogging was in Arizona, but the IP address maps to somewhere in the United States. Yeah, so it could be different ways. It could be an internal IP address that's only accessible inside the company. It could be an external service that's limited by IP address maps to somewhere in Eastern Europe. It's probably not the same person. Yeah, so Gmail uses this, and we travel internationally and use Gmail, and it pops up like crazy warnings of like your machine's been used in whatever country you're in, and yeah, those are real things. Yeah. Could you type in like behavior, like if you're using the credit card example, like what they're buying and stuff like that? Yeah, okay, so behavior, and we're kind of, hey, I put that more under what you are, or maybe it would be more of what you do. So you could do things, and people have done this of developing systems like with your phone. You could try to develop some kind of like fingerprint of how you type on your phone, and so you could tell if somebody else picks up your phone and starts typing. It's different, and so you can lock the device if they detect weird behavior. There's also, they've done things with phones like the gate, like the way that you walk is relatively unique, so you can learn that from a person. So if somebody else picks up your phone and starts walking away, it would automatically lock itself in that case. Yeah. And then look for just now, like when you're getting into your brain signals. Yeah, is that sad if you wouldn't be able to? Not enough. Not enough signals to unlock. Yeah, so you can kind of also, what are you, right? What are you in terms of brain signals or EKGs or whatever kind of craziness, right? And so A, it's important for a kind of multiple reasons. A, this is how we, in security, this is how we think about different types of medication mechanisms, right? It probably falls into one of these buckets, and so we can start thinking about this in terms of what are some of the pros and cons of different types of things. So let's talk about what are some of the benefits of what you know. You've been using passwords for years. You don't think there's any benefits. Yeah, so it's something that only you know, right? And so in the security sense, it should be very good in that nobody else should know this password, right? It has to be really to share passwords between things, because in my life, I mean, I've literally been like hundreds of passwords, and I don't make them in one every single time. I have a set of different ones that I use for different things. Yeah? Yeah, or Netflix, or any of those kinds of things, right? So a password, so can you share your fingerprint with somebody? No? What's this to say no? You can add somebody else's fingerprint as a way to add anything to your account, but you can't fundamentally share your fingerprint with them and just clone it into that, right? What if I can possess, again, somewhere, then you can't physically own the same device, right? To make you share a device that you give them, whatever. So yeah, in that sense, there's a lot of benefit to a password that you can control who you share it with. It's actually very similar to the key idea that we talked about a long time ago of getting into houses, right? It's like, if key is nice, you can copy it and share it with people, but it has a lot of drawbacks. So what are some of the drawbacks that I know of, of what you know? Not password specifically, but... Yeah? Do you think passwords are something you want us to create or any things that are easier to remember? Yeah, so the problem with... Well, okay, so another way to say that is your password needs to be something that you can remember and that is difficult for other people to guess. All right, if my password was my name, that would be a very bad password because that's something that you could easily guess is my password. You could forget knowledge? Yeah, ooh, forgetting knowledge, interesting. I won't make you do it, but... A lot of people have asked me to reset their password on the submission site, right? So this is a very, very example. So some of you get passwords talking about how difficult it is to remember passwords, or how you'll always remember your password forever and ever as your new passwords. Yeah, so kind of on that subject, I'd like to remind you that if you've got like a bunch of different passwords, you've likely gotten them written down somewhere, and so you'll be accessing that. Right, so then the counter example, and this is... Is this in Ferris Bueller's down? No. Oh, maybe this is interesting. Yeah, so the problem is, okay, so then you know if you forget your password, you can't access the system. So what do you do? You write it down somewhere. So if there was a sticky note on my laptop here and a password to this computer, is that very secure? No. No, it's probably better than, you know, I don't know, there's... better than having a password to password, right? But still, it's probably not great because it's working. Cool. Okay, what about what you possess for some browsing cons there? Oh, possess, not R. So possess would be device. Oh, yeah. Well, I mean, if it's a device, it's a lot of the time you use it. Are you? You ever lost a phone? Yes. Have you ever lost a phone? Well, that's like the central word for me to forget. Okay. Yes, that was a fair, a fair concede kind of thing. Yeah, but on the flip side, I can't give you my phone. Right, it's hard to share. It would be hard to share, in that sense. Yeah. Sometimes you might not have the thing you use to authenticate with you. Yeah, so you may not have, you may be in a situation where you need to authenticate to the system and like you've either lost your phone, you've left it at home, you've, you know, whatever, yeah. Key card in a way. Mm-hmm. And it's just like, say you're trying to get access into different departments, you have these key cards you don't have to remember to pass them. Right. But the cause of that is something easily stolen. Yeah, and if somebody steals it, that's all they need is that device to access the system, yeah. Yeah, so like that, it has to have some sort of physical component. Mm-hmm. It's like, well, you know, you could write it down, if you don't write it down, you know, physical component would just be stolen. Right, so there's actually a really interesting dichotomy there, right? It's a physical device where you can steal it. But on the flip side or the password, if it's all in your mind, there's not always a way for somebody to steal that, although they can convince you to reveal your password, right? If you're sharing your resource, it's like a physical key, and you'll lose it at the moment so like, maybe replace that with a key. Ah, yeah, so, which actually I'd say is similar in some sense to a password, right? If you lost control of your password and had to change it, you'd have to tell everyone, but even worse, sitting in the terms of a key, right? If you're losing, like, oftentimes, apartments may have a key to the front door and then a key, different keys for the individual doors that if somebody loses the key to the front door, you have to re-key it. Everyone needs a new key. It's a pain. Cool, okay. So, that was your discussion. Let's move on a little bit and start thinking more formally about these systems. So we're going to think of an authentication system as some function or method. Again, here we're talking a bit abstractly. So we're going to talk about A is the capital A is this some authentication information that proves somebody's identity on the system. C is some complimentary information, so something that's stored on it and used to validate that authentication information. So we'll see what this kind of looks like in real systems. F is a function that maps between them, so very simply, some kind of function that maps from authentication information to complimentary information. L is the function that actually verifies the identity, so that it takes in the authentication information, all of the complimentary information, and then says true or false, so authenticate or not. S is just some function that allows somebody to create or alter information. So this will be changing your password all these kind of things. I know this is very, very abstract. Let's think of a simple password system where the passwords are stored in plain text. So what does that mean when I say the passwords are stored in plain text? Yeah. Can you just open the file and read it? How do you do it? Can you do it? Yeah, so you're writing a system. How would you write a system that authenticates you based on plain text? How's your store in plain text being in plain text while you use just to pair up those two things? Yeah. So you could all write this, right? An authentication system that was a plain password, right? So somebody, so you have to have some way to register a new user to your system. You take a username password, you store that username password to a file or append it to a file, and then when somebody logs in, you go through all the entries in your file and says, does this username and password match? If it does good, you get access to the system. So we could model that using this framework we just showed. So here, so what would then be our authentication system? So what would be the A, what would be the things that users authenticate with? Yeah. Is there a username and password? Yeah. A username and password will focus just on the password right now. So we'll say it's a set of strings that can be used for passwords, right? So you, have you ever tried to use a password on a service and told you that you couldn't use those specific characters? Yeah. Very annoying. This is actually very bad for security, but it happens. So then what's the complementary information? So what information is stored by the system in order to verify this? Yeah. A username? A username and password. A set of all used strings. What was that? A set of all passwords that have been used. Yeah. So the set of all passwords, so, which is the same set, right? So this set, so all the strings that we use for the passwords are exactly the same as our complementary information. But f is not by a bunch of different sets. We'll see why the set makes sense. We'll look at this common, this function is f. So what's our test? So how do we test if a username and password is correct or the same? If the password given by the user equals the password in the database for that user. Yeah, perfect. So it's just an equal function, right? Quality. We just want to see are these strings exactly equal of what the user gave us as their password and what data we've stored in our system to check them. And we got some functions to set and change passwords. Okay. So what's the problem with this? Is it's access to where you're storing those passwords? People know everyone's password. Yeah, so we already stored this password, right? So let's say it's a website you're making, right? On the server. On the server. It has to be on the server, right? In order to check if people are who they say they are, all your passwords must be stored on the server. Can you guarantee that nobody else can ever get access to your system? No, it's happened all the time, right? So there's a lot of technical facts, office of personnel management, all these companies that have huge target credit card processing companies, hard-lived payment systems, and there's a ton of these companies that have had breaches where people have had access to their systems and their servers. So then if all those passwords are stored in plain text then when somebody breaks into your system what can they get access to? Every single password of somebody who is breaking into our system, what other threats do we need to think about? If you're trusting the administrator or the server? Yeah, who else can access the administrator of the server, right? And do you want the administrator of the server to know all of your passwords? Thinking about going back a little bit, right? So what can, I mean, is that really a problem? I'll play the devil's advocate a little bit. So the user names and passwords they are the administrator's system, they control the system, they can do whatever they want as any of these users. So somebody gets access, so now not only do we have to worry about people breaking into the server but also the administrator's account, yeah. So does anybody use the same password on more than one site? So your user names are email addresses, right? So I'm an malicious administrator, I go through all of my username passwords, my email addresses and passwords. What account do I want to get access to? Bank account, I actually don't care about your bank account. Yeah. Email. Email, why email? Because I can get access to everything else through a setup filters to silently forward every email you get to their email account or to an email account they control at which point you've completely lost control and secrecy of your email. So I go through I can see what are all the Gmail user names in your account. I can see all the passwords and I'll just try each of them. Is it likely that one of your users is reusing their Gmail password on this random site? Yes, and so this is another threat we need to consider is the threat of not just somebody breaking into the server, but an administrator or an employee who goes rogue and has access to these data. Yeah. On the same sort of note, okay, you can say, although I trust that Google is pretty secure, like probably people aren't able to get into that, they don't want a really big site. Somebody might be able to get into that site and get that password of, okay, I'm going to try this password back at, you know, their email, which is, as you said, more valuable than to reset everything. Yeah, so we'll have a full discussion on that in a bit, but but first, I want us to realize that this is what we're going to talk about ways to that users can kind of use informant and mobile effectively. Yeah, so another interesting thing is, so we talked about cryptography, right? The whole point is to keep the communication between two parties secret, right? So if there's somebody listening to you logging in with their username password, then what can they do? Yeah, steal your username password and log in as you. And does the system have any way to know that it's not you? We looked at crypto before looking at authentication, so we did realize that we need some cryptographically secure mechanism to talk to the other end. So this is why in the real world we want to make sure that you're logging in over an HVPS, basically always. Yeah. All right, so what about verifying the addresses for a while? They might not be able to log in although if they're, let's say, if they're in a position where they can man in the middle of a traffic and they're in between you and the other system, it's highly likely that they can impersonate your IP address and log in as you. Or the way this usually works is rather than getting on the network in between you two, you downloaded some game or some game crack or something on your computer and now they're on your physical device. So rather than stealing your username password setting first, you can even do things like they try to fingerprint browsers. So they try to, like websites will try to see what browser are you coming as, all this kind of extra security mechanisms. So sites that steal your browser information will then or sorry, sites that try to fish and steal your username password will record all of that fingerprint information so they can recreate it later. The other way the other problem with IP addresses is how often is your IP address set. Yeah, so it changes when you use Wi-Fi, so think about your laptop, any mobile device like a laptop, a phone, these kind of things. Every time you connect to a new Wi-Fi network, it's going to have a different IP address so you can log out of all your services so it's actually just a real inconvenience for people so most sites don't have a password. Yeah, that's a good point. Cool. Okay. Think about maybe like a system like not necessarily well, we talked about web, we can talk about a similar type of authentication system in terms of like a shared multi-user system like a Unix-like system, right? Or everyone to read. I'm clearly too bad. So what's the solution here? Have a better C? Well, technically we could get better F, I think. Oh, sure. Yeah, or a better C works. Okay. So basically the core problem is the fact that we're storing in all of the passwords in plain text. So our complementary information is exactly the same so we don't want to do that. So let's say we store nothing. We need to store something, right? So what do we store? Encrypt it. So encrypt uh, okay, so take the the password when they log in encrypt the password encrypt it with what? I just feel like some cypher on it that causes it to not be the original message. Do you use some cypher types? Sure. But encrypt it on a lot. Like with what key? Yeah. The username? Okay. So take the username and password use the username as a key to encrypt the password store that. So and then we store the username database and so when they log in what do we do? So they log in now with username and password. What do we do? We compare it with the cypher uh, like the cypher type that we have on the database with the cypher. Yeah. So I can recreate this. I can rerun this operation. I have the username they're doing me. I have their password. I encrypt the password with the username. I create a cypher and I compare it. If they're equal, I let them in. Okay. Cool. So now I've stored in my server everyone's username and cypher. Now you break into my server and steal all of it. Yeah. Wait. So yes, let's think about that. So you steal all my username and cypher. Can you steal everybody's password? Yeah. Yeah. Why? Because the key on the site is what they use. The username is the key. So you use the username to encrypt that cypher and then you find out where it's password. You do that for every individual user. Just for the cypher like assuming that's sufficiently unique enough encryption systems where you aren't going to have another combination of key or username and password that would come out to the same result. Can you then just store the cypher and just combine to make one of these things? Well, you need their identity, right? You need your system to have some way to say what is this user, right? So the user name just maps the name that they attribute to your internal identity of their user identity. Okay. So you need something. Should we instead of using encryption just use a hash to store the password? So instead of encryption use a hash. Well, let's let's pause that for a minute and let's keep going with this encryption idea, right? Because so the problem here so the problem here is using the user name as the key, right? Everyone agree? So what should we use as the key then? Password you need to the server like the admin password? Sure. Yeah. So let's generate some new key K some random good key that we use. So now we use AES on the key K along with the password and we get cybertext and we can store now in the database we store user name and the cybertext, right? What do you store the key now? So where do you store the key? If it has to be on my server somehow because I need it to create users and I need it to login users. So this has a slight benefit, right? In the sense that if somebody just were to steal my list of user names and cyphers they now shouldn't be able to easily decrypt the cypher because they don't have the key. The problem is in this situation let's say somebody breaks into your server has full access to everything that that server can access what do they need to steal now? Yeah, they need to steal the list of user name and cypher and the key and with those information they've been on the clock everything. Also think about the administrator scenario the administrator threat so the administrator does the administrator have access to the key K? Yes, sir. For sure. The administrator has access to the key K so they could decrypt all of these passwords and go backwards and so it really not it's in some sense better than just storing plain text passwords but it has a lot of products and it still enables a lot of scenarios. So Spencer suggested we use hash so what would be my sum? Yeah. Well since it's one way we don't need a key. So since it's one way we don't need a key so let's do all right Shaw here we'll say I need Shaw 256 okay so now what do I hash? The password gets some output pass and then when I store my database you can hash it out of it sure let's say it's all the same I'm always going to use Shaw 256 right so now so I store a bunch of usernames and the hash of their passwords and now the user logs in what do I do? Hash the password check if that hash password equals this password if it does what do I know for what do I know? Do I know that what they've given me is the password we gave you originally? No. No why not? It's collusion solutions. Yeah it's possible that I mean there will be other inputs that hash of that same value but because of the nature of hash functions that we talked about it should be very difficult they would need to try to the 256th possibilities in order to find something that the same hash of a lot of group forcing. Yeah. So Ms. Woman would it be secure if you hash their password on the front end and then just send that without encryption? Yes. Let's we'll think about that in a second I have a point so I'll make it here. Okay so now let's go through this. So I have a bunch of usernames and hash passwords on the server so we'll go through the form somebody steals this list of usernames and hash passwords what do they know? They have they know the username then they know the hash for some hash and so then what they can do is possibly you know go through a bunch of random algorithms and try to guess what that password might be. Yeah. Okay so they can try guessing passwords if they can stop them from hashing Adam and then seeing if my username maps that password there's nothing correctly that can do that they can do that. What about let's say that you and I have the same password as password one. Would you be able to tell who has the same password here? Yeah why? Yeah they both hash the same value so you'd actually be able to see who has the same password here. So it's actually making brute force fairly easy you've been in brute force the list of common passwords and you can check in this list what accounts have exactly that password but it's still better than the other cases now there's no cane to steal right the user's job is to brute force these username passwords. Okay let's then change our situation a little bit to say that now client-side we shot 256 the password and then we passed the server the age pass which then the server checks and it's in the database. How does that change things? In what sense? Yeah so it's an interesting thing it doesn't fundamentally get us anything it's one of these things where you it seems that it's better because instead of sending your password over the wire you're sending now a hash version of your password so nobody can go backwards to know your original password but to authenticate to this website they don't need your original password what do they need the hash of your password which if you're sending this without encryption they can just steal the hash of your password and log into the site as you without ever knowing your password so you still have to you still have to encrypt the communication scheme and if that's your requirement you might as well just give them your password so how do we get around this problem? yeah please can you explain the whole thing about how the inside hash can be sure so the question was we'll draw all of the client in all of these models the client sends then the server has to validate and not only the client from the password but also the user name and the password so it has to tell them what account they're trying to log in as but we can think of let's say the server knows what user they're trying to log in as doesn't matter sends the password what we said is so anyone in the middle right so you have Eve here in the middle Eve can now steal this password we know that we can create an encrypted communication channel between the client and the server and this way Eve can no longer steal our password right and this is why this public key infrastructure is so important because the only way we can do this if we haven't already shared an AES key with the server is use public key crypto to send essentially first application or whatever but essentially we need to use public key crypto this is why the client needs to know who the server is which is why verifying the way games is so important so you're not accidentally sending your password to an attacker's paypal.com you're sending it to the real paypal.com no so this was the scenario scenario one scenario two the recommendation was send it over the network to the server communication channels of pain what if we just sent the hash of the password right because here it seems better because now if Eve steals this and can't get our original password the problem is all they need to log in is our hash of our password so we still so at this point Eve can steal the shop of our password our password can be as insanely complicated as we want it to be but Eve doesn't care if she has the password so fundamentally we need we still need encryption on this communication channel therefore in most cases if you gotta build this anyways you might be able to do the first it's a good question um yeah yeah so they benefit in some it's very difficult because in some sense if somebody's even if you're hashing and your password they're storing best practices right so your database leads an administrator can't see what all the passwords is if somebody's on the server they see every password that gets sent right this was actually a major um Twitter had a problem and some other companies I think where they were accidentally logging plain text passwords so their database they logged plain text passwords to it a log file um so that this so in this sense it should be better because in this because essentially they can't just simply see all the passwords like you're trying to hide the passwords so only the user does the passwords they should only send the hash but this has a problem there are other schemes that you can do where the server sends a one-time random value to the client the client hashes the password and the random value and then sends that back and then the server can check and that has better properties so you can kind of get there but in almost all cases this adds a lot more communication like a lot more complexity overhead when really you should be thinking if you're trying to authenticate you need you need this channel secure channel anyways right but presumably you want to do stuff to the server and you want to protect your user's privacy by encrypting that communication anyways yeah it seems like beyond like pretty much both channels are encrypted it's still better to not hash on the client side because if you're hashing on the client side then anyone who breaks into the server hashes can just log in directly yeah that's actually a good point because then they can just bypass the client side logic and just send the hash directly to the server yeah the other approach it's going to be double hash I was going to say if you're hashing on the client side or if you're hashing on the client side then if the website has a unique hash versus if they stole a password like we're assuming we're unencrypting it on the server side if they stole the direct password after being encrypted it's different than stealing a hash actually yeah so that's interesting that does impact the multi-website problem so if somebody stole in this sense all these big passwords they can log into this site as all of them but can't log into other sites but are some benefits but yeah the other thing is you need to change your client such that to make sure that it supports this break you have to verify that everyone it just depends on how much control you have you can just store a hash of the hash it's still the same thing it doesn't matter because fundamentally if you take the hash of this password and hash it in compared to this database then I guess for the other for the other passwords you should be able to go back but you still have to encrypt the communication channel anyways so oh yeah it's usually just better than a server but what if we triple-hash it first what if we just remember hashes of simple passwords yeah stuff happens all right so let's okay so we still have this problem so think about a shared system like a Unix server right so now we actually have a nice thing where we can store user names and hashes and we know that assuming we have a good hash function it should be difficult to go backwards right from that hashes to passwords but we still have this problem that if we both have the same password then I can just let's say if I look at this list and I have a password right because they all hash to the same value yeah so can we just limit the set of like more unique passwords but requiring like a special character and then exclamation points so yes we can try to make our passwords more let's say sure we did that but still it's going to be likely that the passwords will be able to see exactly what those passwords are retraction yeah so I've heard the term salting like just a salt enhancer password how do I know what that means does that address that maybe depends on what it means okay yeah if we add a little bit of something to maybe the password call it a salt and then hash that okay so or another in some time you could say what if we use different hash functions for each user right so every user uses some variation of this hash function you would have to store what hash function is used which kind of is like to your point what hash function is used for these or another way to do it would be so when the user creates their password so we have so the user is going oh man okay so the user okay so the user logs in so we have a username and we're going to generate some random data with a lot of salt some random data and what we store is we hash the salt and the password because our double bar just depending on it doesn't really matter how we combine it but we need to combine it we store that so now we get the hash I'll call it an s-h salt and hash on the password and now what we need to store is the salt and hash on the pass and the salt so let's say we go so let's say they log in and they give us username and password so then how do I verify that this is correctly this user how does the salt generation do this randomly it has to be predictable okay so I need this salt in order to recreate and redo this hash so the salt has to be part of the data that we store here so I can take the shop of the salt and the password and say does this equal this if so yes otherwise no right and the key is that each salt is different so if you have a password that's password and you have a password that's password the salt and hash will actually be different it also means in an interesting way so now if I'm going to guess so if I have thousands of user names we said before when we just had a hash I could hash the password password and just see every single user that has the user name of the password can I do that in this scheme yeah because every user has a unique different salt which means I have to go through every user use their salt combining it with password with the password password hash it and check if they have the user name password so now I'm at least required and we'll talk about reinforcing later but this is significantly better here so we'll just go back real quick let's do this so you guys even had this way back in the day I'll talk about this in a minute so the hash so it had strings so you guys only got to educate with passwords of eight characters or less which is kind of crazy and then so the idea was what we store is an 11 character hash in the password and a two character hash ID in this case essentially our salt and what we think about and you can think about in this sense how high BPS that depended on the hash ID so this is the idea of having your salt change the hash function and we have all of these nice things here so yeah so we can see so basically we can ask the thing hey Alice wants to create a password called password the Unix system will create that and then transform this password into the complementary information so here we have and this is we've seen this inside the EEC password file we looked at this a long time ago we have the user name Alice and then here I think these first two bytes are the salt and the rest of this is the hash of the password password cool alright so when we come back do you think we'll talk about breaking stuff Thursday Thursday Thursday Thursday Thursday