 Okay. Can you trust Google with your password? Can you trust anyone with your password? Should you use different passwords on different services? Is there any secure way for a service to store your password? We're going to talk about all those questions in this video. It's actually sort of going to be basic cryptography, but a lot of people don't know this stuff, so it's worth talking about. So, I'll go ahead and answer those questions first. As for if you can trust Google or any other service, the correct answer is I don't know. We cannot be sure because we don't always know what any of these services are running on their actual servers. And I'll talk about why that's important in a bit. But just know you should always be maximally cautious. You should always use different passwords for different things. But is there a secure way to actually store passwords? Yes. Or at least you can actually test passwords, usernames and passwords without actually even having the password stored. We're going to talk about how you can do that in this video. In a good service, hopefully every single service out there, Google, Facebook, all of them, store usernames and passwords in this way. Or technically, again, they're not storing them. Let's talk about it. Firstly, what is the dumbest possible way to store user logins? The stupidest possible way? Very simple. You have a text file, you have a database, you keep usernames and you keep passwords in there. And when someone tries to log in, you check their username and password. If it works, then you let them log in. That is the stupidest possible way because two obvious reasons. Firstly, any hacker that gets access to your server instantly has all the usernames and passwords. Because they're not encrypted in any way. They're not stored in any other. They're not hashed. We'll talk about that in a second. They're not stored in any way. They can just see them and use them. Worst case scenario. Additionally, even if your server is totally secure and you're not hacked, your users have a big liability. And that is you can see their password. That's basically just as bad for them. They have to trust you. They have to trust that you're not going to take their username and password and try and log on to another service. That's why you should always assume you can't trust these different services. So you should always be using different passwords. So that is the dumbest way you could store passwords, just in plain text. A marginally better but still terrible way of storing passwords is encrypting them. You might think that encryption will save everything. Oh, encrypted. That means it's safe. No, no, no, no, no. Not in the context of passwords. It is marginally better but still basically just as bad. Why is that? Now, when I say encryption, I mean encrypting them with maybe a GPG key pair or something like that. And specifically, if you encrypt something, let's say you have a password. Let's say the password is the word password. If you encrypt that, that just means you perform some kind of encryption algorithm on it that maybe has a key to unlock it and you generate some new sequence of text. And that new sequence of text can be decrypted if you have that key. So you can go two ways. You can encrypt something, you can decrypt something. Now, that is marginally better than plain text because the hacker has to do one other thing. They have to obtain the encryption keys that unlock all of these passwords. But in real life, that's probably something very easy to do in a lot of cases because if they're already hacking your server, and your server, of course, has to encrypt and decrypt these passwords anyway, you're probably gonna have that encryption key somewhere available on the server. And even if you have some harebrained scheme of storing that, it is still a one point of failure. So someone could still decrypt all the passwords and it's only marginally better than having plain text. If someone had root access to your server, you're just as screwed, basically, okay? And the same problem persists for users trusting you. Obviously, you're gonna have the decryption keys. So that's still the same problem for them. So what is the real way to store passwords? The real secure way to store passwords is by not storing them. Here's what you do instead. Instead of using an encryption algorithm, people use what's called a hashing algorithm. Now, a hashing algorithm, I said, now, encryption, you encrypt something, you can decrypt something with a key. Hashing does not work like that. Hashing is you take that password, you take that text, and a hashing algorithm will produce what's called a hash. And that is, it looks like a bunch of random text. It's in the same way that encryption might look like a bunch of random text. But a hashing algorithm cannot be reversed, okay? Now, just as an example, let's say an encryption algorithm could be something, if you're very stupid and you don't have an encryption key, an encryption key, or encryption could be as easy as you taking every letter and replacing it with the letter after it, okay? That would be a very stupid, very simple encryption algorithm, okay? You could also very simply decrypt that. You could take every letter and find, and of course, undo that and find the letter before it. Very easy to do. But a hashing algorithm is not like that. A hashing algorithm is performing something on the text that is irreversible. Maybe you're following advanced rules that are, maybe sometimes you replace it with things after it. Sometimes you inject, if you don't have enough, inject new characters if you don't have other characters. But really, I mean, hashing algorithms and encryption algorithms are much more complicated than this. I just want to get the idea through your head that hashing algorithms are one way and one way only. You cannot look at a hash and figure out what generated it, okay? So this is much, much, much more secure than encryption. Now, it's not 100% secure. I'll explain why. But it's really, really good, okay? It's good in the sense that if someone sees a hash, they don't know anything about your password. They can't decrypt it. You can't do anything. Now, you might ask, oh, well, how is this the same as, you know, how does that work if they don't have your password and you log on with your password? How are they going to know that that's it? Well, what they do is, when you first give them your password, they don't store it. Instead, they make, they store the hash of it. And when you log in with your password, they, again, are not comparing your password to the password they have stored. They're comparing, they make a hash of that password you're giving and see if it matches the hash of the password you already have, okay? That's, in just in case it isn't clear, that's how it works, okay? Now, you might ask, oh, well, what if the hash is, there is a problem of something called collision. That is, if you have a very simple hashing algorithm, a very stupid and simple hashing algorithm, you might by random chance have a hash that is shared in common by two, like two different passwords could generate one particular hash. That is not something you have to worry about in real life because the hashing algorithms we actually use are like way more complicated than that. It might actually be impossible. I don't know. You'll have to ask a professional about it, but it's just, let's just say it's so astronomically unlikely it's not an issue, okay? All right. So anyway, hashing. Much better way of preventing hacking. And of course, if you're a server administrator, you don't actually know your user's passwords. But there is still a way to get through it. If you're a good hacker, you can figure out how to still figure out people's passwords. How do you do that? Well, you do it basically by brute force or having a word list. What you do is you, let's say you take all the words in the dictionary, okay? And you make a hash. You find the hash of every single one of those words. Then what you can do, if you've hacked on a server, you can look and see if any of those hashes match any of the hashes that people have stored as passwords. And in which cases, ah, I can figure out that this is their password because it matches this hash. This is why it's important to not just use dictionary words or easily guessable words just out of nowhere. It's a bad idea to do that because you fall prey to these kind of dictionary attacks. Okay? And of course, you know, you want to be clever with your path. You want to change things around, random things about them, replace letters, totally merge words in weird ways, add in weird characters. You want to just make things that would make it difficult for someone brute forcing them to figure out. Okay? Now still, like how this works in real life too, when you try and log into a server, I mean this is just sort of details, but when you try and log into a server, normally there will be some kind of, let's say, time lag. If you're trying to log into a Unix system or something like that, there's a little time lag. If you get a password wrong, that's often very common when you try and log into something or you might have only five tries or something to get into something with a password. So you can't brute force the system itself, but if you have the hashes, you could just use simple commands like diff or something to find, or grep or something like that to find matching hashes. Anyway, so that is not the perfect way. There is no perfect way, but that is not the most closest to perfect way to store passwords or to not to store passwords, but to check passwords. You can go one bit further, and that is in addition to hashing a password, you can also salt and hash it. Now, what does that mean? Now, what that means is when someone, let's say again, you're someone managing a web service and people log in with a username and password, you have, when someone logs in or starts an account with a username and password, you generate a what's called salt. And what salt is just like a random byte or so of data, maybe a random number in anything random. You generate a random byte of data and what you do is instead of hashing that password, what you do is you combine that random byte of data with the password and you get a hash of those things together. You get one hash of both of them together. Then what you do is you store the username, that hashed and salted password and you also store the salt that generates it. Now, how is that any different? That's different because it makes it much more difficult to do these kind of brute force attacks or wordless attacks, dictionary attacks. Because you basically have to know, let's say the salt that's been generated for your account, the number 12 or something like that, that's the salt. Let's say your password is password and your salt is 12 and so you have a hash of those two things together. Now, let's say that someone is brute forcing the word password. They will not find a hash that matches because they have to specifically be, you know, they have to specifically look for the hash of 12 and password together. Additionally, if you are giving users each, you know, if salt is truly random and it's different for every single user, then if someone wanted to attack, like let's say that I decided I want to hack Billy's account and I know that Billy's salt is 12, okay? I can do a massive, very intensive check of every possible word in the dictionary and alternations of these words and all this kind of stuff and I have a massive word list and maybe if I get lucky, I will hack Billy's account. But even in that case, even if you do, which is very unlikely if Billy chose a good password that isn't just something simple, even in that case, you have not been able to hack anyone else's, okay? Because everyone else has different salt. Billy has salt of 12, everyone else might have had some different salt. So you've actually gotten nowhere in terms of hacking everyone else, all right? So that is what, that's basically why people salt and hash passwords to store them. Now, as to the original question, can you trust Google or can you trust any other service with your password? The answer again is you can't really be sure. You don't actually know how Google is, what Google is doing with your passwords. Maybe they're hashing and salting them, you would hope, they're pros, they're supposed to do that, but theoretically, Google could be doing something malicious with your password, they could be storing it in some other way or monitoring it in some other way. So it's always safest, okay? I mean, provided that, provided that like, you know, it's not like front-end stuff happening on your computer that's hashing and salting the password, I mean, it's theoretically possible to do it totally safe, but in general, I wouldn't, if you're a normal person, do not necessarily trust any service because although there are highly secure ways of storing passwords or hashing and salting them, don't necessarily believe that anyone is gonna use them. Always be suspicious, it's best to use different passwords for stuff, but yeah, it is possible, it is possible to have a highly secure password setup if you hash and salt all your user accounts and passwords. All right, so that's about it.