 Let's get started in all identity verification and key signings. We've delayed until after class. I had a question, oh, I had a question come up before class. I should have had the person ask during class. They say, what if I sign somebody's key and then think later that maybe it's an adversarial key and I want to revoke it, what can they do? What was that? What was I saying? Yeah, nothing. There's nothing you can do if you've already signed the key. So revocation is a whole separate process that's really only with these servers that you guys are using. So as long as the adversary has a public key that says it's signed by you, that's all that the assignment cares about. So there's no revocation, so it's really important that you actually sign things correctly from the start. Maybe next year I'll make them create a key server or something. We can use that. This might have been addressed already, but I'm just going to ask you if it's easier to do it here. So our requirement is to get 20 certifications on our public key. Do you differentiate whether or not those are adversarial keys or legitimate keys? No, because you shouldn't be able to differentiate. They must be keys in the class, so I know that they're a class key. That they're signed by the class public key server? Yes, so if it's signed by the course public key, then you're fine getting a signature on it. So yes, I'll count it that way. But the flip side is you also need to sign 20 people's keys with your public key, not your adversarial keys, right? Question, so I know you can change the name on the keys and it'll lose the class certificate or the signature. Will that count? Does that make sense? I don't know how to answer your question. If you just create a random key and upload it, will that count? Because you got people to find it? Yes, I guess. So the adversarial key you can change the name on it, but it'll lose the signature from the class server. And let's say people signed that key, but it doesn't have the signature of the server. You will have to try it. I mean, I kept track of all of the fingerprints of all of the adversarial keys, right? So I have all that information, so it's not the sentence. Like if you randomly generated some new key that doesn't have the signature of the server and tried to upload it to your adversarial key, it shouldn't match. So if we fail to sign or certify 20 other public keys that negatively impact our servers, let's say only get around to signing 10 real people, that's also counted? Correct, because the point is, hey, if you don't sign anybody's key, you have no risk of signing an adversarial key, right? And without each of you signing at least 20 other people's keys, you're going to get 20 people signed for a key. Right, so I guess you could just have 20 people sign everybody's keys, but that's not very fair or fun. Questions? Part one or two? Questions? Kind of like different questions from the project, but like with the midterm coming up next Tuesday, what can we expect from that? Or are you going to do like maybe next Thursday, go over a couple things we're going to expect? No, it's going to be everything that we cover up until Thursday. Everything covered in class, play in advance, people have to know this, don't ask me what's on it, I'll just tell you it's anything that we're covered in class, it's a fair game. That's from my perspective, the entire point of an exam is you study the material, if I tell you what's going to be on it, you will study just that and nothing else. I know that, that's what I would do. So my job is to test your knowledge on things. I obviously can't exhaustively test everything, because that's a fixed exam, right? So I can think like I randomly pick points in a space to make sure that you kind of study the space, right? So if you ignore half the class, then whatever, maybe you get lucky and all the questions are on the other half, right? But maybe you get unlucky and if the other way, you get a zero. So study each one of the steps we talked about. Now make sure, one of the, actually, so one of the good things is I won't out this person, but one student in this class told me that they went on a, they had an interview with a company and a lot of the, I think four out of the five questions that were asked were stuff that we talked about being class. So this is part of why I want you to learn these things while you have an intern just so you can learn these things. So when you go talk to somebody who's in security, you, and you say, yeah, I took this course, you can actually talk about it and know things. So that's also the important part. Cool. Is there really a big class today? Because everyone wants to sign everybody's keys. Trying to prove that you're actually here. You got to watch out for the plants, though, that are somebody else. Not actually in the course, just an ASU student. All right. Any other questions? How can we try to prevent some of the attacks that we discussed with different authentication schemes? So one of the ways we talked about is we can hide maybe one of either A, F, or C. So when you write this again, what's A? We're going to go back to our formal method. The actual password that users chose, right? A is the actual password that users chosen. F is what? Is that a spark? Oh. Yeah. Unless you're just trying to get me away from my computer. The function which does what? Yep. So it just takes in the input, the user's input A and produces some complementary information C, right? And so C is the complementary information. So typically what we think about this is the hash function, right? So F is some kind of hash function. And we can actually see this. I didn't get set up for this before class. I'm going to get all the way there. So let's try a live demo. So we're going to look at the... So we can look, we can see, I think we maybe did this a little bit before but I just want to do it again because we're counting the authentication. We can see that I am user root. I actually have super user privileges on this machine. We can see the ETC password. Sorry. No, wait. That muted me. Program, right there. We can see the ETC password file is readable, writable by root, readable by group root, and readable by everyone else. So if we look at the contents here, we can see that every line there is the user account and X, a user ID, a group ID. A, I don't know what this one is. I think it's a... I think it's the comment field. And then they're... I believe they're home directory and they're login shell. So if we add a new user, I can never remember which one to add. Then if I cat ETC password, we can see that a new user was created, Adam D. With the second field, the password field is X. And we can see that user ID is 1,000. So if we cat... So the idea is you can see here how cool the users are on the system and what their user IDs associate with each of these users. So you can see that user ID, if you look at the very top, you can see that user ID 0 is root. User ID 1 is Damon. User ID 1,000 is Adam D. The passwords aren't stored here, right? Because what are the permissions on this file? Yeah, universally readable, right? Any user on the system can read this file. So if we stored the password patches here, those password patches would be read by any user in the system. So Linux tries to prevent access to C by putting all the passwords in an ETC shadow file. So you can actually see that all the other users here at the start, I believe, means they don't have a password. So you can actually log in as them. We can see that Adam D. And we can see that inside here, this is, bless you, bless you twice, so again. So the way you actually parse this is, I believe, everything between the first set of dollar signs is what type of hash it is. I don't know exactly what 6 is, but we'll get to see exactly what it is. Everything else in between here is, I believe, base 64 encoded salt, which, depending on the hash, may also contain additional information. And then everything in here is actually the hashed password from the last dollar sign to the end, is a base 64 encoded hashed version of the password. So if I make a challenge or somebody can figure out what the password I just typed in was based on this hash. So the idea is, so the ETC shadow is readable, writeable by a group, only readable by the shadow group. Otherwise, it's not readable, writeable by anyone else. So only root can actually read this password. What does that actually do for us? Does that actually improve the security of the authentication mechanism of the SY? So I can't run an offline attack. I can't just get the hash and then try multiple values and try to root for the hash that way. What can I do? Does that mean I can't possibly break into anyone else's account? You can, like, right? If you were able to crack someone else's password, it still doesn't, since you're not root, unless you crack root, you can't get access to the other information, right? So how much, let's say, you want to break into that added V account. You're some other user on the system. But you can't get to see you can't access the complementary information. But how would you try to do it? Uh, I would have run, I mean, I'm in recent class activities. I mean, we've ran, it was a crack. What was the name of the program we used? OPH crack or something like that. I believe you used rainbow tables. So just kind of a look up table. What did you mean to do that? Physical access to the device. Or at least, not physical access, but just the hash of the password. Do we need the hash of the password? That's the meaning of the hash of the password to do that. So you don't have access to the hash. Can you still break into my account? Am I super secure? So if your password is insecure, what does that mean? It was an easily identifiable password. So how would you try that? Run a list of top 100 passwords and see if that was one of them. And do what? How would you see? Oh, physically entered in. I mean, I'd have to know your username. Right, so you know my username, right? You can look at your PC password, you can see the username. So then you try logging in or you try running sudo or login with my user ID, which would prompt you for the password. So have we actually gained anything by taking that hash value? Because you can still attempt to log into the system. Have we actually gained anything by taking that and moving it into the shadow file? It seems like you didn't, right? Because they can still try logging in. Just like if you had the hash, you could keep trying different passwords to try to generate hashes that match. So why do this? So you got to think, okay, any time you think you're smarter than an operating system that's pretty old and open source and has made some, I don't know, been around for a long time. Oftentimes maybe you're right and you are, but you should not start with that assumption, right? That's like, when you think there's a bug in the compiler, it's 99 out of 100 times. It's not, it's a problem in your code. But there's that one time that it is. So you shouldn't start with that assumption that it's a bug in the compiler. Whenever you suspect that, you always want to go back, verify your own assumptions about what was wrong. So, but why do this? It takes longer to talk to the login program than it does to pre-compute hashes and check what it has to do. Why? The login program is old and slow. All it has to do is take your input and then run the hash and compare it, right? Which is almost exactly what your program, your group fourth program is doing, right? Your group fourth program just takes the new input, hashes it compares to hash, right? It takes the next input, hashes it compares to hash. All you have is, say, yeah, there's maybe some overhead where you're doing that and maybe there's overhead from looking at the file every time and the file will probably get cached by the operating system, so that may not be even slow access. Just to put a weight in the operating system, like if you try to log in your studio, it's gonna get your password input, but then literally just sleep for several fractions of a second and then continue. Yeah, so the way to think about it, I wouldn't necessarily think about it in the operating system, but we can say maybe in the L function, the login function itself, if the input is false, right? If it's not a correct login, then sleep for even a half second. Has anyone ever noticed this? Have you ever tried to log in to a Linux machine or even a Windows machine? Have you typed in the wrong password? How long before you can type in the next password or try the next password? There definitely is a delay, and some systems will kind of put an exponential delay in, so that the delay will keep getting longer and longer, which tries to help prevent you from brute forcing the password, right? Because maybe you can get some guesses, but there's no way you're gonna be able to guess as fast as if you had the hashes, right? So the key distinction there is yes, there definitely is some delay, it is slower, but it's deliberately slower. It's not an accidental decision. They deliberately wanted to make it slow. So this is good. So we talked about a little bit. So here we're kind of thinking about can we hide A, F, or C? So if we hide C, then that's pretty good, right? Then we can force them to go through our function L and maybe add some slowdown if they're incorrect and try to stop A, an online group force attack. But preventing L, hiding L is pretty difficult, right? Because if an attacker can't log on to the system, then the user may not be able to log on to the system, right? So only ways we can maybe do that are trying to restrict based on the address that the attacker's coming from or things of those nature, but even then there's no guarantee that the person logging on is the actual person, right? What's the authentication problem, right? If we can tell that the person connecting to us trying to log in is the person who's authenticating them, they've already authenticated them, right? We may say, hey, we know it's only from this IP address, but we don't know whether it's that person or whether it's malware running on their local system trying to log in. So password-based authentication, we're going to look at now and kind of actually go more in depth of looking at all the different types of password-based authentication. I'm going to steal this Winston Churchill quote paraphrase that it's like, passwords are the worst form of authentication except for all those other forms that have been tried from time to time. Why is that? You all use passwords. Do you love them? I love the one I can remember. Do you love the one that you can remember? That's the problem. Yeah, the one that you can remember. Yeah, so it's kind of similar, right? We go back to the key analogy that we've been talking about, right? A password's like a key, right? And so how many keys do you have on your key ring? One, do you have one key that opens every single door in your life? Do you have, I don't know, does anybody have a ton? Does anybody have like a janitor's key ring that has like all over the edge? I have about, I don't know, five or 10, maybe 20. That's a two and five. I have like five or six. Eight. Yeah, that's a lot of keys, right? So then what's the problem? Why don't you have, why is it feasible to have eight keys? Well, why is having one password like feasible? You have to remember it, right? You're a person, right? When you walk up to a door, all you need to know is what key goes through this door, right? You don't have to remember the edges of your key and have to like recreate this pattern to log into your, or to enter your door, right? So what are some of the problems with these? What are good things? What do you guys think about passwords? Not keys for you? A password? I think it's good that the user is able to choose a password. I mean, in a sense, in the best case scenario, that could be kind of like a one-time pad's not right. But I mean, in a sense, if passwords are being assigned by something, that means there's an algorithm or system, probably assigning them. So if you could break that, then you would break the passwords. So if every person did create a strong password and could remember it, it'd be amazing. It'd be a great system. Yeah, so you can say it's good in the sense that it gets the user's control, right? They have the ability to create difficult, hard-to-get passwords. What about from the authenticator's perspective? Are passwords good or bad? Good, why? Easy to implement. Easy to implement is pretty easy to implement. It's also easy to implement poorly, but even, actually, I'd say with a lot of, I'd say I think a lot of web frameworks have easy, pretty good authentication modules that you can use. So it's pretty easy. So if you're using caches, what else does that get in the server? It doesn't take that much compute time. What's the other important property of a hash? Use it. Super quick to compute. Definitely true. It's difficult to get the original play test. It's difficult and hopefully impossible to go backwards, right? So if the FBI, the NSA come to you and say, hey, what's user XYZ's password? You could legitimately say, I don't know. I have no way of knowing their password. If they tell you to input something that captures their password and they input it, then they could definitely do that. But that's another aspect. But at least you can say, you have the viability to say, hey, I don't know your password, right? And I don't actually care what it is. So there's some inherent vulnerabilities to using passwords in general. So why isn't, so you talked about one, I mean not one, it's good because you can create one really difficult hard password that you can remember. So what about, is it, I guess is it hard to remember hard passwords? Pretty random passwords? Yeah, it is, right? I mean, if it's completely, if it's a string of 12 letters, digits, special characters, and you have to memorize that, that maybe you could do it for one, especially if you use it every day, but I don't know, doing it once a month or something, that'd be pretty difficult. So what's the human tendency, is to use something that's easier to remember, which may be something that is also easy to guess, right, for an attacker. So this is one of the key problems of passwords. So another aspect that's actually easy to overlook, because I always think about this as kind of a, very much a, I'm here, I'm logging into some service, and so you only think about the interaction between the person authenticating and the service that they're authenticating against. But that's not often how we do things, right? So are you, is it, I'm trying to think. When you go up to an ATM machine, does anybody try to hide their pin code that they put in? Why? No? Just because I don't know, I've always done it, just father did it, I've done it, father, it's just kind of something to ask. What's the point why you do it? Why do you do it? Just because if someone has it, they would just need my card to pull basically all of my account. Yeah, so what it means, in that specific scenario, what's the threat that you're defending against? Loss of property. Loss of property, but who are you worried about protecting that loss of property from? Someone like shoulder surfing? Yeah, so what does that mean? Basically someone just standing right behind me kind of looking over my shoulder or looking from the left side of the ear or wherever. So you're worried about somebody physically around you snooping on you inputting your password, your pin code to your debit card, which gives you access to your whole bank account. Is anybody worried about that when they're typing passwords into their computer? Yeah. Yeah, we tell people to turn away or we cover the monitor. Actually I have a really funny story about this, so when I was in the, it doesn't matter the time frame, but I worked for the Psychronous Sports Commission when they were putting on the Olympic trials and we bought this software to do credentials and to make badges. So all the volunteers, all the athletes, everybody had to do badges. And I was in charge of making badges for the volunteers, and there, because there were so many people, I had to manage other volunteers who would do the badging process. So we set it up that you had very specific, you know, if you needed very basic access, you could just do that, some volunteers could do that. But if you needed special access like a badge that would give you access to everywhere in the facilities, you need some authorization. And the software that we were using to put in this password did not password protect, or did not even do the stars when you input the password. So whatever your password was that you type in, it would show up exactly there. And so, and so I'm typing this in front of volunteers, right? So clearly everybody's like this is a terrible idea because the volunteers can see the password and just make whatever badges they want. So what do you think we did to solve this problem? Do you think that people made this terrible software actually fix this problem? No, they recommended that the password be five asterisks. So you shift and you hit eight five times. So you get five stars to show up. And that was the password. So as you're typing this, it would look like it was not in showing your password, it was actually showing them the exact password. And so it did not go very well. It actually was good in a sense because we can claim that we had a password and it was safe. But on the day of things were just going crazy. And there were a few times where I think I mistyped like letters I was typing, so you'd see like star star star five and then star star and then like a, or I got really tired so I wasn't good at hiding it so I just hold shift and hit eight five times. And then the volunteers actually caught on so they would stop bothering me and they would just do it themselves. So this kind of goes to the snooping problem. It's easy to snoop. And you think about nowadays, you all have a recording device on you. Most people have phones with a camera. I can take video and take high death video, slow motion video, right? So all it takes is somebody recording you typing in and they can actually get your password, right? So this can be a huge problem. Actually there's, we won't go to the now, but there's a whole bunch of research being done where people can actually use sound to get your key presses so they can record the sound to get your key presses. They can, if you're on your mobile phone and an app has access to your microscope, they can use that data to actually extract the password that you're typing into the password fields because the keys that you press are going to move the phone in certain ways and so that can tell them roughly what keys to press. There's also that shoulder snooping on phones which actually makes the problem easier because if you think about it on your mobile device when you type in letters, so A, it's a little difficult to obscure some of the string, but when you hit a letter, at least I know what the iPhone does, a big magnifying glass comes up with exactly which letter you hit, right? So if somebody records that, they know exactly which keys you're typing in. So I won't out anybody in this class, though there's another aspect of passwords that are really annoying. So not only do you have to generate a difficult, so to make a good password you need to fix all these things, right? You need to make a password that's hard to guess, you need to be registering your password in. You also need to remember the password, right? You need to remember it every time you use it, otherwise you get a funny password generated by me. So it's easy to lose passwords, right? To forget a password and then you may not be able to actually get back into the account. Everyone wanted to share a password with somebody? It's a very good example. Use somebody else's Netflix account or... what else, any other things? Wi-Fi. Wi-Fi? You want to share your Wi-Fi password? Yeah, I do. Ooh. Yeah, so you may want to share passwords that way again. No. Wills are reported for public documents. Definitely not put your passwords in. Yeah, they'll be put in public documents. That's the way of accessing that way of doing passwords. Yeah, so you may want to share it in the case of a certain event happening, right? In the future. Yeah, so all of these cases are cases where you want to share your password. But... you know, it's difficult because when you do this, well, you now lose control of that account. So basically they have exactly 100% the same rights as you do. Like the Netflix account, right? They could actually start... I can't remember if I shouldn't say this, but it's very reported. I think who... I believe changed the... I think maybe it was both... I'm not before Netflix streaming, but when they were first doing streaming, they changed the place that DVDs would be shipped to to their place and not, let's say it was a parent's place. So the parent was upset that DVDs weren't showing up anymore. And that's what happens when you give some of your passwords, right? They have 100% control of your account. They can change things. They can create a new password for an email address, any kind of things, right? So it's actually really difficult to control sharing in that case, right? Which kind of goes back to the... what we talked about with authorization, right? If the only method you have is a password to identify people, it becomes difficult. People in general are very hesitant to admit when they fall and pick them to some kind of social engineering or scam. So I won't ask anybody in this class, but there have been our cases of when people either call you or you get an email saying hey, this is ASUIT who detected a problem with your account. It's going to block your scholarship that's coming up. But we obviously want to verify that it's you and that it's not somebody, we're not talking to somebody else. So to unlock your account, can you please give me your ASU write ID and your password? So you'll tell it to them, you'll tell them to lock everything, it's all good. So there's a whole class of social engineering attacks that happen with passwords because remember it's something you know, right? So if you devote that thing that you know to somebody else they can then use that to authenticate themselves to the system, right? And so these are kind of inherent problems with passwords. And I think it really comes back to the point we talked about is yes, it's good in the sense that it pushes the security burden onto the user because it says hey, you, you know, make choose a good password. But that's also the biggest con because it forces the user to choose a good password. And another thing that's really difficult is it's hard to it's hard for a lot of especially people who are late people and don't do, you know, computers and programming all the time, is the difference between easy for person to guess and easy for a computer that's cracking your password to guess are completely different things, right? I can come up with a lot of passwords that would look pretty random to you but then when you realize there was some keyboard pattern or something you would easily be able to find it and password crackers know that. Some practical vulnerabilities. So one key question that we haven't talked about is how is your password actually transmitted to the remote system? So why do you feel safe when you SSH to a machine you type in your password? Shouldn't you feel safe? Is somebody sniffing all your Wi-Fi traffic but they've just seen your entire password? Do you know that for a fact? I think the answer is more it depends on how the protocol is implemented so SSH is specifically designed so that that communication is secure and encrypted but you still have the middle problem where you actually don't know if you're talking to the server or a person impersonating that server without comparing some other public keys and trying to identify that. It's a huge problem so Telnet transmitted passwords in the clear so you could easily sniff networks and look for Telnet accounts pop and what's the other mail transfer protocol? IMAP. Pop and IMAP would NSMTP I think also would transmit your password in plain text and there's tools that you can download that will just sniff open Wi-Fi networks and look for any passwords that are being sent across. I believe FTP is the other big one so FTP by default sends the password in plain text so why don't you fix this so we have this function f that turns the password into some complimentary information so why don't we push that onto the client and run it f and then send us c? Maybe I'm seeing it wrong but if you're sending if you send them f and they send c that's f and c are still in the clear so if they see the function that you sent them they see what they return to you I mean it doesn't really solve the problem. So what would that mean? So you're an attacker, you see this you never see a you see f and then you see c then what could you do? You can't reverse a hash you can brute force and try to hash the hash Sure, that's the same problem let's say it's a really good hash function we'll talk about good ones in a second let's say it's a good hash function that's difficult Yeah Yeah So if all the system is doing is taking in c to authenticate us if I sniff c essentially c is now your password if I can get the hash then I can try to log into the system it'll send me f and I'll be like yep here's my hash function and send c back there are techniques but it's very difficult to do in practice to make it so that you actually know the password I don't think I mentioned zero knowledge proofs but there's crypto stuff you can do to prove that two people know something without actually sharing the thing that they know so you can prove to each other that you know the password without abstract either side divulging the password I don't think we're quite there yet with doing that and the similar thing is susceptible to replay attacks so if I can just record the traffic that logs in it maybe contains the password maybe contains some hash of the password then I can descend it password reuse so it's password well actually let's hold on this we're going to talk about it later and frankly one of the biggest problems that requires really proactive management on the part of the users again we're pushing security decisions onto the users and saying hey do a better job make better passwords think before you type things in don't actually try to do your job or do what you're supposed to be doing think about this other thing that we're forcing you to deal with cool so let's say you're going to list so we kind of touched on a little bit but I'll go more into the details of how you actually try to break into something so let's say you want to break in some authentication system what's the first thing you try and why what's the first guess so what's the first password guess you would try would you try eight a's I mean there's a whole list of commonly used passwords or I mean the simplest admin that's what got activated yeah so you use so what's the theory there what are you trying to do you're just trying to see if people have changed the default okay it's a default password so that's a good one so maybe you can find a list of for the site or the it's a router or something you can find the default username passwords that have been used there so why would you use the most commonly used password type it seems self-added but I'm trying to get you to think about the concepts at fault so why would you use that why would that be important yeah so you think about it as a search problem right so we have some space of passwords right we know our password are set A of all possible passwords we can just start choosing things at random from A and try those passwords right or we can try to order A in some notion of what's most likely right and we can try that we can also use not only so the list the most commonly used passwords is actually kind of an oxymoron how would you ever create that list because what are you supposed to do with passwords keep them private and never tell anyone that right so you could use that if you trust how that was created or one of the you know classic ways you would do this is use essentially what they call a dictionary attack which is kind of a general term for all these type of things where you basically go through the dictionary and you can even order by most common words to least common words try a root word in the dictionary against the password list and it's incredibly simple right for each word in the dictionary so assuming if you have C you would either compute the F of that word and check if that equals C or if you don't have that you would ask L hey I try to log in with this new word so we just talked about it's difficult to search all possible passwords right if you know the set of all possible passwords is 12 or 15 or 20 character alphanumeric and all let's say all principal ASCII characters if you know that that's the space of the password that's incredibly difficult so much more easier to search likely passwords right to search through and find out what passwords are much more likely so there's two ways and this is the way we've been talking about but I think it's a little bit more clear when we have this dictionary example so we know F that's being used we know C and so we can repeatedly try different guesses right so this is what we talked about we can just if we get the hatches we can just try possible passwords and so as somebody mentioned there are tools that will do this crack John the Ripper there's lots of stuff you just look for password cracking tools you usually I think have to give them a word list so if you're writing this tool would you just use the words I don't actually use the words okay so you first try all the words I think that would be pretty easy maybe try combinations of numbers up to a certain length and then you try different variations on the words you try uppercasing the first letter of every word you could try all uppercase you could try different variations of camel casing you could try ways of substituting 3 for E you could try all the words with a special character at the end right you could try different all types of different variations here and that's actually what these tools do so with an online attack right so here in this case we don't have C but we have access to the login function and so we can try different guesses until L of our guess actually succeeds so this would be logging into a website guessing a password so if you're trying to log into the CSE C465 website trying to break into the admin account you could try that by putting in different passwords and different guesses so how do you counter this how do you defend against this is this an impossible problem entering the correct password after 3 tries then they're walked out to a certain length so how do they get back in either that certain amount of time is passed or how do you force them to reset their password that's sent to some communication of the phone or email that they previously did so one so basically one idea would be after 3 failed guesses locked it out of the account for 45 minutes say nobody can log into this account for 45 minutes but if you need to get it unlocked you can either follow up on an email which we know is associated with this account or tell them they have to call a certain number of service, a human will try to authenticate them and then kind of unlock their account what are some good or some bad things about that approach so think about yourself authenticating to a website have you ever input a password wrong 3 times in a row yes why it's because you're dumb no because maybe you have catwalk on or maybe something else weird is going on or maybe you're just fast figuring and accidentally mistyping things it's a password you're trying to go through and you don't know which specific one on this list it actually is so you keep trying additional passwords yeah so it definitely has pros but it also has cons from a business perspective because now you're locking your customers out so now you're adding additional burden to your customer support people so it is you as an organization would have to decide is this the right thing that we want do we want people to have to do this so a bank may make different decisions than let's say a clothing store or something like that what are the ways right so you try to enforce password rules when they're creating their password right so what rules do you want to enforce a secure password character of maximum a minimum character of it so let's say you have 8 will be secure 12 characters what else do you want what's your specific policy what do you want for this generally I found they require also at least an instance of an uppercase a special character an uppercase a special character and a number and the length and the length of 12 so I guarantee that nobody's ever going to create a bad password a capital password xy xy xy xy xy all the way to 12 characters or password 1 1 1 1 or the name of the site capitalized or something and then so let's say you do actually have somebody create a good unique password for your site and they come back to it in 2 months what's going to happen they forget they're going to forget because you force them to create a password that they can't remember and that is secure but not usable so it's definitely kind of a mixed feeling I mean I think it can give you a bad sense of security that yes you actually are these passwords are good but until you actually run a password cracker against it it's hard to actually verify that that is one thing that so you're definitely getting more information of the attackers so the hope would be essentially the size of A like the set of all possible passwords so the hope would be that it's large enough that it's okay that you're telling them that but yeah it's definitely a good I was just going to say something similar that a lot of times I have to have a special character so everybody puts one exclamation point in their password and then that almost shrinks the size of A it's kind of the thing of if I know what permutations you're going to use then I'll use that in my password cracker and that's definitely what I would do is take my normal password list and add exclamation points at the end so I can password the exclamation point as probably the first thing I'd try so going back to the earlier comment about let's lock people out after three tries so one thing to think about is what is the attacker's goal so what is the attacker's goal what is that yeah but that's not specific enough it's not useful cracker whose password whoever somebody's password is that all the time well I think a password let me really open you up to an awesome service attack if somebody just went through and if they had a list of all your users and said oh cool I'll just go through and try every user three times and everybody's locked out yeah that would be actually super interesting the thing about this is differently whose password would you rather have access to what if it's a password a student in this course or let's say me my exu password or a regular student in the class why I've accessed all your crates right my password or Michael Crow's password right he's much more important than ASU he probably could do a lot of stuff with this account right so the point is an attacker so if let's say your goal is to if the attacker's goal is to let's say change their grade in the course then getting access to yours any random ASU any student in the class is not that important right they don't really care about that they want to get my account but let's say that the uh let's go with the grade I guess it's a little bit stretched but let's say that cause you can drop courses through my ASU right yeah so let's say that you wanted to um improve the curve of your class so rather than bringing it to my account you can bring it to as many of your fellow students' accounts as possible and drop each of them from the class right thus raising the average right so all those people are going to get a W or something so maybe the person professor keeps that in consideration right so the point here is that there's actually two different models we're thinking about when you think about somebody who's trying to break a password there are cases where we want to get a specific account right we want to get an admin we want to break the admin user account we want to break the professor's password right there are other cases though right we actually don't care whose account we get into as long as we get access to think about a bank actually I don't really care if I break into a specific person's bank account unless I know they have a million dollars in there I just want to break into some bank accounts and hopefully there will be enough at the sum of that I'll be able to get a good amount of money so taking your example of breaking of dozing the entire service by locking every single person out of their account let's say we didn't want to do that we wanted to figure out how can we break into some accounts how can we do that so we don't want to break into a specific account but there's this three three try limit what we do yeah so say that again on all the users yeah so the first thing I would try is password on every single user in the system however if I could find out user account names I would try that on every single user in the system right and I guarantee you you will get access to that system right you will get some accounts that way then I can try and give you the next most popular password which is I believe 1234 up to the minimum number of required digits I would try that across everybody's account and that would give me another set of passwords right and I haven't locked anyone out at this point and I can give you this stealthy over time I can do this by using a lot of machines and IP addresses so I can come from a lot of different places so they may not even be able to tell it's me doing this slow but broad password crack right whereas if I want to get into one person's account so the limit actually doesn't help very much if you just want to if the attacker just wants to break into anybody's account but it's great to prevent people from breaking into my account right because I have a good password so one thing that we talked about already is basically deny access to all the complimentary information right so force them to have all their guesses online is this easy to do? costs a great deal to authenticate each other when you speak in class you know it's probably in class or at least they've been paying attention for the last two weeks it's probably a good idea they're not adversarial yeah my name is Larry Standiff by the way I told you just sign in I'll get back to you on the web a web server yes on a local machine why? on the web you can't just do weird memory things that get into files with old caches on windows if you want to dump the windows SAM so that you can crack the windows passwords it's not like you can just copy paste it there are people that have come up with inventive ways to overrun the memory protected you can't touch this file the operating system running protection so that you can retrieve those from the machine okay that's interesting so there's definitely is a difference between let's say you have physical access to a machine versus remote access right so even on Linux machine if you have physical access to that machine and the drive is not encrypted you can just go and read the ETC shadow file of that machine I actually have gotten and broken into well not broken into it it's a virtual machine that my advisor gave me and he didn't give me the password so you just boot it up into super user mode or single user mode or whatever and alter the ETC shadow file with your new hash that you want the password you know and then you reboot it so it's actually good in that case there are definitely cases I'm not 100% up to date on like the current state of windows security but you used to be able to very easily get the hashes of like all the users on the system so you could then use that to crack them so can you still guarantee this on a remote server a web server you have to send an A over the network you have to send an A over the network right which let's say we're using HTTPS we're using SSH we have to guarantee that the protocol is secure between the two endpoints we've even verified the authenticity of the endpoint so we know that we're actually talking to let's say google.com or gmail.com so we've verified that yes it's definitely them can we still guarantee that nobody can get the complementary integration I've found the server I've found the server all you need to find is one vulnerability on that remote system that allows you to access to either read files read the database or as a rule of code execution that allows you to use the code like if it was possible to like sql injection sql injection vulnerability is a classic vulnerability that we haven't talked about yet but it kind of goes back to the well assuming that if the system is secure then yes you can guarantee this but we in real world systems there's always vulnerabilities in all types of mechanisms right and applications and so in the case of sql injection all it can take is one command and you can download their entire database which probably includes the hash hopefully the faster hashes and not the actual passwords so it can be hard to guarantee that this is the case but it's a good additional first step what we talked about we can add a delay to L when incorrect so we can say hey when you log in we'll actually wait for 500 milliseconds if it's false so many systems actually do this one of the main ways though but okay so let's think about so adding a delay to L is great in what case when we're rapidly attacking one password one user what information do we have why are we using L we don't have to see it we had to see what we do which f does not have any delay to it the delay is artificially added in L so we can crack it as fast as our computer as our hardware will allow us to crack right so we're not actually limited to this so this only helps you in the case where we don't have access to any of the complementary information we cannot get any hash so then what should we do try it takes 500 milliseconds or something that seems pretty good right because then you're limited to cracking 120 guesses per hour or minute can you run for multiple can you guess for multiple machines yeah you will we'll think about it from the defensive side now right you can guess for multiple machines but each guess is still going to take 500 milliseconds which is much much much much much slower than calculating mv5 or one of these hash functions Linux does this but you make it system wide as well basically so that even if you had two users but even if they take the hash right even if they take c then they could just run it as on it but it's still better yeah but barely so if the delay in L can be bypassed then where would we want to put a delay in the hash right what if the hash itself takes 500 milliseconds or 300 milliseconds right so we can actually increase the time to compute f and we'll actually see there are many there are a lot of hash functions that actually do this the idea is they are intentionally slow if you were sufficiently knowledgeable could sanitize hash functions to be equivalent of faster so if for shock 5 or whatever the next person is if they do something like this it automatically takes you know 10 milliseconds longer to do some padding from constant time operation could you go in because the algorithm is public and reverse-engineer it and make another algorithm that's the same thing but a half the time so here's one way though I mean you need to actually add the delay smartly so that you can create some f prime that's identical but takes less time right so you can't have say yes when you hash this value you hash it you do md5 and then you wait for 500 milliseconds nobody would actually follow that one of the things they do is say calculate md5 100,000 times take the password run it through md5 via hash and then feed that back into md5 to calculate the hash there and keep doing that 10,000 100,000 times and that will add some inherent delay the problem there that's the first thing I think they use the problem is that you can make FPGA boards and you can make hardware that does that really really fast so the next idea was force it to actually keep track of all of the previous values that's hashed and use some pseudo-random previous results so you have to store in memory all of the previous results you've made so you actually now have memory bounds on your hashing so to hash this effectively you need to use x amount of memory which then is much more expensive to make hardware for you can still do it when you're increasing the cost to attackers that they have to build special purpose hardware that's very expensive based on note-pickings cool so super cool thing that I really like talking about here that there's a lot of information out on the web the idea of rainbow tables so think about it this way I wanted to crack any let's say 6 digit alphabetic alphabetic password that is using md5 as the hashing function how would you do this you want to break it in O of one time you want to just break it without trying all of that that's me actually I want you to be able to tell me to reverse the hash essentially this is one of the 6 digit alphabetic passwords what would you do see if you need a math to pick on a dictionary the hash is the key in the password is the value and so you just put the hash given in the key in it for the existing dictionary and it'll spit out the value so you can loop over all 6 digit alphabetic passwords for every one of those do the md5 hash to restore the password and the hash your question was deceiving because your dictionary looked up maybe constant time but your pre-computation is the whole process you have to build a dictionary I have to trigger a little bit but once that is built once you have it assuming it's sufficiently large it actually has enough stuff in it that you actually can find a password yes so it depends on if the password is in a space that you're essentially pre-computing the hashes for what it is that's trivial you could easily write that code to do that now how much storage space do you need to store that how many is md5 hash I actually don't remember 32 bit hash so you need to store however big the password space is which is 6 to the 32 there's just lowercase alphabetic you need to store for each of those 32 bytes that would be a huge table but hard drives are cheap and you could store all that that's not a crazy thing to do so the idea with rainbow tables we're not going to go too deep into the invitation but I super urge you if you want to get into this rainbow tables are a super cool way to say hey this basic idea is good we want to try to pre-compute all possible hashes here but what we want to do is we don't want to store every single hash for every single value so you essentially pre-compute the size that you want to use and you create a rainbow table based on that that actually doesn't store every single hash but it allows you to do it in a way that allows you to recover the password they're super cool so they basically give you this tradeoff between time to crack so how long if you're given a password how many operations do you have to do to crack it so in this case it's super easy you just look up in a table a rainbow table you have to it's actually really cool because it uses hashing to do this and uses different types of hash functions I'll let you get into the details if you want but the space requirements for this are large so for md5 1 through 8 character alpha numeric the rainbow table for this is 127 gigabytes but this is all 1 through 8 alpha numeric passwords and 127 gigabytes is honestly nothing that's so low and 1 through 9 you can see it increases a lot is 690 gigabytes so what this would mean if somebody has this and they've pre-computed every single md5 hash for every single 9 digit alpha numeric password if somebody breaks into your system and lets say gets a list of all the hashes seeing your system to break passwords all they need to do is look this up essentially the rainbow table do a few operations and then be able to break any 1 through 9 character alpha numeric password this seems good or bad good for the hacker bad for us so how can we defend against this what's the key component here that allows this to happen part of it is the size of the password so part of it is if we know so if they have a 12 character password we probably can't create a rainbow table but maybe we can you can get a lot of so maybe you could so the key idea here is that if your hashes are just based on the password so A this has the problem this is what they found in the Unix systems so A they were storing the hashes in the ETC password file for everyone to read but what they found out was that if my password is password we hash that to a value store that and you create a new account and your password is password as well all you have to do is check the ETC password file and anyone else who has the same hashes you you can clearly see that they have the same password as you right so to solve this they did two things A they saw they basically choose so you can think of it as creating different F functions right so the different F functions there's 4000 F functions based on this salt so the salt changes from what hash function you're actually using so in this case that hash function F is constant it's md5 right it's 1 so this means if you have a database where you're storing hashes as just md5 values all of these hashes could be passwords could be trivially broken with this and so what this is called is a salt think about salt and hash think about that the idea is adding some random values of salt to each password before it's hash but the key is and this is the key thing that people always mistake about this the salt is public and known the salt is not a secret value it's actually stored with the hash the idea is now every password so depending on the size of your salt whether it's 2 to the 10 or whatever how many different values your salt can be you now have all these different F functions so every user is getting a password encrypted so even if two users use the same password they'll hash to different values because they have different salts and this defeats rainbow tables because if I know you have let's say 2 to the 8 is 65,000 let's say just 2 to the 8 salt that's 65,000 different so in order to break easily all the passwords that you have I have to create 2 to the 8 different hash different rainbow tables for each of those different F functions to be able to break any password so essentially you're kind of reducing performing a brute force search on all of those passwords assuming you're using a large amount of salts and there's not any other problems there so let's okay let's do this let's talk about on Thursday so on Thursday we're going to finish up whatever this is we're talking about authentication any extra time we have on Thursday you can ask me whatever review questions you want about that