 Let's get started today. First thing, announcement. So on Friday at 1.15 in BYAC, the brickyard, the C, the building that's in the courtyard there, room 110, we're going to be hosting a cyber security information session. So if you've been, uh, got made by the bug, we're going to do like, um, doing this crypto stuff and we like, uh, all the security stuff that we're talking about. We're going to be talking about the, um, a couple of things. One, the time security program we have here at ASU, which I believe I talked about at the beginning of the semester, but now it's more relevant because you actually know things. Um, so about specifically we'll talk about the concentration program. We'll also be going over the details of the scholarship for service program. So this is basically fully funded, uh, one year, I mean, at least one year. So every year of the scholarship you go work for the federal government. Um, it's fully funded and that pays for tuition, books, and also a second. So you can focus 100% on school. Uh, so I'll be there. There's also, of course, the best thing. There's free food. So there'll be food and drinks, um, there. So come by and say, hi, I'll be there. Do you want to talk more? Any questions on this? I'll also post an announcement on Piazza. All right. Logistically, let's see, going forward, um, I'm sad to announce there won't be anywhere homework assignments before the midterm. So, I know. So midterm is next week on Thursday. Um, the idea is I don't want to be doing homework assignments before the midterm. So you can focus just on the midterm. And then, uh, I also won't, like, two nights. I don't know, it's kind of going to work, but, uh, you also won't have a homework assignment over, uh, spring break. So you can actually spend spring break doing stuff and then we'll have a new assignment when you get back. So be ready to roll. Okay. Any questions? Midterm exams. Let's get away with all the questions now. We'll be in this room the exact amount of time. Uh, no notes, no smart anythings, no nothing. It'll be on everything we've covered up until Thursday. Yes. There'll be a variety of questions that will test your knowledge of the material. Would we have to correct the cipher possibly? Maybe. You should know how you've done it, right? Yeah. Are we going to study that? There will be a practice in midterm exam, though, where it'll be released soon. And the undergraduate kids will help go over that, so we'll all go over that in class if we're going to be in practice. Yeah. But it's not a study guide. The guide is study everything in class. Cool. All right. We'll try it all. So someone remind us what are the types, different types of authentication mechanisms that we talked about on Thursday. Signature. Some broad categories. Signature. Um, maybe. So signatures we talked about with crypto. It's a little bit different, but related to that. Biometrics. Like biometrics, so biometrics is testing what you are for the broad category of something that you are. Yeah. What do you know? What do you know? Like an advert? Yeah. What do you have? What do you have? So like the unique things that we've been talking about are a pop-up on your device. Yeah. So these are kind of the three main, and then there's other categories that we talked about, but basically what you know, what you have, or what you possess, and what you are are kind of three ways of categorizing this. And again, we talked about other types of ways, like where you are, right? Contacts, your location, those can add additional authentication mechanisms. And so. Okay. So I'm going to remind us what is the goal of authentication? Make sure that like someone not only is able to have access, but they should have access. Yeah. So it's not just what access should you have, but who are you, right? So it's trying to answer a question of identity of to this system, who are you in this system, right? Are you some random user, or are you a guest who doesn't have a user account, or are you the administrator of this system? And we know based on access control and authorization that we looked at, all those types of things need what you can do to the system. But to even start with that, you need to understand, well, who is this person? Okay. So we can think, and just like we talked about with crypto systems, right? We can kind of formalize and think about an authentication system in a similar way. And this gives us the ability to kind of reason about and think about different crypto system, or sorry, here, authentication systems even though they're wildly different, right? So passwords versus fingerprints, right? Those are testing not only different things, but they also have very different kind of ways of thinking about them. We can kind of think about them in this kind of standard way. So we can think about, let's set A, so some kind of authentication information that proves identity. And then some, we'll talk, and we'll go over through examples so this will make sense more. We have A, so A is kind of, you can think of your authentication information. So this could be your password that you know. C would be complementary information. So what kind of information is stored on the system that is used to validate your authentication information? Right? And we can think of, and we'll talk about many different types of schemes of doing something that seems as simple as passwords, right? And different types of authentication mechanisms have different properties. So for instance, maybe the simplest one would be what? What would be the very simplest thing for a password system? Yeah. So it's complementary information. So in the case of this model, C is the same as A. Right? So you just store exactly that password, and then is it easy to check if they're giving you the right password? Yes, it's very easy. Strength comparison, right? This is something you've been doing in an order of seconds in this class as well as others. And then we need some functions. So we need some functions to be able to map A to C so that we can check, so we can do the check. Right? In our case where A is equal to C, the complementary function is just the IG function. It just returns whatever it's given. So there's nothing complicated here. We can see that this can be made complicated. And then we have some function, L, that's going to actually do the verification. I think of L as login. So it's a function that takes in a piece of authentication information, takes in the complementary information, and returns either true or false. And then we need some way to update things because we just have this system. We have no way to say, like, well, I need to change my password, or I need to create or enroll a new user. All right. Everybody roughly. So we just talked about this in terms of passwords. What about in terms of biometrics? What would be the equivalent there? So let's go with the fingerprint. Yeah. A, we need your fingerprint. Well, let's see. Can the system actually store your fingerprints? Because it's attached to your finger, right? Yeah. What does it need to store? Maybe. Or what could it store? Yeah, attributes of your fingerprint, right? So it could take an image of your fingerprint depending on how the fingerprint scanner works. It could take a picture of it and store that as the image. And then in that case, so if C is a picture of your fingerprint, then what would your F function be? Something that maps the authentication information, your actual fingerprint, to the complementary information that's stored? Yeah, the scanner that takes the picture of your fingerprint, right? And then you need some function L. So do you want to do an exact match? If this fingerprint matches this picture, because we're going to start with pictures now, right? We're talking about the set C. So I sort of pictured your fingerprint a year ago, and I have a branding picture here. But I just say it matches, the pixels match 100%, means that you're going to go. And what's the problem, though, with trying to match exactly that? The picture is not clear. Right, because fingerprint itself, A, hasn't changed, right? It's just the end. If you think about, what about the back? How good is your picture? Does it include any background information? Because then that would almost never be the same, right? And then how do you make sure that you take exactly the right part of their fingerprint every single time? Otherwise, if it's even slightly off the thing, it will not work. So that idea was, okay, but we need a little bit of noise. And so then we have other problems of how do we actually do this, right? So maybe storing the picture is not the best idea. But maybe what could we or what should we store? Yeah, maybe data points, so what kind of data points do we want? I mean, that's all different. I actually don't know. They're different styles. I don't know how that works, but my thumbs are at least different. I can't really show you, that'd be weird. Right, so the idea would be, okay, rather than storing maybe an image, we kind of try to extract features from an image of the fingerprint. And then this would allow us to test that it's the same fingerprint over and over. Maybe we can extract attributes of a, I don't know, I've said it's a long time ago, swirls and circles and all kinds of different types of fingerprints so you can figure out what general class it is and then pick different attributes in there that you're going to prepare against. And then maybe you can be kind of impervious to some kind of noise, right? Because the key problem is here we can't store the actual fingerprint, right? We can only store attributes of the fingerprint. Yeah, right, so good. Okay, so in this case, A would be the fingerprint itself, right? C would be the attributes that you stored. Okay. And then what would F be? Yes, or whatever algorithm you'd come up with to create the features, extract the features from the fingerprint from the scanner, right? So F would be a function you can run on. And anybody's fingerprint will output you some features and then you need some way L because again, maybe your finger's sweaty or maybe there's stuff on your fingerprint or you've got cut so you need some kind of noise in there. Try to do that and do that comparison. And then S would be the ability to maybe enroll multiple fingers, right? Into the system or, well, you can't really change your fingerprint but you can change the fingerprint, I guess, that's associated with your account. Yeah. So can you still, the difference between C and F is like F something that implements C then? The only thing about A and C are just data, right? So A is your actual fingerprint. C is the data points. The question is how do you transform your fingerprint to the data points? And that's with that. And then L is the function that actually checks, okay, give me an A and a C. I will try to say whether it's actually, whether you hit successful logging. More questions on this? All right, let's see if this drags with what we did. Okay, so we have password storage and plain text. Yeah, okay, cool. So A would be a set of strings used for passwords. C is the same as A. They have the same, any string. And we just have the F is just a identification function. L is just going to be the Equality Operator. And we can use S to set or change passwords. Okay, so what's, one maybe problem with a password authentication system like this, super simple. Look at this, this is a essentially easy model. You don't have any framework around here. You don't even do anything interesting. You just take whatever they give you, Equality Comparison. What was that? You're about who, right? So you're, I don't know, look at it. Let's think about, taking these great shows is probably the best example right now because they're all using that, I know. So you've got a great scope. You log into using a password, right? So great scope maybe has access to your password. But they also have access of all of your grades and everything, right? So I don't know if they really wanted to, they could just change all your grades to zeroes and delete submissions. And we have no way to know that you actually made those submissions. So it's a really problem that great scope knows your password. And they have to, in some sense they have to know your password because they need to know A, right? Like what is the password that you're trying to log in with? But that might be the password. Let's say it's encrypted using SSL encryption from me to grade scope, using the public key infrastructure which knows how it works. So we can verify grade scope's identity so we know that nobody can impersonate grade scope, nobody can intercept or listen on my communication from me to them. Does that change it? It depends on how you want to do it. You may have restrictions on like, I don't know, you could say it's maximum a certain number of characters. You can attack the equality function in that it's someone optimized it to where it returns as soon as the character is different. You can brute force the password one note at a time instead of a whole password at a time. Yeah, let's say I have a constant time equality operator. Right, I can do that. You have to do more advanced stuff, but yes, and this is how you can break some systems. Maybe we'll talk about it later. Yeah, but still, whatever. People tend to reuse passwords. If grade scope gets compromised, then you're able to get all your, everyone's passwords. It's a good chance some of those maps with other people's accounts that may have more sensitive data. Okay, so grade scope, let's see. Okay, so grade scope can get hacked. And if they do, then somebody can see all of the passwords. So let's say it touched on their database. So grade scope, we can assume, is storing everything in a database somewhere. It's using a password in some table. And if they're able to break it, if somebody's able to break into either their systems or just the database itself, extract all these main passwords. Now not only can they impersonate everyone on grade scope and log it as them, they can also, how many people use the same password for grade scope as another site? It's okay to admit it. By the end of the class, maybe even this class hopefully will change that. Okay, what about any two sites? Do you reuse any passwords on any sites? It's gotta be most of you. I feel very confident there's a vast majority here. It's okay if you don't want to. So if somebody, let's say, got access to grade scope, what if you use the same password of grade scope as your bank? Your bank can log into your grade scope. Yeah, I guess. I don't know, maybe they really want you to pay back those two ones, though. I'll just go in and make a sensation for you. What if an attacker steals your username and password to prevent you? So you're an attacker, put yourself in the mind of an attacker. You just broke into grade scope's database. You've stolen all the username and passwords. What do you do with them? I would try to log into the same username and password to log into every possible site. What sites would you choose first? Every possible site is a lot. There's like a billion pluses of them. Wow, okay, yeah. So you could use, depending on the value of what you think the account is worth. Yeah, game account, what game account? You mind sharing? It was EA. And Steam? Yeah, so we've done some research on underground forums and there's actually a full market for League of Legends accounts that are at certain levels, various types of accounts. Things that you wouldn't think actually have value, but people will pay money if you get that account. So jumping back to grade scope, do they use single sign-on? And what's the benefit to a single sign-on model that just directly uses the name of passwords? I don't remember if they do or not, but let's save that for later. Thinking through an attacker, okay. So the first thing I would try is email services, right? So I would try Gmail. I would just try all the usernames and password combinations and the usernames, I believe on grade scope, are your emails. So I could see exactly which people have email accounts. I would try to log in with all those because as soon as I broke into their email, then I would set up a filter to forward all of their, or a rule to forward all of their incoming mail to another mail account and then I'd just do password resets on all of their other accounts to then get access. So I can read their emails, figure out what accounts they have access to, what things are high-value, and then from there, just reset the passwords. So you don't need to compromise their email really to do any kind of thing. Or by the way, if that doesn't work, then maybe other high-value targets. Okay, cool. That's the first thing I need to do all the time. Okay, so this is all the results of, let's say, grade scope maybe storing passwords in plain text and a hacker breaks it and steals it using a password. But is the only thing we're worried about a malicious, external hacker? What are some of the threats that grade scope would need to consider? A malicious employee. A malicious employee? Yeah, a grade scope intern that's there for three months and just copies the database to a flash drive and then sells it to somebody later. What else? Yeah, the server that they're using, maybe vulnerable or maybe is misconfigured and it's allowing connections from anywhere. Maybe they are really good at doing backups and they're using Amazon S3 backups but they forgot to mark their backups as not-world-readable and so anybody can find that and then download the full database to see things happen. Maybe, like, actually this happened to Twitter. Maybe, so, I know I've seen this. So some of you, I know you can use, like, printing out things as your debugging, right? Your programs to see if they're working or not. The, I guess, more professional term for this would be logging, right? So as your application runs, you have logging statements that log somewhere and everything that's going on. It's very easy to accidentally log a password somewhere and now you have, maybe not your database because your database is secure and everything but maybe the plaintext password is stored in some log somewhere and an employee can get to it. So actually, Twitter found this out. They were accidentally some place logging a password to a plaintext file or just part of their logging system so anybody that had access to the logs could read people's passwords. Logging a mistake that could happen completely not malicious, right? This is just an unintentional thing that could happen. Okay. So we talked about that. Good. Okay. What about a, okay, so lots of problems. Are there any benefits? Yeah, super easy to implement. What else? It would be fairly fast. Fast? Yeah. What else? If a user forgets their password, you can give it back to them. Do you ever forget a password? Yeah. It's actually as a user it's much nicer to be given your password, right? Although on the downside then now there's a trail in your email of your password so if somebody has access to your email now they have access to your password but from a user experience perspective it actually makes it much better than other techniques where I'm sure you're familiar with where they send you a link in your email that expires as they have a link and you create another password. All that's way more difficult than to say, yep, here's your password. So it's important, we'll talk about the dangers and we'll talk about a little bit of starting a bank back password but if you just think of something that's purely evil and bad and people are stupid as they use it that's not always considering kind of a whole scenario in the whole case. So let's also think about, and I still can't see my cursor. Okay, so now we have a shared system. So how does, we talk about authorization on the Unix system, right? We talk about the rewrite execute bits or owner group and others but how is actually logging in work and use your password so eventually you will get access to a shared server for one of the home assignments so all 370 of you have an account on this system that you can get into. How is authentication done there? Or how do we even know what user accounts are what? Yeah. Originally, you just have to link text to C slash password. Yeah, let's check that out. Yeah, so the file ETC password can you read this in the back? Is that big enough? Yeah, okay. Cool. So we have a file there, we can see it's readable write, it's owned by group. The group is root or it's owned by group root or it's owned by root and readable from everyone. So let's look up this. This is the problem of using a Docker container. Let's check it. Yep, same thing. Okay. So we can see there's a bunch of users here and the way this used to work was actually not plain text because, well, you can't have a file that's readable by everyone on the system that is also plain text password. So, okay, this file does many things. One thing is mapping. Okay. Where's the boot 2? Yeah. Okay, so it's mapping. So this is the data format here is separated by colons. The first column is the username. So username of boot 2, which I just logged in as. The second column and X we'll get to in a second. The third column is the user ID and group ID of that user. So this, and remember we talk about computers don't like to think about people with identities in terms of a string name. They want to think about it in terms of numbers. So to the system the boot 2 user is user ID 1000 and then when it needs to print it out like, for instance, there's a nice command you can run ID that tells you who you are and it maps your integer 1000 to Ubuntu. It says, okay, your username is Ubuntu and your user ID is 1000. How does this command know that user ID 1000 is the name Ubuntu? It has to use this file, it's not magic. So root is also user ID 0. So not magic at all. This is what this file is used for. So everyone needs access to this file. Right? So I'm going to ask this a simple question. Why don't you want to put plain text passwords in this file? It has access, right? It's insane, you would not want that. Everyone has access to this file. So if we think about what do we want from this system, right? We want to be able to prove that the user knows the password but we don't want to actually store that password in plain text. Maybe what can we use or what can we think of that could help us rather than storing the plain text faster? What do we know that's really difficult, easy to calculate forward but difficult to go back from? Cryptographic hash, right? A cryptographic hash, if I ask a password I can store it in this file and then presumably the attacker as we talked about would have to brute force that entire search space looking for that password, right? One of the key properties we wanted from cryptographic hash functions are that it's difficult to to find a collision, right? Or it's difficult to go back. So if you have the hash of something, it's difficult to find that input that generated that. And so this is essentially how cryptographic hash functions are done here. So let's think about this. Oh, there we go, okay. Figured out how to make it go back. Okay, so let's think. So we have this file. We'll do the hash. What do you want the root faster to be? Oh, you don't get the choice. This is kind of a common one. And I have a bunch of users here. Let's think it's all of you. I'm just going to, you know, I do, I've memorized all your names So student ones is the hash of password and student tooth password what I'm storing is the hash of foobar You need to step up our game. These are just, you don't know how it's ordered. It's the hash. All right. So we have all of these for 370 users, right? So we've done the hash. We can pick whatever our favorite hash function is .256 Whatever. So then how does that map into our model here of authentication systems? So what's A in this case? The password. And then what's C? The hash of the password. And then what's F? The hash function. And then what's L? Yeah. Does the hash of what's entered match the stored hash? Perfect. So actually, pretty easy, pretty similar, right? The only thing we're adding is hash functions in there, but compared to the password one, it's pretty good. So what are some benefits of this over plain text passwords? Like you said, that it goes in like the blender type thing, right? It's hard to get it back. Yeah, it should be difficult to go backwards if you get the hatches, right? And we can, one of the benefits, of creating a file that everyone can read, right? Essentially, all of these hatches are known. And we would hope that nobody can just steal the plain text passwords like they could when they were stored in plain text. What are some downsides due to the file? Two passwords are the same. And if they're two passwords are the same, the hash would be the same. So out of 370 students, how many of you think are going to choose the password-password? Hopefully not. Before taking this class. 37. 37? Okay. 10%. Yeah, it will be a number greater than one. I can definitely guarantee that. It's definitely... And if it's not password, it's going to be password one or password one, two, three, or something, right? So there'll be some fraction, let's call it, even 1%, right? Or even, let's say, you as a user, right? So you as a user, you change your password to password. You don't need to do this, but it's pretty easy. So you can do the hash of password, right? You can see the password in there. And you can see who else has this hash, right? And now you've broken the passwords of student one and student ten and all the other students in here that have this exact same password. So why is that? The input is password and the output is password. Also, I don't even need to do this necessarily, right? What would be another way to guess and identify who has what password here? If we know the hash, we can just try a bunch on our own machine. Yeah, if we know the hash, we have to assume people know the hash function, right? Because the system, like again, we're not going to do security through obscurity, just like a crypto system. Assume the adversary knows exactly how our systems work, right? So we can download this list. We can try let's even just dictionary words and see who has a word from the dictionary. We hash that word, look it up against everybody else in the class, and as soon as we found the hit and we match, we know we found it, we've broken that password, and then we just keep going and we'll probably get about 10 to 15% of passwords that way. So even though we have a case where it seems like, well, we've actually made a lot of progress, and even though this is a very frustrating thing, even though we've chosen this cryptographically secure hash function, why can we break it? It kind of has to be symmetrical in some sense, right? So however you're going to do this is the same thing with the tracking features from bigger parts, right? It has to be deterministic, otherwise you're not going to be able to have a lot of instructions. Hardly. But what, so why, then why can I break it? Why am I just looking through addiction? Yeah, people, so people are not choosing random passwords, right? People are, it's not like a message for the message maybe very long and I have no idea what the contents are, right? The password is going to be maybe 12 characters max and is going to be likely so if you think about the space of all possible 12-digit characters, that is very large. But if you think about what the space of what password people actually choose is much more limited so I can search in that space to break people's passwords and guess what they are which is much faster than trying to brute force let's say the Shaw hash, right? than trying to brute force 256 bits, sorry. Yeah, so definitely the problem is I mean, part of the problem is users let's say. More secure, could you stack different hash functions that talk to each other? Kind of. We'll get to that more later in a different aspect but fundamentally for this problem, no. You still assume the adversary can do whatever calculation, right? Assuming I know whatever complicated function you have, if I can put password in and then get stuff out, a constant thing out, then I can just check everything looking for that. So, as you said they'll expect for the password to be like 12 characters long and people are going to use words but that's where like using like something that generates your passwords for you, right? Yeah, we'll talk about that more. We're building up to that. There's something else over here? Could you hash both the password and the user name so they don't have the same hashes? Ah, okay. So the key problem here, right is we have two different users who both use the same username or sorry, both use the same password and the hash is only based on their username or sorry, based on their password. They don't actually do that and there's probably a good reason why. I don't know it off the top of my head. The idea is let's generate some random information to add to the password so that everyone else has a different so the idea is and this is what we're getting into here. We'll get into a more in depth in a second but the idea and this is actually already a concept that was essentially done by UMix to deal with this problem in the ETC password file. So the idea is called the, so you have hash and you're going to have assault so the idea is student one in this case would store the hash of so every user is going to have a different salt so let's call this one alpha so the hash of password and here we've been plus summing concatenation concatenated with alpha and the interesting thing is so to be able to recompute this I have to store alpha. So I'm going to generate some bit of information for everyone else so user two I forgot what their name was before we'll have a different hash and beta so now if user s370 has a hash of password plus 3 letters omega omega key key whatever, some new salt right the key thing is even though the passwords are the same because they have different salts the hash will be completely different sure so then how good is ok let's go through our attacker again right so the attacker now guesses password as the password so before the attacker just generated the hash of password compared it to everything and matched immediately 5% how do they do that in this scenario? yeah yeah so then now you're making the job of the attacker more difficult right so rather than doing one computation and being able to break everyone in the database they have to at least perform the hash on everybody's unique salt and this we'll get into it more in depth but this is kind of for now the central idea and this is actually what was used in unix systems and this was so that passwords could actually be stored in this EGC password file this is where all coming back to this this whole idea of being able to do this and so you can represent this with the unix standard hash function basically and interestingly having the 8 characters or less could actually not be more than 8 characters and then interesting had a 2 character hash ID so it used 2 characters as the the salts essentially and an 11 character hash and instead of like appending it to it because this was made it wasn't necessarily saved before cryptographic hashes but slightly different was that the 2 character hash ID would use different variations of DES so you have slightly modified different DES's exact same idea of using this but rather the salt being added to the password before being hashed here you have 4,096 different hash functions in some sense to use and all the login functions like login or su anything that checks your password would be in the s function but eventually and this is why we can see the x's here eventually they realize even storing passwords here is an insane idea it doesn't add anything really not everybody should be able to read even the hash of your password so that is why yeah they made an etc shadow file so it's owned by root readable by root and nobody else can read it so if I tried to cat this file it would tell me permission denied there are hash's stored in here I'm not going to show you it now I will show you it later maybe but this is what the what the x means here for the password means the password is not here it's an easy shadow file so then you can get around this problem and say hey it's a bad idea that everyone's hash is our public right even with salt but it does give a lot of good things cool so if we think like how this kind of process works essentially we can think that Alice as our principal talks to the service provider like a unique system and says okay I would like an account I am Alice my password is password and then it would use SF to generate an encrypted password which would look something like this so the first two digits there would specify the hash ID and this is the line in the EDC password file that we looked at user ID, group ID the name of the user and the last one is the shell use and so this password is A and it's kind of a graphical representation like the password that is given by Alice is A and what's stored in the EDC password file or EDC shadow is the complimentary information and this basically does the login function is pretty easy it does a check of call F on the password and check if it's equal to what's in there okay it's kind of an overview think about it formally and now we'll start digging in more and more into the details so what are our goals as attackers when we want to attack an authentication system gain the ability to use other users credentials yeah so we want to so okay one way to think about that would be okay yeah we want to find other people's credentials so how would that look let's say in our model what are we trying to find yeah we want to find a little A right in A such that for some F F of A equals C and C is associated with the entity we want we're just kind of stating that a little bit more formally right so actually this isn't 100% true we're missing L right so we still need L the login function so so what are okay so how do we do this then we've already talked about some ways step one in that process yeah so we're going to get the hashes right so at first so in our model we need to find C right so if we find C then we want to find something that when we run through our function F would give us C right so this would be we may have different models or ways to do that but what if we don't have access to the hashes yeah try all the passwords on the actual login right so try every password that we can give the system and we'll say hey I'm Alice my password is Foo and it will say false hey I'm Alice my password is password and it will say true now we know Alice's password right what's the key difference between these two scenarios uses publicly accessible and what publicly accessible interaction with the public system another way to maybe think about that is we don't have anything private like the actions information what else to think about in terms of who has what information what's another difference see himself what else so maybe in the different cases it may depend on the strength of F or C in some sense okay the attacker doesn't need to know the password or know the hash sorry yeah what about so the other thing is like it's interacting with the actual system so for instance it's kind of the difference well like we talked about this a little bit like trying to guess hash codes on a cell phone so what can so so in these different scenarios right how do we try to prevent an attacker from breaking our authentication system okay yeah so just like a cell phone right we can have multiple tries will actually mod you out or delay you what is that actually doing to the attacker delaying them right limiting their ability to guess over and over right and which of these two scenarios that affect the attacker both of them I guess are direct approaches having C or not having C yeah so this is the important thing this is why you ever log into like your own computer and maybe mistype your password it usually like takes a little bit a little bit of a delay from when you if you get it correct you log in immediately if you get it incorrect there's a tiny delay that maybe grows larger over time and that's to prevent somebody from sitting at your computer and just typing in and guessing passwords because it's going to slow them down over time right but if somebody stole the hash of your password there's nothing L can't do anything to stop them right because the login function is not involved there right bypassing that completely this is why the distinction here is super important especially when thinking about preventing different types of things right it's probably good to have an impulse but we have to be thinking about what's the situation so if we think okay well one way we can prevent this well maybe a general class of prevention will be slowing people down and maybe we can do that through L of locking the phone after three tries 10 minutes so that literally an attacker could guess maybe 10 three guesses for 10 minutes or something you actually though can get around that so I actually haven't played with it but there's a box I have in my office that I think it was for iPhone 7 so basically you connect the box through whatever the port was and it would start guessing pass codes and when it gets it wrong it would shut off the phone before it was able to save how many tries you had and then it would turn the phone back on and then keep guessing and you could brute force a like four digit pin in about a day and a half based on this device so yeah it's really like essentially bypassing this login functionality and so I think newer iPhones are much more secure in that sense but still like flaws in the implementation could allow an attacker around these anti-group forcing methods or for instance let's think of a website right so we'll use Gradescope again right now if you wanted to guess let's say my password on Gradescope you could try you know my email you could go try my email and my password or you could try password and then password one and password two Gradescope would probably let's say Gradescope is limiting your login so after three login attempts from the same IP address they say sorry you're locked out so does that mean I'm safe I could use a different IP in fact I could use I go into botnet that has thousands and thousands of IPs and I could just round robin all my requests through there and continue doing that such as that I never rise above the threshold that they think from any one IP address right I can even do that also helps a lot when you're dealing with a let's say like a banking site that locks your account after three tries and you have to call to get it unlocked well rather than breaking one account I'll just try password on every single email address I know of on that banking site right and each of them is one try and then I try maybe the second most common password on all the banking sites on all the users right so I'm doing it because I don't care whose account I break into I'm just trying to break into account okay cool so we're talking about we can maybe slow down L in order to try to limit the ability of the attackers they don't have C what else can we do to prevent delete the user's information we can think about that and like login in terms of the L like things we can do that L in order to prevent root forcing right it's a pretty drastic measure you don't have to really think hard about the user experience you can make it so that getting the hash the F function takes a long time that way if you're trying a bunch of them it's going to take a long time to try a bunch yeah so we can well and yeah okay so we can maybe think about this F function right we know the login function has to use F to do the comparison right and we know that the attacker they get the couple of entry information in the term we're thinking about a hash right then if we make that slow for them it will be very difficult to root force how slow do we want to make it what if we made it like 5 seconds because that's slow enough to slow down an attacker and one way we can make it slow we talked about multiple hash functions right why don't you run the same hash function a million times right just input into shot 256 output shot 256 and then put that back in new hash you do that a million times so that's more realistic maybe it takes 5 seconds on some machines is that secure or would that slow down to the fourth thing every time you login you have to do that right so the login process will take 5 seconds now so that's why there is this distinct tradeoff here between what you're willing to do the cool thing is a lot of these things that we'll talk about in a bit have knobs that you can tune to decide how long hashing something takes cool one thing we didn't talk about is you can try to hide stuff right so just like be better and don't give anybody your hashes right so for instance like Unix or Linux like we saw the EZC Shadowfile by moving the passwords there normal user accounts should not be able to read the hashes is that true does that mean that kind of this security you have to require there's some user that's trustworthy since we have this information like the super user yeah so in this case the super like somebody the system needs to have access to this information right in the Unix model the root user has access to this information and this means if somebody exploits the login or operating system in order to elevate themselves from a normal user to a root now they have access to all the passwords so it still doesn't anything's definitely more difficult and it's strictly better than just keeping passwords in the EZC password file where everyone can read it and it's very ironic that there aren't any passwords in the EZC password file but you still have this problem of if any of your systems are compromised so it doesn't necessarily prevent but it can make the attackers job more difficult and the other thing is well why don't we hide L the login function yes, username and password why don't we hide it how does the user get it it's something you really can't you can't you can try has anybody done this maybe their work or something it has login restricted only from certain IP addresses some people we work with some partners on some of our research and it's insanely annoying essentially what happens is one person who can access this system and everyone else asks them for information or we have to set up a VPN from us into their thing it can be a nightmare but you can try to do things like prevent or you can maybe detect when try to detect one thing to do that okay cool so in terms of website or in terms of what's the most dominant authentication system username and password do you actually use anything that's different but you use solely biometrics there's systems you have access to only if you provide a fingerprint like some phones have that now or you can play for most of it just basement sure so phones have that but you can also think that when you turn it off and turn it back on it won't allow you to use your face or your pincot or your passcode or whatever so there's still a password-based mechanism there what was it key-based authentication key-based authentication like what SSH so yeah using SSH keys not I'd say super popular but yeah definitely that's one that basically uses public key crypto to identify you so you're identified by possessing the private key what else so the the phone lock with the pattern yeah so that's still a type of password right because it's something that you kind of know and the other thing is they've got a lot of studies where users are very bad at doing random looking things so it can be actually pretty easy to brute force definitely there's also other there used to be things in windows where you could choose a picture and you would have to like set up an authentication mechanism of like boot these people on the nose and then draw a line from here to here and it turns out those also are very easy to break because people are very bad at generating random looking things like that maybe you're what about your maybe you have access to any buildings or anything with your ASU ID right so this is actually not a password it's something that you have just like a key so it's kind of funny that keys actually are something that you possess to authenticate yourself to a house but in the digital space it's all passwords and things in your mind and everything cool okay so I think we agree most common what happened so you've I don't know grown up using using a password system for a long time do you have any thoughts or feelings on them excellent five stars would recommend why why yeah it's a huge pain to try to reset your password used to be some sites where I literally never remember my password and so it's like you go to the site and you just immediately click forgot your password and you get a link and then you walk in and then it's good what else there's so many subscriptions and services that make you use a username and password and you have to like either use the same password to not forget or just have different passwords every yeah so you yeah exactly so even and maybe you're even aware before the fact that you shouldn't reuse passwords but you have hundreds of accounts online how do you possibly create a random unique password for every one of those yeah it's be crazy yeah so okay so they've changed like the requirements on passwords that change over time right so maybe they check for things like password and then require you to have a number and a symbol so people will do password one exclamation point yeah some things like ASU require you to change your password every so often yeah like my ASU requires you to change your password every so often we'll talk about that later but yeah that's frustrating like I know I don't know about you but I just had a pattern that I would rotate through I mean not for my ASU but actually I always had to say like password and then just like change certain things about it that was easy to type in every single time but then sometimes I forget it's one so you have to like cycle through each of them majorly try all of them before you actually log it any other thoughts? password history in one sense yeah so that's part of refreshing is they keep track so you don't reuse one it's like a muscle memory associated with it like you just said yeah and that's incredibly you know useful or annoying when you're on different sites right is they may have a a strategy for creating and using passwords would you like to share with the class? so one of the jobs I worked the password was you go up to your estimation point then you go down the second row so I worked on a submarine so it was the whole number of the submarine in between or afterwards and we just cycle which row we would use if this password was used on a secret system I don't know it's not very secure but a submarine was yeah so it's like a trade off between usability a complex looking password if you just looked at it but if you actually understood the patterns of the keyboard and everything so this makes a lot of sense as soon as it was in the military he had a crazy password for our system I was like go up this way and then down this way and then over and it's like my keyboard is like the ergonomic one so nothing like that it's a huge pain in the life of the system so maybe you have a scheme where you're rotating through those things another common way is develop a phrase that then you can only do certain words and replace certain words with maybe but it will be still easy to remember if you give like a 10 word phrase yeah so maybe rather than thinking in terms of passwords you could think of it in terms of past phrases and think about phrases what about how do you deal with the massive number of username and passwords password manager what else sticky note on the keyboard sticky note on the 100 things sticky note on the sticky word that has all of your passwords on your site I don't anymore but I used to have 10 passwords I used to use it with all of your passwords I guess it's a visual equivalent of a sticky note what else probably keep it related to your impressions on the site okay in what sense so just something that the site kind of triggers okay interesting it's like the it's like the thing they say to be able to remember people's names is like come up with a weird association with their face so you remember then later and use that as a password is that like cookies using cookies to track that kind of stuff like a new one I think it's more like a mental thing I know that some people are sticking out they actually have a part in their wallet is it the name of the site or username of the password so like a name that really makes you lose your wallet I used to have growing up basically I'd have like three different passwords and so it'd be like high value like email and banking and then medium and then low so like everything was low and they had the same password the medium sites had their same password and the high got their same passwords the problem is not if you ever try this the problem is always if that password doesn't apply to some stupid password policies of this new site even though it's technically a secure way to think and that is to remember a one-off thing for that stupid site mom actually came up with her own algorithm where she would use parts of the domain name she would have like a base password and then use parts of the domain name in the new password it's like how do you come up with this I actually yeah so see that's a similar structure so you're not, yeah cool so yeah the idea is like quotes from the books like subslice them nice okay so phrases maybe from homework assignments maybe breaking crypto things yeah so I think I kind of paraphrasing Churchill he's talking about democracy but passwords are the worst form of authentication except for all the other forms that have been tried from time to time so I think it's kind of something that my feelings about passwords is like they have all of these problems that we've talked about but it's insanely frustrating but they're still used so often because they actually do for all of their flaws especially with computer systems it is the best form we have right now right yes it sucks to get locked out of a site because you don't remember your password but it also sucks to get locked out of your house when you lose your keys so yeah there's kind of a lot of problems and some of these inherent vulnerabilities some of the things we've talked about they're incredibly easy to guess like human beings when we access a column of something random it is very difficult to a column of something that is actually random right and then but it's not actually just human faults right it's like now as part of the nature of a password system you have to memorize that super random thing so how you're going to call this like completely random that nobody else can guess but that is somehow meaningful to you where you will remember it the next time you use this site and by the way you can use a different password on all 100 sites that you use do you recommend using password managers yes I do we'll talk about that in a bit and I'll kind of explain why other things they're easy to snoo not just so as passwords are transmitted over the wires we're not using encryption or SSL so many can steal passwords there is a great thing at the DEF CON security conference it's a cheat and so they sniff all the wifi traffic and some things like like mail like pop checking or ftp or something will actually send passwords in clear text and so they sniff for all these things on the wireless network when they see it the username and password that they see shows up on this wall over time and yeah so it can be very easy to accidentally snoop and then you have snooping in person right I think somebody typing their password is not difficult to kind of see what they're typing in yeah my uh so I live in an apartment complex and the resident portal sends the password over httpp.get request in the url encoded string so I was like stopped it and I was like well there's my password yeah these are the type of things people look for yeah easily sniffed and detected yeah yeah it can be stored I mean if you're using the browser to store your password it's stored in the file on your computer which means if anybody has access to your computer they've accessed all those passwords they can also be easy to lose and it's very difficult we talk about this no control on sharing if you share your password with somebody there's no guarantee that they will share it with somebody else and somebody else also very susceptible to social engineering and specifically phishing so one of the classic social engineering attacks would be you call up somebody who works at a company say hey this is Adam and IT I can hear you having problems with your computer and they say yes finally thank you for calling me and you say great well just for me to verify your identity and so you are who you say you are please tell me you're using a password so before we proceed for your security you know whoever allies you have a password and you go great and you walk them through some stuff and now you're sold and you use your password or in the more the phishing context I trick you to click on a link that takes you a page that it looks exactly like great scope it's an email that says hey you failed your latest assignment term in and you go what I just got 100% I know it you click on it it says you've got to walk in password and unfortunately that is a site that's actually controlled by an attacker and they've just collected your username password and transparently redirect you back to great scope so you never notice that anything was different this is actually one of the big things we try to look at and solve in our research of studying phishing for big brands like Paypal and Google and these types of things there's also a lot of practical vulnerabilities like we said visible like your password has to be transmitted and so it's visible of our insecure distributed network systems susceptible to replay attacks where somebody gets your password and you can log in as you and password reuse is a huge problem and it actually puts a ton of burden and effort onto users because now the users have to deal with this burden of remembering passwords but choosing a unique password but choosing a unique password per site that is all of this insane complexity and it's easy to screw up as we saw so companies can start passwords in plain text which just increases the severity of the problem cool and so we've talked about these so once some types of attacks would be like a dictionary attack just try each word in the dictionary or a word file compute the hash check that the hash equals the authentication and it's super easy to search all likely passwords because we can't even we'll get to them later we'll look at Adadumps and we can see what passwords are commonly used by people yeah so we can have different types of attacks so this goes with the different styles of authentication we can have an offline attack where we know the function and we know the complementary information we've stolen the hash we can repeatedly the other type of dictionary attack is an online attack where we're attacking the login function itself so we have access to L and we just keep trying guesses until it succeeds cool okay and when we get back on Thursday we'll continue with how to stop this