DEV Community

Ariyo Aresa
Ariyo Aresa

Posted on

How an authentication system actually works

The processes that takes place when you sign up or login on a site is actually much more than just you filling a form and clicking a button
A lot of processes actually go on behind that login or sign up button and that those would be the main focus for this content.

When signing up on an app, the app sends the data to a database (a table containing everyone's data). However if all data are sent in plain text, the internet would be a scary place. This is why a series of step is taken to make sure your data is shared and stored securely

Phase 1: The sign up path

  1. The secure travel path (HTTPS/TLS):
    Before your data even leaves your computer, your browser establishes a secure connection using HTTPS. This creates an encrypted tunnel between you and the server. Even if someone intercepts your Wi-Fi signal, they only see "garbage" data. It is important to note that HTTPS secures the transit, but the server still needs to secure the storage
    NB: This is why you shouldn't login or sign up to sights that uses HTTP and not HTTPS

  2. Salting:
    A pinch of salt is usually added to highly sensitive credentials. This is to prevent hackers from using precalculated tables known as 'Rainbow Tables' to guess common passwords. The salt is usually a unique, random string of data added to your password.
    • ​Without Salt: Two people with the password Password123 would have the same hash in the database.
    • ​With Salt: Each user gets a unique salt, so their final hashes look completely different, even if their passwords are identical.

  3. Hashing:
    This is the biggest secret in web development. Good websites don't save your passwords in plain texts, after your password is salted, the server uses a cryptographic hash function to turn your password into hashes. Password123 becomes something like $2b$12$K1e58377$Kqkrsy after hashing.
    This process is a one-way thing. The hash cannot be turned back into your password

When logging in on the other hand, the server compare your input to that in the data base.

Phase 2: The Login path
When you return to login, the server doesn't decrypt your password (because it can't). Instead
The server looks for you email address or username to find your unique salt
If it exists, it attaches the salt to the password you just typed
it then hashes runs the combination once again through the same hash function used during sign up
It compares the new hash with the previous hash in the database. If they match, you get logged in and if they don't, you get an error.

Phase 3: Staying Logged in
To avoid the process of logging in on every single page click, the server generates a session token or a JWT (JSON web token).
These makes the computer remember that you've been logged in before and there's no need to collect your credentials again
Sessions: The server stores a session ID in it's memory and gives you a matching cookie. This makes the server remember you every time you visit a page
JWTs: The server gives you a digitally signed token. The server doesn't necessarily remember you, it just trusts that because the token that contains your information because it's signed

Top comments (0)