00:00 Time to talk about passwords! Hooray! Alright, I got a couple things I want to talk with you about passwords. I go into more detail in the instructions, but let's talk about a couple high-level things. First off, don't store plain text passwords. Such a bad idea. If a bad actor gets a hold of your database, then sure, they have access to all your data. So what's the big whoop?

00:19 But the fact is they have access to all the plain text passwords of your users, some of whom may actually reuse those passwords on other services. And as much as you can say, well, they shouldn't do that, they're not going to be too happy about your response if this were to happen. They'd just be like, well, yeah, but you're awful because you lost my data.

00:38 So no, do not store plain text. Also, I don't recommend encrypting passwords because those encryption keys can get lost and you can't rotate them very easily. That would involve the whole database migration and stuff.

00:53 And on top of that, encrypting the password is susceptible to vulnerability. So even if the database were to be lost, despite the fact that it's encrypted, it is very possible to break that encryption and be able to decrypt all the passwords,

01:10 which would be really sad for your users and for you if you like not being hated by your users. And so what we're going to do is we hash the password. What that means is we take the password, whatever they give us, and we do a one-way transformation. And that's what a hash is, is it will transform it into another string

01:29 that will always transform to that same string every time. But you cannot go from that string back to the password. There's a lot involved with how all of that works. It's math and smart people figured out how to make that work. But it does. And it's great. And so we're going to be hashing.

01:46 But important things about hashing, because there are ways that attackers can figure out what the passwords are from hashes too. So there's rainbow table attacks and brute force attacks. So a user could just like hit your API a bunch of times. We already added rate limiting in a previous workshop. So they shouldn't be able to do that very effectively.

02:06 But then the other thing is if they do get access to your database, they can use what's called a rainbow table to figure out what the passwords would be. So that's not great. So making it slow can help against brute force attacks, but including assault,

02:22 which is just like a string of characters that is totally random for every single one of the passwords, make sure that if they are able to break the hash for one of the passwords, they're not able to break it for the rest of them. So it just makes it not very profitable. Again, like when you're talking about security and attackers,

02:40 lots of the time you're just trying to make yourself not the low hanging fruit. Let them attack the other people, which is, you know, run faster than your friend when it comes to running from a bear, I guess. That's terrible. All right, so we're going to be using a methodology called bcrypt or an algorithm called bcrypt

02:58 and a library called bcrypt.js for this. In this exercise, all we're doing is creating the hash. In a future exercise, we're going to actually compare hashes. But yeah, there's a synchronous version and async version. We're going to use both of those actually. And then finally, password storage.

03:14 So we need to update our database model because we don't have anything in there for a password yet. And you might think, oh, well, we'll just put a hash on the user table. But if you do that, then a developer who's querying the database

03:29 and trying to get the user information may accidentally do a select star and pull all the information. They pull the hash, which you really don't want. You don't want to send that to the client or anything like that. So what we do as a security measure is we separate those things, put the user table over here and the password table over here, have a one-to-one relationship between them.

03:48 And then everything is nice. People can query the user table. And I know they're not supposed to do a select star, but they might. They get all the data from the user table, but they're not going to get the password. And it's definitely worth it to make sure you do that. So I think that should be everything for you. You should be good to go for this exercise.

04:07 We're just doing the sign-up process, so we're not actually going to be comparing the passwords quite yet. So if you go to log in, we'll have this page that Kelly, the co-worker, put together for us. And so if we say hannah at example.com, then Hannah and Hannah,

04:23 and then Hannah rocks and Hannah rocks, and then agree and continue, and you should be able to log in. This is going to be reusing stuff that we've done with Conform and Zod and even the setting up the session and everything like that. You don't have to do that. Kelly did that for you.

04:39 You're just concerned with creating the password in this exercise. So good luck. Have a good time.