Need for Authentication
The current application allows unrestricted access to the admin page, enabling any user to create or delete articles. Authentication is introduced to restrict administrative actions to authorized users only.
Build vs. Third-Party Authentication
The video challenges the claim that developers should never build their own authentication. It argues that secure authentication is achievable by understanding core principles, and third-party services may introduce cost, lock-in, and limited flexibility.
Authentication vs. Authorization
Authentication verifies a user’s identity (e.g., email and password), while authorization determines what actions a user is allowed to perform. The focus of the implementation is authentication, as only one admin role is required.
Password Security Fundamentals
Passwords must never be stored in plain text. Instead, they should be hashed using a one-way function to prevent recovery of the original password if the database is compromised.
Hashing, Salting, and Peppering
Hashing converts passwords into irreversible values. Salting adds unique random data per user to prevent rainbow table attacks, while peppering adds a global secret stored separately (e.g., in an environment file) for additional security.
Argon2ID for Secure Hashing
The recommended hashing algorithm is Argon2ID, known for being computationally and memory intensive, making brute-force attacks costly. It automatically handles salting and uses constant-time comparisons to mitigate timing attacks.
Session Management with Cookies
After successful authentication, a cookie is created to persist the user’s login state for a defined duration. This avoids repeated logins and enables protected access to admin functionality using middleware.
Implementation Steps
The system requires adding a users table, generating and storing hashed passwords, verifying credentials during login, and issuing authentication cookies. Once complete, only authorized users can access the admin interface.
So we have gotten very far now. We can show articles on our page. We can create and update them. We have styled the page. We have gotten very far. But right now, if you go live with what we have, all users can technically access the admin page and create articles, delete articles. That is not what we want. So to deal with this, we're going to be adding authentication. You might have heard.
on Reddit or Twitter, or whatever, that you should never roll your own off. That is too complex. You should use a service like OZero or AWS Cognito. It's definitely not true. You can 100% roll your own off in a professional way, and in a scalable way, and in a way where you don't end up on the front page of Hacker News because your database got hacked.
We are gonna be, first of all, dealing with the counter argument to the it's too complex for a single developer to do. And also what is authentication? What is authorization? How do we do password security so that we store our password in a secure manner? And how do we authenticate our user? And what is the actual complex part of doing authentication?
So the counter argument to why you can do this yourself is that the core principles of secure authentication can be learned and that what is really tricky or difficult about authentication lies in the packages that we use, but these packages are already provided to us for free. Also, even if you use a third party services, you might need customization, but you'll also be holding to that platform. They might
then your account, they might do whatever you need, right? And also adds cost to your application that you don't really need. And also understanding authentication is really, really important. So you know what is happening in either case. You can always go with the third party service later on if you absolutely think that is what you need. But it's still important to understand the underlying principle of what is going on, what you're doing, and why you're doing what you're doing.
At the core of this is the principle that we want someone to prove they are who they say they are. We typically have an identity and that will often be an email. It could also be a username. Typically it's an email and then a password. You also have the social authentication where you do authentication through Twitter or for GitHub or Gmail or whatever.
We need to provide something that says, this is who I am. And then we need to be able to prove that we are that person. And that is often with our password. Then we also have authorization, which we are not really going to be taken into because that determines what a person can do. So can you delete our blog post? Can you see certain types of data? Can you create certain types of data?
or kill for our needs because we are only going to be one admin to manage our block. But that is the difference. So authentication, who are we, who we say we are, and authorization, can this person do X action? The most essential thing of authentication is password security. So this is the one thing you need to take away from this episode. If you take nothing else away, that is, do never, never, never, ever store.
passwords in plain text. This is what gets you in the news and this is what gets you on the front page of Hacker News. If your production database gets hacked or someone gets access to it, all of a sudden you have a big breach where you can see all the user's passwords. And they might be reusing those passwords against on other sites, right? So you typically just screwed your users over on multiple fronts.
So we need to store password in a proper manner. And the first step is that we are going to hash it using what is known as one-way mathematical function. So that means we can go from password to hash, but we can never go from hash back to password. Password is irreversible by design. We are still vulnerable to some type of attacks, some attacks called rainbow table attack, where
An attacker can pre-generate a bunch of hashes using known algorithms and then compare them against what we have in our database. And this is when people are using common passwords, so password, password 1, 4, 3, whatever. The way we can mitigate this is we can do salting. And that is basically we're going to add random data to each password before we has them.
This means that even if two users has the same password, they will have completely different hashes. This makes rainbow table attacks useless because the attacker no longer can generate table rainbow table and then check against the hashes. So free is adding a pepper, which is very similar to assault, but is an application rights thing that we add to a password instead of
the assault which is user-wise. There's only one user who has a unique assault, but then all of our users will also have this pepper value. And it's another thing we add to the string or to the password before we hash it. And it's something that we store separately in an ENV file that only we know about. So we are securing ourselves on free funds here.
I want to make it clear that we are using the recommendations of something called the Copenhagen book where we will use an algorithm called Argon2ID for password hashing. It was the winner of the 2013 password hashing competition. It's specifically designed for secure password storage. What makes this a really good choice is that it's very, very, very slow. So it takes a lot of resources to
to try and brute force a hash or try to guess and hash by trying a lot of different options or different combinations. It also takes a lot of memory. So you will need significant RAM to actually compute all of these hashes and check against what is in the database. It handles sorting automatically for us. It also uses what is known as a constant time comparison.
which protects against timing attacks where an attacker would try to learn information about password by measuring how long it takes to verify them. So I will provide a link for this in the episode notes so you can read more or deeper into an indication and what you should be aware of to follow best practices.
Finally, we don't need to deal with it anymore because we just did in the last episode, but we need to be aware that we are going to be using cookies for this again, so we can store that a user has authenticated and then we can check that cookie to see if they're authenticated and who they are. We will make it live for a certain amount of time. That could be a week or two weeks, whatever we decide. They will then live in the browser, so we don't need to
type in our password every time we try to access our page that is locked away. So that we have already done most of, we just need to repeat it and then we will upon logging in create a new cookie with this data and then we will do the same flow that we did with the flash messages. Great. This is
the essence of what we're going to be doing. We've already seen cookies, we've already seen middleware. We haven't touched upon it that much, but we have all of the elements in place to do this. So what we need to do is we need to add the users table. We need to generate the hashes and store them. We need also to verify our password and then create the cookie and
We are done, we can log in and only we or who we allow on a platform can interact with the admin page of our blog.
