So I'll do it now in my virtual machine. I think most of you still should have your virtual machines that you created for your first homework and you use VirtualBox. VBoxManage is spelt wrong. VBoxManage on the command line is just the command line version of VirtualBox, the graphical interface. I need to use it. I'm going to start my node. Remember in the virtual network we create nodes, node 1, node 2, node 3. I already have a node 1 in my case. Start VM. And I don't want a graphical interface. When you use VirtualBox it opens up a window to log into the node. I don't want that. I'm going to create a headless version of that node. Start node 1 and now it's booting. So my node 1, my virtual machine is booting now. It's in the background though. So there's no graphical interface at the moment. It takes a minute or so to boot, to boot up. And then we can log into it using secure shell once it's booted and it will be booted soon. But we need to give some options like log in as the network user. By default there's a network user. You don't need to do this just one example. And the secure shell server that VirtualBox uses is port 2201. It's been set up for this node. And we log into localhost or <IP_ADDRESS>. And once it's booted, what have I done wrong? Lowercase p for port. And now I log in with my password. And I'm now running or logged into node 1. So now I just want to demonstrate on this virtual node something about how we store passwords in Linux and most Unix operating systems, similar concepts in most Unix operating systems. So I'm the network user on node 1. So we store passwords in some database. In Linux or Unix, the database is simply a file, a text file. And in fact, the user information is stored in two different files. What we call a file that lists the user names and another file that stores the passwords. Not the actual passwords, but the hash of the salt and password combined. Let's have a look at them. On my node, I've created a set of users. So here's some of the users or the users on my example node. Okay, so we'll see their passwords. There are two main files. One is, and both files are in the directory called etc. The first file is called passwd short for password. That's the name of the file. It's a text file. There's more some information about the user. So if we have a look at that file, using less, each line has some structure where this is the user, the user name, then separated by colon, some entries related to that user. So there is a set of users in here. And in fact, most of these users will ignore because they're system users. They're not something that a human user needs to... They are not accounts for human users. They are for servers, special accounts for my operating system. The root user is the admin user. But if we scroll down towards the bottom, the ones we're interested in, these are the, in this case, there are six from network down, the six human users on my system. So I've set out my computer such that there are six different users that can log into that computer. So there's the user name. And the way that the passwords are stored, this value, x, means that the password is not here. The password's in another file. We'll show that in a moment. So this x value means... Normally, the password would be stored here. But in fact, the way the system is set up is that the password is in a different file. The rest of the values are some user ID. So this is my user name, Steve. This is my user number, 1001, a unique number for the user. And we'll see in the next topic we often have user groups. So not just a user, but a group. So the next number here identifies the group I'm in. Some information about the user, there's nothing set up here. Maybe my full name, my telephone number, my office number and so on, maybe here. My home directory and the shell, the software I use for the command line. It's called bash in this case. Not too concerned about the details here, but we have a set of user names here. What we want to look at is where are the passwords stored? They're not actually in this file, they're in another file. So let's look at that other file. And it's called shadow. Permission denied. I'm currently logged in as a network user. I can see the set of users that have accounts on my system in the password file. But the shadow file is the one that stores the information about the actual passwords. I cannot access it. So that's the basic control that you should not allow any user to be able to view the password information. You should provide some access control. So I don't have permission to access that. And if you log in as one of the other normal users, they would not have permission. So when we set up, say, you build a website, as opposed to your operating system, you build a website and maybe you have a database that has all the user names and passwords in there. You don't allow any user to access that database. You have some form of access control so that only the relevant users, the admin users of your website can actually read the database. That's the same concept here. I cannot, as a normal user, access this password's database. So I need to be an admin user. And I've set up this system such that I can switch or elevate my permissions from the normal network user to the super user, or the admin or root user in this case. And we use that, the command sudo in Linux. So if I have admin privileges, I can view this file. And I've set it up so that the network user does have admin privileges. So we get those privileges by using sudo. It asks for my password to check. And now I can see the file. And we'll scroll down to just to those users that we're interested in. We'll zoom out a bit in a moment to make it clearer. But let's focus on, let's say, my user Steve. It's all one long line. So it's just broken across two on the screen here. So there's one line per user. Let's focus on one. There's the username. The same as in the past WD file. Steve, that's my username. Then from here, this colon up until here is information about the password. The hash of the salted password is stored here. We'll come back and look at that in a moment. Just before we go into that, the rest of the values are something about the age of the password. You can set up the system such that someone has to change their password every month. And that they get a warning when that change is coming up. So something about the password age can be stored here. And that's what these values are about. When the password or the account was created, some times or dates, and something about the age of the password so that you could set it up so that when someone logs in, they must change their password. We're not too concerned with those values here. I want to focus on this part. The storage of the password, which is all of this. If we look closer, it's hard to see, but it's broken into three parts separated by dollar signs. Three fields, then. The first field is six. So to store a password, we use the recommended practice of taking the password, generating a random salt, combining them, concatenate, and hash the value. And the hash value is stored. So, in fact, we must store the hash value and the salt value. But we also need to store the or know which hash algorithm was used because we can choose from multiple hash algorithms. The first number, six, here, identifies the hash algorithm. Six is, and I'll show you later where it's specified, but six refers to char 512. 512. So six means use the char 512 algorithm to hash the salt and the password. The next value is the salt. The random value that was generated by the operating system when I created the account. So when I created the account for Steve, sorry, I've chosen for network. Doesn't matter. When I created the account for Steve, the operating system chose a random value. And because it stores it in a text file, it represents that random value as a set of characters from a printable character set. So you can see it's not hexadecimal, it's just a set of characters from including upper case and lower case letters, numbers, and a few other characters. I'll show you the list later. So this is the salt here, a random value. And then the next long field, the last part, goes all the way up until here. That's the hash value. So if you take my password and you combine it with this salt and you use algorithm six, which is char 512 as the hash function, you hash this password and salt combined, you get this long value, which is the salt. And then you see for the other users, it's the same structure, 6, salt, the hash value. So this is the password database, and this is the answer to part D in question one of your quiz was you store the username, you store the salt, and you store a hash of the salt combined with the password. That's this value here. The way you store it depends upon the implementation. You could store the binary value. It's just stored here in some printable character set so we can view the value. Now, this password file, this file is protected so that normal users cannot read it. So if a user logs into this system, Santi logs into this system, he has an account on here, he logs in, he with the normal permissions cannot see this data. Of course, he knows his own password, but he cannot see the hashes of other users' passwords because this file is protected. That's the idea is you want to protect the database that stores the password information. But what if he could, there's some problem in the setup in the system such that he could see this data, or someone shows him all of this data. So what if a user could see all of this and therefore can they find the password of the other users? That's what they want to do as a malicious user or an attacker. So another user, can they see the password of other users? Well, no, they cannot directly see the password. They can see the hash of the salted password. And the challenge then is, given that hash value, can you work backwards to find the original password? And the analysis that we looked at last lecture shows that if we use an assault and a password which is difficult to guess, a brute-force attack of trying all possible passwords will not work. It will take too long. So even if you can read this file, it's practically impossible to work out what the other users' passwords are. So that's the benefit of storing the hash of the salted password. Let's just check some of that detailed information. There's a man page or a help page that explains some of that file and the structure. And one of them is the crypt. It's the old function for cryptographic operations for the password. And it defines many things, and I'll focus on some parts. So the salt stored in that password file was made up of a set of characters A to Z, lowercase A to Z, uppercase 0 to 9, and these two characters are dot and a slash. So there are 64 possible characters that can be stored in the salt. With 64 possible characters from that character set, let's calculate. So we have 64 possible characters. Sorry, I've missed. That was the, what did we have? A to Z, uppercase and lowercase, 0 to 9, and a dot and a slash. So 52, 62, 64 possible characters is the way to store that value. How many possible values are there? It depends upon the length. If we have just one character, how many possible values? Well, 64 possible values with one character. If we have a two-character salt, there's 64 times 64. The other way we can think of it in binary, how many bits do we need to represent 64 different values? How many bits? I want to represent those characters in binary, zeros and ones. I'd need six bits because 2 to the power of 6 is 64. So one character, a lowercase a, from this character set, we could represent in six bits because we need to be able to represent 64 different possible values. We need a minimum six bits to represent them. So we can think that each character corresponds to six bits. Now coming back to our salt, the salt is made up from those 64 possible characters. And if we scroll down, it turns out that the hash value is also made up of those 64 characters. This just lists the algorithms used. The idea is the algorithm number. We saw algorithm number six, char 512, which is using the algorithm char and it produces a 512-bit hash value. So it takes any size input, produces a hash value of 512 bits. And the format of storing, as we saw, there's the number six, the salt and the hash value. It says encrypted here, but it's the hash value. How long is our salt? Let's look again. Actually, let's scroll down. How long is the salt? How many characters? One, two, three, four, five, six, seven, eight characters. So the salt is eight characters. So eight characters, each can be one of 64 values, or the other way we can think, each can be represented by six bits. With 64 possible values, we could use six bits to represent those values. So each character corresponds to six bits, eight by six. So it's 48 bits long, effectively. So it's a 48-bit random number. So that's the salt. So what the operating system does when a user creates the account is chooses a 48-bit random number and stores it in this file there, but doesn't store the binary form, it stores it in this special character set, just so it's easier to read. So the salt in our example, the algorithm we use, the hash algorithm are 512. The salt is eight characters, or 48 bits. And the hash value, this is the hash algorithm, the hash value, so what we do is we take the password chosen by the user, the user, when they create the account, they choose a password. We add at the end the salt value and we calculate, using SHA 512, the hash of that. And let's say that the output of that is, let's say the lowercase h, the hash value. So when the user creates the account, they choose a password, the operating system chooses a 48-bit salt, the operating system or the software combines them together, divides the algorithm SHA 512 and produces an output, the hash value. And the hash value is what's stored in that file. And it uses the same format of 64 characters, this character set of A to Z, 0, 9 dot slash. I'll come back to this. How long, how many characters here? Well, you can count them, but the man page tells you that there's 86 characters here. You can count them. Always 86 characters. 86 characters, each character corresponds to six bits, gives us 516 bits. 86 by 6, 516. Well, in fact, the hash value with SHA 512 is 512 bits. So there's four bits which are wasted there or not used. So the length of the output, H stored is 86 characters, which corresponds to our 512 bits. It's actually 516, but four of them are not needed because SHA 512 produces a 512-bit output. So it's just an example of the storage of passwords on an operating system coming back to the different users. So when a user changes their password, this file will be updated. The hash value will be recalculated. Let's try a few. There's a utility that allows us to test to create this output. I'll show you. It's called mkpasswd, make a password, and we can specify the algorithm that we want to use. I want to use SHA 512. We can specify the salt, and we need an eight-character salt. Let's start with one, the simple one, and then choose a password. I'll just type it here. For example, password network. And it produces this output that would be stored in the password file. I want to use SHA 512 with this salt and this password network. Then what the value which would be stored in the file is SHA 512 number six. Here's the actual salt. And then if you combine the salt and password together, and then hash them, you get this value. So that does that for us. Now, we'll do that again. Let's look at just the last five lines of this. So we had... It's hard to see, but we have one, two, three, four, five users on this system. I've created five users. Let's set the password, or calculate the password for a particular user. Spell this right. Using the same method. Let's use the salt here just to check. In fact, when I created this Tanawit's password, what did I use? I have to remember because I created it for him. I think I used the word password. We'll find out. Yeah. So if we take the word password, that's the user's password, this salt, combine them together and calculate the hash with SHA 512. We get this output. And in fact, it's the same value as it's stored in the system. If I used a different password, actually, password one, the user changed their password from password to password one, same salt. It's hard to see, but I think if you compare the output here, this hash value with this hash value, you'll see that completely different. Two different passwords, even though the same salt, the property of our hash function will get two different outputs. What if two users have the same password? It's common that some users may choose the same password. What happens? Well, they'll get different hash values so long as there are different salt values. In fact, the way that I set it up, all users the same password of network, except for one. So Steve's password, in fact, was network. His salt was this and we get this hash value. Tanaruck's password was also network. It's a different salt. Even though the password's the same, we combine it with a different salt so we get a different hash value as output. So that's one small benefit of using the salt. If we have a large database of many users, it's likely that some will use the same password. So let's say on the admin, Steve, and I can see this file, even though I can see this file, I cannot directly see other users' passwords, even if they have the same password as I do, because they have a different salt value, because the salt is chosen randomly, then the hash value between two users which have the same password will be different. If we didn't use a salt, two users with the same password will get the same hash value. And that would be shown in the file. And then someone who has a particular password, they see their hash value and they see someone who has the same hash value, then they know the other person's password. It's the same as theirs. They're a small benefit of using salt. So that's just an example of the storage of passwords in Linux. And other operating systems and other systems use similar concepts. They may use different algorithms, different lengths, have different requirements on password ages and store them in different formats, but the same concepts. And when you implement your systems, you should use that same concept, especially websites. Any questions on that before we return to our lecture notes? Let's look in detail of this file. So there are many users on the system. There's the normal users that I've created, Steve, Tanarak and so on. Then there's some users which are created by the operating system for special purposes, not really relevant. And there's always a root or an admin user in the Unix. It's called the root user. They're just another user from a password perspective. So the root user, there's their salt value and the hash of the root user's password. So in this case the root user has a password, whatever it was set to be when I set up the system and there's the hash of their password and salt value there. So some accounts may not have passwords because you do not log in with them, special accounts. But in this case the root user has a password. So of course you should not show other people this file. Even though it's a hashed salted password you want to reduce the chance that someone can look at this value and work backwards and find the password. So in this case yes, the root user has a password. Of course if we didn't hash the password and just store the password everyone would see all the passwords here quite easily. Which would be very bad. You'll have an opportunity to, you can look on your own virtual machine and show you later how to add accounts, add new users and set passwords and you can see how that works.