Hi folks, what I want to do now is I want to analyze the password protocol. Something we're all comfortable with, familiar with, use every day in the context of our schema. Our six step protocol schema that we went through, so let's start. So in Step 1, Alice reports that she's Alice, the identification step. In Step 2, Bob provides back a challenge basically saying, okay, you're Alice, what's your password? Or typing password colon, or something that makes it clear that you're looking for password. In Step 3, Alice then computes, remembers, looks up on a piece of paper, [LAUGH] whatever she's going to do. Finds her password, and confirms that it's the right thing. I'm logging in to this application, you look up in your little book, you wrote it down. I don't know whether writing it down is a great idea, it might be. Nowadays, it seems like you have to. Write it down, there's my password. And that's Step 3, just computing or looking things up. You're not doing something mathematical, you're finding, or remembering, or looking up password. In Step 4, [SOUND], I type it in, or I maybe say it. I'm providing the password back to the requesting server. It's asking me to validate, here's my password. Step 5, I look up the password. There's probably a file somewhere that has your name listed, or your user ID, and password. And a lot of times, you'll want that to be encrypted. Because if it's not encrypted, hackers can come in and read it. And you want to do something even more than just encrypting it. because when you store it encrypted, if hackers know the encryption algorithm. They can do these crazy things like run something called a dictionary attack, where in a stored list of passwords that are all encrypted. I can encrypt every element of the dictionary. This is assuming I steal your password file, and compare every word in the dictionary against each password. And if some user on a shared system has a password that's just a word in the dictionary, then it'll match. If I know the encryption algorithm, I have your password file, it is a shared system with a bunch of users, and I have a dictionary. There's a lot of ifs in there, but you get the point. And then, after in step five, I validate, or validate that it's not you, I notify you. That's the six steps in password. Now, let's think about Eve. How does Eve attack the system in zone one? Find your password, asks your password, guesses your password. Lot of easy ways to guess somebody's password. Pins are the easiest of all, because it tends to be a part of your mobile number, or your zip code if you're here in the United States. Like some number that's part of your address, phone, or something that you are. Some number that's been issued to you, is almost always your PIN. I'm sure out of the people who are watching, I probably could guess half of your PINs, if I just know a little bit about you. Maybe a business card would be sufficient for me to get a pretty good idea of what a PIN would be. That you'd be using for either a mobile device, or your garage door opener. So, you can guess, or steal, or do whatever she needs to do in zone 1. Zone 2, she can do something called sniffing. In a previous discussion, we've mentioned sniffing, that's basically collecting information on a network. You know collecting packets, or messages, or commands, because the Internet is natively not encrypted. So, if information's being passed across the public Internet, then Eve can read it, and your password might be passing by in unencrypted or plain text. In zone three, again you go and read the password file. Now hopefully, you won't be storing it unencrypted, and hopefully, in addition to just having words there. You might introduce something called salt, it's an interesting concept that's where you take randomized numbers. And you just append, or prepend, or inpend random numbers into the word just for storage. That way, if I do a dictionary attack on stored passwords, it's not going to match, because I put a little random nonsense in there. In fact, that word nonsense in cryptography is re-used, and we shorten it, and we call it nonce. So a lot of times, there's just some number that I need for some reason, we call that a nonce. And you'll see that when we get to Crypto, we'll be using nonces frequently to do interesting things. Bitcoin, the blockchain component of Bitcoin, which a blockchain is certainly separate from Bitcoin, but in blockchain we use nonces to do mining. We'll get to that as well. So, you think passwords are very secure? No. Eve has good opportunities in each zone. Why do we keep using passwords? Because people love them. They're interoperable, they're comfortable. They kind of cross all over our systems, they're fun to pick. We're used to it, [LAUGH] It's easy for developers, they are never going away, don't even think they are. You might work for a company, or you might have heard or you might have heard of professor somewhere, who tells you they are working and getting rid of passwords. You're never going to get rid of passwords, you can augment them, you can build much stronger forms of multi factoral authentication. No question about that, but there's always going to be a place for passwords. Because people like them, and I think system designers need to keep that in mind. So, with that, we will see you in the next video. Thanks.
