Introduction to authentication

Summary

In this video, I show why rolling your own authentication isn't as difficult as many claim. While security is complex, the core principles can be learned, which is important since you'll likely need to customize third-party solutions anyway. I explain that authentication is proving who you are (identity + proof), distinguishing it from authorization (permissions). I emphasize never storing plain text passwords, demonstrating how to secure passwords through hashing, salting, and adding a pepper. Finally, I address HTTP's stateless nature by using cookies to maintain authentication across sessions, setting the stage for implementing these concepts in our codebase.

Transcript

Welcome to this short introduction to authentication, where we'll be discussing what it is and why it's not really that hard to roll it on your own. And the reason why I want to talk about why it's not that hard to roll it on your own is that you might've heard this being repeated over and over on something like Reddit, Twitter, X, where they say you have to use a service. This is not something developers should do by themself. And the common argument you hear is that this requires deep security knowledge that most developers lack. It's deceptively complex. It has hidden vulnerabilities. Standards evolve all the time. It's basically a cat and mouse game where attackers will think of new ways to attack and then the defenders have to change their defenses and continuously repeat this process. And this is true. However, the core principles can be learned. And this is also one of my counter arguments that core principles behind a secure authentication system can be learned. And also, most of the time, you will need to do some customization, which means that these providers, something like Auth0 or AWS Incognito, work in a certain way where you might need to build on top of that. And if you don't really understand underlying principles, it's very easy to start just thinking you have a secure system, but you just introduce security holes yourself because you don't really know what's going on underneath. So by learning the core principles, you are much better equipped to also customize the system to your needs. The final one that is not really that important, but it's still a factor, is that these services add additional costs that can balloon if you actually create a successful app. And it's just something you have to take into consideration, right? It costs money. You also marry yourself to one provider's way of doing it. You probably wouldn't really change authentication provider once you are settled on one. So this is some of the counter arguments as to why you probably shouldn't be that scared to roll your own authentication. So what is authentication? Well, it is essentially just proving you are who you say you are. So you have some identity, typically an email, and then some proof, which is typically a password. And if those two match the records we have in our system, well, then you can have access to these hidden resources or this other part of our block or application. We also have this concept of authorization, which differs from authentication in that authorization literally is about, are you allowed to do this thing? Are you allowed to access or see this resource? We will not be refocusing too much on authorization because it doesn't really fit into what we need to start managing our block. But an example could be that you have your account as a super admin user, let's say, and then your block gets incredibly popular and you need another person to help manage that block. Authorization in that case would be, does this other person have access to, let's say, your subscribers? Like, can they view them? Can they update them? Can they delete them? What can they do with your blog post, for example? They might only need to be able to see your blog post and update your blog post, right? And that is essentially what authorization is. And now for our most important slide, which is password security. And if there's only one thing to take away from this video is never, ever, ever store plain text passwords. I have seen this in my job where I get access to a client database and they just store all of the user's passwords as plain text. It should be obviously right that it's a very bad idea because if someone with malicious intent gets access to the database, right, they can just start acting as all of these users. So the way to mitigate that is we start by hashing our password. This is probably the most important part. And you are applying a one-way mathematical function, which just means it's non-reversible. So you take a piece of text, hash it, and then you have this hash on the other end. And we can never go from the hash to the original text. We can only go from the original text to the hash. And that's technically enough. And it's definitely way better than just storing plain text passwords. However, we are still liable, or we will still be vulnerable to rainbow table attacks where if someone gets a hold of all of your database's passwords, they can generate a long list of hashes with already known passwords, and then just check against the hashes in your database versus the ones they have in what's called the rainbow table. The way we mitigate this is we add some random data to each password before we hash it. So doing that means that they cannot effectively use a rainbow attack against us because each password would not only have different hashes. Let's say you have like the same password for two users, right? It would have two different hashes simply because we have added this random element to the password before we hashed it. The final thing, and maybe not that important, but it's super easy to implement is we can add a pepper, which is very similar to salting, but it's something that we provide on a per application basis. And it's just another layer where we add another piece of text to the password before it gets hashed. And this is essentially how you do password security, how you get secure passwords that you can store in your database. And the way we would do that in Go is we would have this little function here. This is how we're gonna do it in the course, where we have a function called hash and pepper password that takes in the password. And then we apply our application pepper to it. Then we use a library called bcrypt, which is from the standard Go project, but it's maintained outside. So all of these elements we talked about in the beginning of evolving standard, well, it's taken care of by all of these maintainers, all of these developers that contribute to the package. And it's important to note here that bcrypt will do all of the salting for us. So they do the salt. And you can see that we pass the byte slice to this generate from password function. And then we provide it with a default cost. And this default cost is a variable that will literally specify how computational heavy it is to generate hashes and how hard it is to generate rainbow tables. We don't really need to worry too much about it. You can increase this cost if you need to, or if you want to, but just using the default cost is often enough as typically the bcrypt library will just use the best one, the current best one. That is a balance between processing power and efficiency so that you could technically turn this all the way to 11 and then have a super hard to crack password, but it would also require a lot of computational power to generate it. So the default cost provide us with a nice balance. Finally, we need to tackle the problem that HTTP is stateless. We would need to re-authenticate the user each time they try to access a page or a route where we have said, you need to be authenticated to access this. This is obviously not a good user experience. And the way we're gonna tackle this is with cookies. Cookies, they will store some information about who the user are, are they authenticated, and also how long is this cookie valid for or this session valid for. So when the user log in on the server, we create and securely sign a cookie that we then send back. And then the browser will store that cookie so that let's say for the next week or however long we set it to be valid for, the user will be able to access these protected resources because the cookie will be sent with each future request. So this is essentially what authentication is, how secure passwords work and how we're gonna tackle the stateless HTTP problem by using cookies so our users can stay locked in for a certain amount of time. And in the next videos, we will be starting to work on expanding the database with the tables we need and then starting to implement all the logic for authenticating users by creating a login form and all of these elements that is needed to have an authentication system.