\n<\/p>\n
User Registration & Secure Password Hashing with bcrypt<\/p>\n
In the previous article, we built the backend foundation by setting up Express.js, PostgreSQL, environment variables, and a clean layered architecture.<\/p>\n
With the backend ready, it’s time to implement the first authentication feature\u2014User Registration.<\/p>\n
Although registration appears straightforward, it involves much more than simply storing user details in a database. A secure registration system must validate user input, prevent duplicate accounts, protect passwords, and ensure that sensitive information is never exposed.<\/p>\n
In this article, we’ll build the complete registration workflow while following security best practices.<\/p>\n
The registration process follows a layered architecture, where each layer has a single responsibility.<\/p>\n
Client
\n \u2502
\n \u25bc
\nRoutes
\n \u2502
\n \u25bc
\nController
\n \u2502
\n \u25bc
\nService
\n \u2502
\n \u25bc
\nRepository
\n \u2502
\n \u25bc
\nPostgreSQL<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
The overall workflow is:<\/p>\n
The client submits the registration form.
\nThe controller receives the request.
\nThe service validates the data.
\nThe repository checks whether the email already exists.
\nThe password is securely hashed using bcrypt.
\nThe user is stored in PostgreSQL.
\nA success response is returned to the client.<\/p>\n
Instead of placing all the registration logic inside the controller, I divided the implementation into three layers.<\/p>\n
Controller<\/p>\n
Responsible only for:<\/p>\n
Receiving the HTTP request
\nCalling the service layer
\nReturning the HTTP response<\/p>\n
The controller should never contain business logic or database queries.<\/p>\n
Service<\/p>\n
The service contains the application’s business logic.<\/p>\n
For registration, it is responsible for:<\/p>\n
Validating the request
\nChecking whether the email already exists
\nHashing the password
\nCalling the repository to save the user<\/p>\n
This layer acts as the brain of the application.<\/p>\n
Repository<\/p>\n
The repository communicates directly with PostgreSQL.<\/p>\n
Its responsibilities include:<\/p>\n
Checking if a user already exists
\nCreating a new user
\nExecuting SQL queries<\/p>\n
Keeping SQL isolated inside repositories makes the application easier to maintain and test.<\/p>\n
The controller receives the registration request and forwards the data to the service layer.<\/p>\n
\/\/ Register Controller Screenshot Here<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
The controller itself performs very little work.<\/p>\n
Its responsibility is simply to:<\/p>\n
Extract the request body
\nCall the service
\nReturn either a success or an error response<\/p>\n
This keeps controllers lightweight and easy to understand.<\/p>\n
The service contains the actual registration workflow.<\/p>\n
\/\/ Register Service Screenshot Here<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
The registration service performs the following steps:<\/p>\n
Check whether the email already exists.
\nGenerate a secure password hash.
\nCreate the user in PostgreSQL.
\nReturn the newly created user.<\/p>\n
Because all business rules live inside the service layer, future changes become much easier.<\/p>\n
For example, adding email verification later would require changes only inside the service, without affecting controllers or repositories.<\/p>\n
The repository is responsible only for database communication.<\/p>\n
\/\/ Repository Screenshot Here<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
Typical repository functions include:<\/p>\n
findByEmail()
\ncreateUser()<\/p>\n
Keeping SQL queries isolated improves readability and keeps the service layer database-agnostic.<\/p>\n
One of the biggest mistakes an application can make is storing passwords in plain text.<\/p>\n
Imagine a database leak.<\/p>\n
If passwords are stored as plain text, every user’s credentials become immediately visible.<\/p>\n
Instead, passwords should always be transformed into a secure one-way hash before being stored.<\/p>\n
This is exactly why we use bcrypt.<\/p>\n
bcrypt is one of the most trusted password hashing libraries available for Node.js.<\/p>\n
Unlike encryption, hashing is a one-way operation.<\/p>\n
This means:<\/p>\n
The original password cannot be recovered.
\nEven the application itself cannot view the user’s password.
\nOnly password verification is possible.<\/p>\n
When a user registers, bcrypt performs several operations internally.<\/p>\n
Password
\n \u2502
\n \u25bc
\nGenerate Random Salt
\n \u2502
\n \u25bc
\nPassword + Salt
\n \u2502
\n \u25bc
\nMultiple Hashing Rounds
\n \u2502
\n \u25bc
\nStore Hash in Database<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
Each password receives its own randomly generated salt before hashing.<\/p>\n
Because of this:<\/p>\n
Two users with the same password will have completely different hashes.
\nRainbow table attacks become ineffective.
\nBrute-force attacks become significantly slower due to bcrypt’s configurable cost factor.<\/p>\n
During login, the user enters their password as plain text.<\/p>\n
bcrypt then:<\/p>\n
Reads the stored hash.
\nExtracts the embedded salt.
\nHashes the entered password using the same salt.
\nCompares the generated hash with the stored hash.<\/p>\n
If both hashes match, the user is successfully authenticated.<\/p>\n
const isMatch = await bcrypt.compare(
\n enteredPassword,
\n storedHash
\n);<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
One of bcrypt’s biggest advantages is that developers never need to manually manage salts or compare hashes\u2014the library handles the entire verification process securely.<\/p>\n
Using bcrypt provides several important security advantages.<\/p>\n
\u2705 Passwords are never stored in plain text.<\/p>\n
\u2705 Every password uses a unique random salt.<\/p>\n
\u2705 Identical passwords generate different hashes.<\/p>\n
\u2705 Brute-force attacks become significantly slower.<\/p>\n
\u2705 Rainbow table attacks are mitigated.<\/p>\n
These features make bcrypt one of the industry standards for password protection.<\/p>\n
Once the backend implementation was complete, I verified the registration API using Postman.<\/p>\n
Request<\/p>\n
POST \/api\/auth\/register<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
{
\n “username”: “Sriya”,
\n “email”: “sriya@gmail.com”,
\n “password”: “Password123”
\n}<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
Response<\/p>\n
{
\n “success”: true,
\n “user”: {
\n “id”: 1,
\n “username”: “Sriya”,
\n “email”: “sriya@gmail.com”
\n }
\n}<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
Notice that the response never includes the password or its hash.<\/p>\n
Only non-sensitive user information is returned to the client.<\/p>\n
Now that users can securely register and their passwords are safely stored, the next step is allowing them to authenticate.<\/p>\n
In the next article, we’ll build the Login Flow, where we’ll:<\/p>\n
Verify user credentials
\nCompare passwords using bcrypt
\nGenerate JWT Access Tokens
\nGenerate Refresh Tokens
\nUnderstand how JWT authentication works internally<\/p>\n