 So are you all friends now? Are the assignments over? Where will grades be posted? Where will they be posted? In your email boxes. We'll email you when those are done. We'll grade assignment three so you'll know exactly where you are up until that point. Any other questions? I saw there's a microphone right here. Yeah, it's out of battery. No, the microphone is at the desk. I don't want to use that one. It's a handheld mic. I'm not a stand-up comedian. Can you hear me in the back? If there's any problems, I will yell louder. Any other questions, comments, midterm? Yeah. Will the test be handed back in here? Or would you just get our grade? I'm sure yet. We definitely won't hand it back here. We may give it to you digitally so you may be able to figure out exactly what happened that way. Is there any way you can kill the static? Yes. Probably. Like that? I didn't know it was an experiment that we were doing. Subliminal messaging through static. It was not. Against IRB rules. All right. Well, let's jump right in. Cool. Okay. So, it's been a long time. Somebody remind us of what the heck we were talking about before we went on this midterm break. Yes. We were talking about authentication systems. What's an authentication system for? Who do you say you are? Are you who you say you are? Or who are you? Right? Exactly. Both of those. Right? So who are you in accordance to the system? What kind of things make up an authentication system? Yeah. What you know. Something that you know. What else? What are other types of authentication systems? Yeah. What you are. What you are. Location. Maybe location. What you have. Anything else that we talked about? Cool. All right. That's good. And so, we talked about abstractly. We can define an authentication system as something that tries to prove the identity, our identity, against the system. So, we have some complementary information at the store. We have a function to map the user identity to that information and a function that verifies identities. So, okay. So, we looked at initially just a password based system. And this was password stored in plain text. Or some of the problems that we discussed when we talked about storing passwords in plain text. Yeah. If you found the plain text, you broke in the system. If you find the plain text, you've broken the authentication system because now you know that password. And so, you can authenticate as that user. What else? Timing attack. Yeah. So, if you don't do this correctly, there could be a timing attack in detecting the password itself. Yeah. Anyone that has access to the plain text that like work on the website have access to the passwords. Right. So, anybody with access to the website or the database has access to all of these passwords, which they can then use to impersonate other users. Anything else? Yeah. So, if this database is ever leaked by either an employee or a vulnerability in the website that allows somebody to leak the password, it's highly likely that that username and password is used on other websites on the internet and the web. So, you've basically broken the authentication system there. So, now we move to the, we initially started very briefly talking about the UNIX standard way of doing password hashes. And so, what was, so where were traditionally passwords stored in a UNIX system? EVZ password. Yeah. P-A-S-S-W-D. Right. And that file, as we saw a couple of months ago, what we saw is world readable. So, clearly putting the plain, the plain text passwords of every single user in the, in the EVZ password file that's readable by everyone is clearly a terrible idea because then you can see everyone's passwords on the system. Actually, a funny side note, did anybody go to the our cybersecurity symposium on Friday? Did you listen to the talk by Mike, who was the keynote speaker? He had a really, so he's a pen tester at Bishop Fox here. He's actually a manager, but he started as a pen tester at Bishop Fox, a local company in Phoenix. And he specifically talked about pen testing a website where they broke, they had a blind sequel injection, which means they could leak one bit of information from the database. And so doing this, you can eventually get all the information, but they're on a limited time pen test. They couldn't get all the information. So they started leaking the password field, but they saw that it was a crazy pass, like the passwords were being hashed or something. They looked into it more. They figured out what stored procedures there were in the database. And they figured out it wasn't actually a hash based algorithm. It was using an encryption key to encrypt the passwords. And of course that key was stored in the database itself. So there was a stored procedure called decrypt password and encrypt password that would use the key. So by using that function, they were able to extract admin credentials from this database. So I thought that was, I don't know what I was saying. I was like, oh my gosh, we just talked about that in my class about why that's a bad idea to use an encryption function as your your hashing function. Okay. So we would think that we, okay. So we just said we don't want to store the passwords in plain text in a shared readable file because everyone can read it. So why don't we just hash them, hash the passwords. Use SHA256 and call it a day. Yeah. People can pre-hash a bunch of really common passwords and then just compare them. Right. So yeah, we looked at, okay, well how would you break this? Well, you can see on the passwords, you know that the string password will hash to a certain value and so you can actually pre-compute this list of possible passwords and with rainbow tables, which we may get into a little bit, but the cool thing is that you don't need to store all the data but basically you can store all these hashes, pre-compute them and check them against every single user in the database. So we said, well maybe a better way would be to kind of customize in some sense each user's either hash function in some way and so this is actually the unique style of password hashes or the initial style. So first interesting thing is your password is a string of eight characters or less. Is that a good or a bad thing? Yeah. Good for hackers? Good for hackers? Okay, we'll talk about from a security a defensive perspective. That length of password is going to be relatively easy to remember compared to if you had a really long complicated time. Yeah. So you have a trade-off here, right? So the interesting thing is that it limits you to eight characters. Why wouldn't it let you have a password of 20 characters or 25 characters? We can take really long to hash. Possibly, especially maybe back when they were defining the standard in the eighties, seventies, maybe it could maybe they want to minimize hash collisions. They want to minimize hash collisions? Yeah, that could be, but assuming you have a good hash function with 256 bits of output if that's what you're using. Yeah, I mean it's honestly looking at it's a clear design flaw because why would you limit the size of passwords? Like you should, if somebody wants to create a password with size of 20 or whatever just let them do it. It's not a big deal. And so the complementary information, so the basic idea is you'd have two characters that would specify what's the hash ID and you'd have then an 11 character hash of that password. And the idea is these two characters, so how many, so you have then those two characters mapped to essentially they made, so this is what we talked about a little bit before we'll get back into it. Rather than just using a salt that they add to the password, they actually change DES depending on which version of this hash out, this hash function is used. So they have 4096 versions of DES and then you have the set of all possible, the set of the login functions as well as the program to change passwords and do all that fun stuff. So now if you have two, so now you're looking at this database, how do you break passwords? Or how do you guess people's passwords? So let's draw a nice, lovely picture. So you now have, so for every user's password, you have some, we'll call it a hash ID and the actual hash. So for every user on your system you have this, well I guess this would be see the complementary information. So you have a bunch of users on the system, how do you break passwords? Yes, you have a password, let's call it a password. So what that does is you then look up what's this hash ID because that's going to tell you, essentially you can think of it as this gets passed to some different combination of DES and there is no key involved here, it's just running DES in term to do that and then out comes this hash. So the way that they think about it is this hash ID, basically you think of you have DES0, DES1, DES2, DES3 all the way up to every different, so this hash ID tells you which version of DES that you use for this. This is before they had really good hash functions that they knew how to use. How's the hash ID generated? Randomly, so when you create a user you randomly generate a hash ID, so you take their password to password, you randomly generate a hash ID, you run it through here and then you save it in terms of the complementary information. What's the length of our alphabet or the hash ID? Two, so two character, two character hash ID, 11 character hash. What's the range of characters I guess for the hash ID? That is a good question, I don't know it off the top of my head. I think it's hexadecimal or something approximating that, but I don't know. Yes, well, I think if you look at it there'll be a colon in between them to separate them, but yeah. Okay, so one way to do it is to break an individual user's password. Right? What do you have to do? Take the hash ID, figure out which version of DES, and then keep guessing random passwords. Will that information of what you're trying to guess of the random passwords help you break other user's passwords? Only if they have the same hash ID. Only if they have the same hash ID. Why? Because if they have a different hash ID it's a different function. Yeah, so let's say I have user zero and this is hash ID, we'll just call it zero, and then I have user one who has hash ID one with some other hash. If these both have, let's say their password is both password, will the hashes be the same? No, they'll be different because this hash ID is different, can't they? Are the hash IDs public information? Public information, they're stored as well. Public in the sense that they're stored with the complementary information, so if you steal the hash, you know the hash ID. You use the hash ID over here? It, I think, no, technically it uses the way it was. Now it uses proper hashing with solvent, but the original way it was done they tweaked some of the parameters of DES and I think they use a zeroed out key and they may do it a couple of times so they may run DES on itself on the same input a few times. I don't, but yes, this was before they had a good hash function that they could trust to use. Was there a predetermined one-to-one relationship between hash IDs and the DES version? Yes. In the sense that if you know hash ID maps to this version of DES then that would be consistent across systems. Yes. So, could you create a pre-computed list of common passwords to hashes? Yeah. Yes, how would you have to do that though? Maybe. Right, you have to have 4096 copies of those for every, for all the possible different hash IDs. You can still do it, right? So the idea is you're making essentially you're making the problem more difficult for an attacker rather than just completely pre-computing this list and you know in a given hash function password always hashes the password. Now with the hash ID and then the nice, the better way to do this is to think of this in terms of salts. So, you have the salt and the hash C0 you use a good hash function like, we'll draw 256 and then, so actually UNIX is slightly more complicated if you actually look at a EDC password file or the now the EDC shadow. It's basically something like the hash algorithm to use and then the salt and then the hash. So this hash algorithm would say this password is saved with shop 256 hashing. The salt can then be so now when you have the password in when you say password now this goes into shop 256 and usually you can catnate the salt with the password and then out comes hash prime which you then compare with hash. So now by making salt significantly large now you can make essentially to break passwords in this the attacker needs to guess for every single user because they have a relatively unique salt so it would be difficult for them to pre-compute this. Questions? Yeah. Yeah, you said that they moved passwords from the shadow file? Yes. Was it just because the other one was more readable? Let's see. Yes, so they realized they should have downloaded the EBC password file and do brute force cracking of passwords and because people usually choose very terrible non-random passwords, right, there's a tension between users of a password that's easy to remember for them and a password that is difficult for an adversary to guess. Right, if you if I just used my first name as my password Adam that would probably be something that you would guess to break my passwords. Plus you can do an automated system to do this to break passwords very, very quickly. So they realized, okay, it's not a good idea for everybody to read that file but that file contains important information. It maps user IDs to user names. It says what groups those are in. So that needs to be accessible. So now if you see in the ETC password file there'll be a star where the password feel is and that means looking ETC shadow which is owned only by root. So something like login when you're logging in that process acts as root to check your password with the ETC shadow file. So it uses the setUID functionality to do that. Is there any reason? No, I think now I do not believe it is but that would be interesting to find out. So no, I'd say now the general advice is you should be able to accept passwords that are as long as the user wants them to be up to a reasonable size. Nobody's going to remember a megabyte long password. Is it random? Yeah, so the salt would be some kind of random depending on how much I mean it would depend on the hash algorithm usually but there'd be some randomly generated bits of entropy that makes it so that every user should have a different you can't pre-compute a rainbow table against any of these given entries. So you want it enough bit such that it's highly unlikely for multiple users to have the same salt ID like I think 496 is not big enough. I would probably just do a 32 bit salt or whatever I mean something. So actually the better thing to do is to never write your own one of these and use a library that does it for you. That way you don't have to think about it. Yeah, so the salt is the hash ID you. Here, so the way I mean you can think of it like that but really what it does the way you do this is that you just before you, so I'll make the diagram a little bit more correct, you have shot 256 you take the salt and you can either pre-pend it or post-pend it to the password. So this would be concatenation so you just concatenate those together you now have a unique string that way as long as the salt's different your password is password or your password is two the password is the same it will still get mapped to different things and because this is a cryptographically secure hash function you can't go backwards even if you already knew that salt you still can't go backwards. Any other questions? Salt again? The salt is a just like in before where we had a hash ID it's essentially randomly generated say entropy but randomly generated that you add to the password before you hash it such that different passwords hash to different values. You mean the same passwords? The same passwords hash to different values different passwords should always hash to different values so this way the same passwords with different salts hash to different values. He was... Sure. If you find out the salt would it be a vulnerable solution? I don't know you answer that tell me. So if you know the hash or if you know the salt then what do you also know? Assuming you can get this salt information what else can you get from this diagram? You get the salt, the hash and the hash algorithm right? So you have all knowledge of that so then how do you break the password? Just like before randomly guessing but the difference is now you have to do that on a per user basis if you have a million users you have to try to break each user's password individually and you essentially can't reuse your computation to say oh what's password out of all of these millions of users or who uses the password QWERTY out of all of these millions of users you have to test every single person and redo this hash computation. So but it's still vulnerable to this but if I said if this user is user admin then maybe that's the user that I want to break. I actually don't care about breaking any other users. So why can we use a brute force dictionary at SAC here? Why can we? You just said we can. I agree with you. I said we can't if we know the salt. You always have to assume they're stored together right? Fundamentally they have to be if it's a secret information then you basically are into the realm of encryption and you have the problem of how do you actually keep that information secret? So you have to assume if the hash is public that the salt is going to be public. So what's the why is this vulnerable to a dictionary attack? Depend on the salt to depend on the hash compared to the key part. So you know the salt you can just keep guessing password, depend the salt, and check the hash and find it when you break it. How long does SHA-256 take? 256 seconds. It does not take that number of bits in the output but that's really fast, right? It's used to, I wouldn't say encrypt, but hash in a lot of areas. I think there may even be an Intel there definitely is an Intel AES instruction so they do AES, they can do AES on the chip. There may also be a hashing function like SHA-256 on the chip. Why do you want it to be super fast? What was the point of a hash function? Timing attacks. Maybe timing attacks so you want to reduce the time it takes to ah, there's other stuff involved there but yeah, part of it. What else? If it's slow nobody uses it, right? And what are hash functions used for not in this context? Integrity, right? The integrity of a message. I can send you the message and I can send you the hash and you can compute the hash across that message to verify that it's actually what I sent. And if that hash is slow if you're trying to run a hash on gigabytes of data you'll never do it and nobody will ever use it. So you have this really interesting property. A hash function needs to be as fast as possible. In this case, is a fast hash function good? No. Why not? Because it makes if you're viewing attack it's easier for them to brute force because it takes less time. Right, because once an adversary gets the salt and the hash the faster this hash function is the more passwords they can try in a given amount of computation. Right, and if it's in hardware they can do it very, very, very, very, very, very fast. So what do we do? Yeah. I had a different question. When we were talking earlier about pre-computed tables, how does that work if the salt is randomly generated? You fundamentally cannot have a pre-computed table. You can't pre-computed you need to compute it here when you have this specific user that you're trying to break. There are more hands here. I'll go back to what I was talking about. You may answer. Okay. We're going to go back. So the problem is that it's fast. But what other properties do we want about the hash function? Do we just use something like CRC32? Yeah, we want to make sure that passwords are similar to each other. Quarty versus Quarty1 should hash to completely different things. What else? They should have pre-image resistances. Pre-image resistance, meaning so you can't find two messages that hash to the same value and then you also can't take a hash and go back to find the message. Yeah, specifically here we really care about that part. We don't want to be able to take the hash and just go back to the password without guessing all possible passwords. So should we just get rid of the hash functions in general? Yeah. What are you going to replace it with? Blind trust. Better passwords. Better passwords, good luck with that. I will just say that's impossible and continue on. So it's a tricky problem, right? You have these properties, cryptographic properties that you can look for and there are things that theorems that will try to prove these things, these properties of these hash functions that you desperately want. But they're very fast and you don't want that part. So what do you do? How do you make it slow? Come up with a new slow hash. Make the password or salt larger? I guess not the salt but just the password. Maybe make the password. How do you make the password larger? You can increase the characters that are allowed or you allow the length to be larger and set like a minimum. So for people to use like 100 character passwords, I still think, I think the difference between hashing 8 characters or 100 characters is minimal. You need to get to the gigabyte level. But then when they're doing a brute force attack, it takes much longer. Because of... Because the password space is larger. Okay, so if you're requiring them... So basically, okay, so good. So one thing would be with the passwords, make it so that the search space for passwords is huge. So if you require every user to have a 100 character password, of course, what are they probably going to have as their password? 100As? Yeah, that would be my first guess. Or maybe just 100 zeros or... I don't know, honestly, probably nothing. Like nobody would use your system because it would be impossible to remember or use a 100 character password. I mean, if no one uses it, you know it's secure. It is very secure. I'll agree with that. I wish you good luck with your service. Okay, so that's one way, but that is fraught with error and peril. Because even when we try to help users create difficult-to-guess passwords, it's hard to make that actually do that well in such a way that they'll remember it and where they won't just do things that completely undermine your security. Yeah. I'll be passionate multiple times. Why would we do that? To make it longer to because you have to do that multiple times. So how many times? Twice? Probably more than that. Yeah, maybe 5, 10. Well, that's maybe still not going to do it. A thousand? 100,000? A million? Maybe? Okay, so then let's think about that. So what would be, let's say a good... What are you going to target for? What's the time you want it to take roughly? A year? Okay, let's go with that. So one year. Okay, cool. So this process takes a year. How long does it take to create a user? One year. How long does it take to log in? One year. Is this a usable system? Yes. No. Maybe like 5 seconds. So you want like 5 seconds? Okay, so then let's think. Sign in? 5 seconds. Can it take less than, or let's say creating a user? 5 seconds. Can it take less than 5 seconds? Maybe. How? So if it's like a multiple like page user registration when they enter their password, you can do the hash like then. Okay, you could technically create the hash in parallel. Okay, so what about logging in? 5 seconds. Can it take less than 5 seconds? Probably not. Why? Right, you have to perform the exact same operation. You have the hash for however many millions of times it takes to be done in 5 seconds. And then when you do that, you compare the hash with what you've got stored, and then you let the users into your website. Now, if we flip that around and say we're an adversary who has broken into this website, how many passwords can I guess per second? Zero. Like a fifth of a password. A fifth of a password, right? Yeah, so 0.2 passwords per second. So it's going to take me a long time. How long is it going to take me to try like the top 10 or 100 most common passwords? Like 500 seconds. Yeah, like 500 seconds. That's pretty slow. I don't mean it depends on the value of these passwords, and maybe they will announce, but this is just for one user who think about having a million users. We've added some security in here because we're able to do this. So, the tricky thing is so if you set this password to be for 5 seconds, what's it going to take a year from now? Maybe not, I don't know, but likely less, it's possible that it takes less and less time as computers get faster and faster. And so but anyways, this is the basic idea of creating kind of hashing functions that are either slow in this sense. Usually I would not say 5 seconds. I'd say on the order of like 1 second is usually what you want. What about those systems that like lock you out for like 30 seconds after? Okay, perfect. Well, we're going to get there, but we can just keep talking. So, in this scenario, what do we assume the adversary has? The hash. They have the hash, they've broken into the database somehow. They have the hash and the salt and the hashing algorithm, right? So, in this case, so we call this basically an offline attack in that I don't have to ever ask the system if this password is right or not. I can just look, I have the hashes, I can perform the computations and compare hashes. That's different than can I still try to guess password even if I don't have hashes? Yes. Yeah, how? Passwords. Just go into the thing, figure out either usernames or email addresses. Go to the thing, try foobar.gmail.com password-password. Right? So, the difference is that's an online attack because you are interrogating the system itself and then you can do all these kind of things like exponential stop and wait. So, you can wait for the user and see, okay, you can actually artificially enforce a one-second delay in here and then a two-second, five-second, ten-second delay in here. But the problem is if that delay is artificial it means that so, let's say you have a one-second here artificial delay and you're doing SHA-2 for D6 for offline mode so how long is it going to take them to guess one password? Yeah, SHA-2 for D6 time which is incredibly like in the milliseconds to nanoseconds time frame. So, this is a core concept to think about, like, good to put defenses here on online guessing. Anyone ever accidentally wipe a cell phone? No? I have a friend, so Microsoft a lot of companies if you join your cell phone to their network or if it's a work phone it's a policy in place, so have you ever done that where you try to log into somebody else's phone with their passcode? You try once error, you try second time error you try third time, it says you're locked out for 30 seconds. Have you ever waited? You try again, you're locked out for like three minutes. Do you know what happens after that? Well, it depends on your policy the Microsoft one wipes your phone so one of my friends was messing with another friend and did that, got to that last part of my thing, phone. Luckily they had all the data off there, so it wasn't a huge deal but, yeah, I'm pretty crazy how good it was here. And actually, even on the reverse side, I don't know the state now, but we were looking at iPhone security and iPhone forensics and trying to break pins and you could, you used to be able to, I think it was on the iPhone 7 I saw this device in my office, you get this device you hook it up to a certain part in the phone and then you hook the other one up to the, I think it's the lightning cable at that point it would guess passwords and when it got to that thing, it would actually just shut off the phone through that other hardware thing, so it wouldn't set that thing that says wait 30 seconds. And so it restarted the phone and it was able to guess like a four digit pin within a day even with that stuff, so I think that was the iPhone 4 when it was first vulnerable to the phone. Yes. So there was software based ones that you could tell it to not do that in software, this one required like a hardware device on the phone so we could kill it before they would say that. So the phone was able to turn off and back on in under 30 seconds. Yes. So it would be quick enough to keep guessing when you got to that point. And my timings may be off, but it was within the span of a few days you could break the code on the phone even if it had those features. So yeah, basically turning these offline components, disabling them so you're essentially trying to do the speed as far as you can get to an offline kind of attack. So then like you said it was like iPhone 7 so like what would they update to make that like not be able to work? They I believe now if I remember correctly so the security enclave which is what they have so the same place that stores your fingerprint and does fingerprint checking it's actually not in the kernel it's in a separate part of the CPU called the secure enclave. I think it's similar to secure world on an arm system. I think that's what was actually using after the hood. And basically they do I think they do everything in there so they probably have ways to like that's all secure storage so that even if you rooted your phone you still can't touch and mess with that storage area. So I think that's how they're able to get around it but I would not be surprised if they're still other hardware based bypassing for it. So when we're talking about making SHA-256 take longer by hashing it multiple times what would the advantage of I mean the advantage of that would just be that you can use SHA-256 in multiple applications because I'm just wondering like why don't we just make a hash function that's slow then because that seems to be what we're doing anyway. Exactly so there's different and there actually is a need for slow hash function. The problem is when you're developing a slow hash function how do you know your implementation of it isn't slow versus the actual underpinnings of the algorithm are really slow right because if you let's say you made a version of SHA-256 that was super slow that took whatever 5 seconds per hash or 1 second per hash now I'm an attacker I study it I build a version on an FPGA to do hardware based hacking of it and now it takes milliseconds to do that computation because when you do this you basically incentivize people to do that so yeah there's a couple different things so S-crypt was one of the first in this area trying to make a deliberately slow and tunable hash function and then there's B-crypt one of the things I think with S-crypt if I remember correctly S-crypt uses basically hashing functions and it uses a fixed amount of memory and so it's easy to turn that into create hardware to do that very fast B-crypt I think deliberately uses a lot of memory when it's doing its hashing so that way it's hard to do that on an FPGA without it being very expensive but yeah there's a whole basically research component to there developing now these slow hash functions cool okay well we already kind of went through all of these going back here so as an example of the EPC password file Alice with her password here so the first two characters here are the hash ID the rest is the hash cool okay so we actually have already been covering a lot of this but now we'll kind of mix in our intuition of what we're talking about of attacking these authentication systems with more of that notation that we talked about so what okay let's talk about this what is the attacker's goal at the password to get what password to so one goal could be just get a password to an account get a specific level password get a specific user's password to authenticate as the target does the attacker always need the password to authenticate as the target maybe maybe there's some bugs in the authentication mechanism which allows them to log in as the user did I tell you dropbox bug I don't know if I have any slides but I don't think so there's a bug I think it's back in I want to say 2011 maybe in 2009, 2010 you can actually google this because they have a blog post where dropbox somebody realized they logged on to their dropbox account on the web and they knew they fact fingered and mistyped their password they hit log in and they still logged in so they logged out they tried putting I think a friend's email address in there with a random password hit log in and it logged them in and so then they emailed dropbox and some developer had pushed a fix to some code I think it may have been like an equals versus double equals kind of a problem but they had accidentally pushed some code to production that essentially disabled the authorization check or the authentication check so you could log in as any user without a password at all so these things happen these could be bugs they could be we'll talk about later some more software based problems that you can use to bypass authentication and so cool so basically this is just a more formal description of what we were talking about right the attacker wants to find some password to log in or maybe you want to find a specific user's password and this was the what we talked about you have this offline versus online versus offline mode where online you are querying the service itself or as offline you have basically the complimentary information and you're trying to figure out the password okay and this we talked about already you can try to hide stuff but you still like we said it's hard to hide these you know you can't make the assumption that these in restoring passwords that the password is going to remain secret forever the internet is littered with password password breaches so simply relying on that is going to be a terrible idea other things so this actually has to go into kind of a similar topic of what we talked about when we talked about encryption so can we hide the login mechanism L for certain systems for certain systems like what if you have to go to a specific location so okay maybe if you have to go to a specific physical location to try something what else so L would be the login function so can you actually keep it so think about it this way so if you can keep L secret can anybody break passwords on your system no because they have no way of telling if a password is correct or not but can you actually keep it secret what was that it's part of the key essentially and it has to exist on every server that uses that yeah similar to the encryption problem right it's like yes okay you could make your own custom encryption algorithm and never tell anyone but now the algorithm itself becomes part of the key and here now your login function becomes essentially part of something you need to hide and where are you going to hide it you're going to hide it in the source code that's running on your servers I mean something has to actually do this login function so it's best not to rely on it if the authentication mechanism was something like a blood test what would L be in that case would it be like what they're checking in the blood to figure out it would be the method because you just can't I mean you take a blood sample but you can't just I don't know at least I don't think you can just compare blood right away right you have to take the blood features from the blood you take probably the blood type you probably take some other features and then match those against the features that you've stored so in that case would it be would you consider that to be hidden or not I would say no because your features would need to I mean well you could try to claim that you've hidden L but fundamentally I mean it would not be terribly difficult to figure out what features are you comparing right and then figure out a way to break that or try to bypass it or brute force it again a thousand people and keep trying blood samples until I match the one that but in that case it seems it feels I mean it might not be hidden like a process but it's not like doable by most I mean I would I'm gonna say like everyone but like I guess most people like maybe if you own like a lab or something you can do it I think it depends on your front model in this case so since we're already talking about something that most people don't use like blood based authentication I would say that you now would probably you probably be worried about nation state level adversaries and part of what they do is intelligence gathering so figuring out what features you're matching against would be one of those things I would expect them to be able to figure out and I would not rely on them not being able to figure that out that also makes sense so we've been talking about this a bit so okay you what was the first computing device where you had to have a username and password so you know maybe the computer itself to log on but how old were you that's why I'm trying to get that when like what age did you first use your first password based authentication system very young Neopets Neopets nice old school so long time so how do you feel about this you've been using these systems for a long time they're okay they have their flaws will be more specific you are the people who use these things right it's not just I mean literally everybody uses them yeah they can be hard to remember passwords can be hard to remember has anyone ever forgotten a password sucks can it be hard to remember sometimes like oh sorry let's go over here first if you try to be like smart how like a long password can you have to make a little long password all the time right so you have that user experience problem where you either intuitively or you've learned that having a long password is better so you want to have a long password but actually typing that in every single time correctly is a huge thing yeah user names or like emails can be hard to remember yeah user names or maybe even user names so that actually is a problem sometimes like what of all these emails and user names that are used on the site policies regarding passwords can make it more difficult policies regarding passwords so can you elaborate on that so some sites take policies of you can have special characters but only specific special characters then other sites will have you can have any kind of special characters or you know and then there's anything in between yeah so I'm gonna like you can't your password can't start with a number yeah or your password can't have exclamation points or right yeah or spaces can't have spaces in a password yeah that's good as an addendum to that when you fail to login on a website like that it usually doesn't tell you which requirements were made that's always very annoying I do hate that as well everything uses a password so you have to remember like yeah not just passwords but you know you have on your credit cards or debit cards you have pin numbers your phone probably has a pin number backup what other non-standard devices use passwords those are just two that came to my mind but I don't know I don't know house lock maybe a combo lock for your bike work work pass codes yeah we had that at when I worked with AT&T government solutions we had like a passcode for the door to get in garage door still a door but garage doors yeah that's good a different password for the garage door so how do you manage all of this complexity and you've been dealing with this for a long time how do you actually deal with it actually really so you both actually so how so what do you last pass and how do you use it that was super complicated but a lot faster than I remember black book what was that write down my password for the black book that I keep somewhere yeah so that's not a crazy idea I would advise not to put it as a post it on the computer itself but yeah having back up hard copy back up is not crazy yeah master password for oh can you explain master password is an app line and you have one really long password in combination with I guess it can be anything but they tell you to put your name in and then automatic to generate some passwords based on any folks that you've been nice okay so kind of algorithmic based so it's not just a completely random password that you have to store but based on so almost like a hash in some sense so based on your password and your name if that will spit out a unique password that you use on that site then you use that app instead of remembering the unique password for site yeah passwords for sites I don't really care about I'll typically reuse password which is bad practice but I don't really care about what passwords or what systems people do on those sites anyway I mean I did that for a long time like I had my basic password that I used on really crap sites and then a slightly more sophisticated version and then like my email and banking sites but now they're all random with password managers but what else any other strategies yeah oh nice okay that's a good I haven't thought about that actually using the password by logging out like once you log into a website and create a password with it log out log back in log out log back in so that you develop more of a muscle memory for the password formal practice but like Google Chrome remember it for you so you can let your browser it's very tricky because those are not usually not encrypted so you can I think encrypt them but even then it's not I think the usability can be an issue there like then you have the problem of depending on what the password is right logging in on your laptop versus your tablet or mobile device I mean all those things can be tricky like syncing between devices cool so yeah I have a base password that I use and I change certain things throughout it for different websites cool so this is kind of like a master password idea but with your own custom algorithm that you use anything else? anything else crazy? do you ever find that your algorithm can't get past the requirements of the site like we talked about? sometimes they don't allow certain characters that are in like the base part of it so I have to change those certain characters which it's always bad when you have to take out characters that the website doesn't allow yeah that's my the huge thing with a lot of those things cool so do you feel that this is a good thing like is this state of authentication to computers, websites, all those things is it a good thing? yeah? yes yes why? because what you know is the most secure what you know is the most secure as I say did you know something else that's not a password? do you have a feeling of that? I'm going to say like no it's not ideal because I don't know I think in like a dream world right like some system right where like you don't even need to like log in or something like you're just known and then you just log in yeah that's who you are right your identity right rather than having to continually prove yourself you would know who you are I like things like base ID or fingerprint authentication more than password just because easier to use and obviously like in a perfect world it would be more secure right so yeah so then you have this problem of man like having base ID or whatever or a biometric type thing that you actually is very little effort on your part to use right that clearly has a lot of the good drawbacks on the flip side does anyone ever unlock somebody's phone by just pointing their phone at their face I did that last week it works really well or I this happened at my lab at UC Santa Barbara somebody unlocked somebody else's phone while they were sleeping they put their phone and put their phone and put it on the phone while they were sleeping so you have problems there but man as far as usability it's pretty usable so yeah I think there's a quote I think it's Churchill I believe is friendly with the quote about democracy and it applies equally well on passwords or passwords are in my opinion the worst form authentication except for all those other forms that have been tried from time to time so yeah that's it's a like we talked about it's such a pain right and you think about to use this securely you should have a unique password that is difficult to guess for who everyone for everyone not just people but computers too right they analyze password databases to figure out what are the most common passwords so you can think that you're being insanely clever because you have this password based on some keyboard combination that looks incredibly random but is trivial for a computer and a computer will likely guess it assuming you can guess the passwords fast enough yeah what about we didn't actually talk about this but what about snooping so anybody talk to somebody typing in passwords and guess their passwords what are other ways that people can snoop on your passwords yeah I mean I know that you mostly base your passwords off of like Winston Churchill quotes I can go like alright I'm just gonna get a list of common Winston Churchill quotes and try that I gotta change the passwords keyloggers right so what's a keylogger a delicious software in your computer yeah malware that gets installed on your computer that is listening to all your key presses so you can see all the key presses you're making to the websites, to your passwords you can see the reflection of the screen from your eyes yeah so there's actually been a lot of research papers demonstrating that with your laptop you can the acoustic sound of the keys you press each key is different so you can build up models and try to guess passwords based on what keys they're pressing so you can do the easiest one of all shoulder surfing where you look over somebody's shoulder and you watch them type their password also very easy to do extending on that there have been all kinds of things where I can film you logging into your laptop and I can use the reflection of your eye on the screen on your keyboard it gets even worse so thinking about your cell phone so you know that all of these have super awesome gyroscopes in here that's how you exactly like the location and orientation of the phone it turns out most apps and now even websites can get access to the gyroscope data so what happens when you're typing in your password onto your phone like this you're slightly tilting and slightly moving it so most of these gyroscopes can detect so there's another work that's been able to determine passcodes based on gyroscope information yeah I've noticed this for those passwords where you make a pattern or whatever you can see where they just let their finger on the screen so that's called a smudge attack where you look at like the smudges on the screen and you're able to redo their patterns yeah exactly yeah so this was this is why if you've been to like a secure facility rather than having a numerical pad that's you know one, two, three, four, five, six, seven, eight, nine because what will happen is people will put in the passwords in the everyone will do the same password and the keys will not have even where so you can figure out the passwords there what they do is they have a digital screen that randomizes the numbers every time so that the exact presses are different every single time they've even been going back to the cell phones they've done research that shows you can actually if the cell phone is on the desk where your computer is they can get what keystrokes you're typing into your laptop from your mobile phone crazy how the emanations that you make when you're typing is enough to perturb the gyroscope and so you can train and learn on that and each key press will be kind of different because of the way your finger presses it and where it is and so it will generate different things so you can steal keystrokes that way it's crazy yeah the more we talk about it the more I think we should burn everything down easy to lose easy to lose forget passwords and then it's gone right it's something that you knew and now it's something that you don't know even though you've forgotten that piece of information right and so there you have that authentication problem no control on sharing, does anybody share passwords here anyone use a shared password there we go which makes sense right there are certain times you want to share access to a resource with other people and maybe you don't want to reveal that password because use it on all of your other websites but it's difficult to restrict it I can't say I want to share with you but you can't share with anyone else and then all of a sudden you can't watch Netflix because there's 5 devices using it at once and you've lost control what's social engineering yeah, second the human element behind some of this so kind of similar to looking over someone's shoulder basically getting to know that person and using that information that you can find out about them to guess like the passwords that they might have come up with yeah I feel like convincing someone to give you information that should be giving you right, so that would be like if I'm at my desk in my office and somebody calls me and they say hey this is ASU's IT department we're really worried that they've been a breach of your account some user records may have been accessed to verify that you are actually an investor at a new pay and you own this account could you please recite your ASU password to me so that I can verify who you are before I tell you the extent of these problems right, it would be very easy for me to give that password over the phone not realizing that no ASU employee will ever ask for your password as a means of authenticating you so this happens all the time at a lot of different ends so you can even, there's been lots of cases of social engineering to bypass authentication mechanisms there's, I think we've talked about this where they've been if you look for social engineering DEF CON videos you'll see cases where people will where a journalist will give them permission to call their phone company and to change the phone like address and password over to them and they pretend to be you know super busy or they give them some sob story and convince the customer support representative to password even though they didn't actually authenticate to the system yes, that was the baby crying in the background they'll use a recording of babies crying in the background to be like oh my god my kid's so sick we really need to pay this bill and it's such a huge problem we can't do the website please let us in anyways it's super everyone thinks that they won't fall victim to these type of things but they are usually wrong yeah so so password reuse and so so many problems and it really requires each person to be vigilant right and we're putting a lot of kind of burden and complexity on individual users to be able to use these systems correctly so it's kind of a crazy thing that we actually do work basically so this is a recap of what we already talked about dictionary attack so we can just guess from the dictionary or from lists of commonly used passwords what what we think the user's password is so the way the way to think about this is you don't think about like a dictionary you don't start with like art of art to guess that first then whatever the next word but you don't start with the a's and just work your way down the dictionary what do you start with password password the most commonly used passwords yeah so you there are studies you can look at there's all kinds of crazy stuff so you can look you would guess not by necessarily the dictionary order but you look for words in the dictionary that are and you look in the order most likely to be a password okay there are offline tools to help do password cracking there's a program called crack there's a program called John the Ripper that you give them hashes and they will try to use all the cpu resources you can give them to crack those passwords you can even just if you get sometimes an md5 you can just google for that md5 and you may find the word that corresponds to the hash of that md5 so we talked about online attacks where you're trying to log into a website to try to guess a password so let's say that here I guess we're getting here cool so how do we try to defend against password guessing we've talked about some of these things so let's kind of sum up yeah so if you were like you failed three times you'd get like just no confirmation right so I can add some delay and some pushback in the let's call it the online method offline we can make the hash function take longer by hashing multiple times make the hash function slow so that both offline and online are slower two-factor two-factor so you force the users to use two-factor authentication so specifically don't just rely on the password have them give you something else that they know or sorry something that they have right or maybe a biometric in addition to that so one you could just try to this is the the optimistic way is just don't give them access to your database of password hashes and so force all guesses to be online but as we talked about this is very hard to guarantee right there can be there are many different ways that your password hashes can leak out so like we just talked about add delay to L and increase time to compute a website has done we have a website so you say add delay to L when incorrect so what is that how do you actually do that like offline or online let's say online in that case you could you can keep track of like how many times someone has tried to log into this easier account in the past like in the most recent like it or something and if it's like over a certain threshold then the next time they can log in is pushed back until some future did how are you going to try to break and brute force passwords in that way multiple you're going to switch accounts switch accounts right so you can also deny access to someone's account that way too and it possibly is a denial of service attack against them right so if we have a thing that says if you have tried if somebody has incorrectly logged into this account let's say five times in the last whatever five seconds then what we'll do is try four times on that account switch to another account try four times on that account switch to another account try four times on that account going basically under the system other ways to do it if you try to use IP address base of walking where you can only guess a certain number of times on a certain IP address I'll get rent a botnet get access to thousands of IP addresses and have each of them guess one user account every half hour or something right now I'm doing guessing at a very slow level but across a wide swath of user accounts yeah I have that stuff for like some website even once you do log in like if this is your first time logging in from like a certain location you can't actually get access to a verified reading yes so that's and so the other thing to think about and that's basically all of these things two factor authentication this type of thing is basically because many because passwords are so terrible and because it's easy for websites and sorry not websites but malware to steal your password they may do other types of defenses where they say Gmail does this if you log in from a foreign country it'll say hey this is a little weird like verify on your like we're gonna say an email about it and maybe verify on another app that you're actually logging in from this other country and it's not somebody else okay cool so rainbow tables as we've talked about already basically pre-computing some of the hashes so when you're trying to attack a hash function very cool they trade off they're super interesting because they trade off time to crack versus space and the way to think about this is they require a lot of space so for five all one to eight alphanumeric characters the table is 127 gigabytes going up to just one additional character requires 690 gigabytes of storage to store that rainbow table but you can easily look up from a hash to see if it's inside that rainbow table so you can take an mv5 hash look up basically instantly whether it's nine character alphanumeric password you can actually go and download torrents of rainbow tables for various hashing functions of various sizes and then you can plug those into tools like john the ripper to break passwords okay cool we talked about salts we're almost here we might as well just we actually talked about all this we talked about flow hashing decrypt scrypt I think I guess I have my role reversed decrypt was designed to get slow ads it's actually used on the submission server and computing a hash takes 300 milliseconds on the server so if any of you was able to exploit the submission website to dump the database it would be very unlikely for you to break people's password because it's a pretty slow hashing function that takes 300 milliseconds to compute scrypt is the improved version of decrypt that's designed to take more memory cool okay we'll come back and we'll talk about an incident of password reuse