Authentication Tokens and Sessions

Authentication Tokens

Registration
- User sends username and password
- Validate password strength
- Store bcrypt salted hash of the password
Authentication
- User sends username/password
- Retrieve the stored salt and salted hash for the username
- Salt and hash the provided password
- If both salted hashes are identical, the user is authenticated

With authentication, we want users to be able to:
- Access their private data
- Make authenticated posts to the server
When you take these actions on a web app:
- The app should verify that you made the request
- Only serve your private data to you
- Do not let anyone else make posts in your name

How does the server verify that you are the one who made a specific request?
We only have authentication
Users would have to type their username and password with every single protected request
- No! Terrible user experience
- Some apps make authenticated requests every few seconds to load more content while users doom scroll
- You would not use this app if you have to type your password constantly

Instead of authenticating the username/password on every request:
- Issue an authentication token
When a user is authenticated, generate a random authentication token
Store [a hash of] this token in your database and mark the username of the account that was authenticated
Set the token as a cookie for that user
Whenever a request comes with that token, treat them as the user associated with that token
- By looking up the token in your database

With authentication tokens:
- We now have a login system! 🎉
As long as the user has the authentication token as their cookie, they are logged in
- All their requests are authenticated by the server
You can/should set these tokens to expire
- Expire client-side (cookie expiration)
- Expire server-side (storing an expiration timestamp in your database and ignoring the token after that timestamp)
The token might expire in years, depending on your application

Once a token is generated, set it as a cookie
Now the token will be sent with all subsequent requests
Use the token to lookup the user
The possession of the token verifies that this user did authenticate in the past

Check each request for a cookie with a token
- Lookup the hash of the token in the database
- If the token is found, read the associated username
- Proceed as though this request was made by that user
If the token is invalid or no cookie is set
- Do not respect the request and return a 400-level response code:
  - 401 Unauthorized - User is not logged in
  - 403 Forbidden - User in logged in, but trying to do something that they are not allowed to do
Ensure all sensitive pages/features are secured this way!
- The front end cannot be trusted (NEVER trust your users)
- All checks must be performed server-side

Authentication tokens need to be random and unguessable
- The token must have enough entropy that they cannot be guessed by an attacker
- Eg. An attacker should not be able to send requests with random tokens until one matches a logged in user
Generally, there should be at least 2^80 unique tokens that could be generated (80 bits of entropy)
- More is better!
Since you are generating these tokens, and no human has to remember them, you can simply choose the entropy
- Generate a random hex value of length 10?
  - You already have 160 bits of entropy
- Why not generate length 50 and have 800 bits of entropy 🤷

(Caution: These tokens need to be stored on the server){.yellow}
These tokens are about as sensitive as passwords!
- Stealing a token and setting a cookie with that value grants access to an account without even needing a password
Protection: Only store hashes of the tokens
Anyone with access to the database cannot hijack anyone's Sessions
With such high entropy, no known attacks can find the tokens given the hashes

Do not salt auth tokens
With arbitrarily high entropy, even rainbow tables are useless
- Salting does not add any protection when attacks are already effectively impossible
Salting would make your job more difficult
- You id a user based solely on their token
- You don't know the salt for a user without looking up their account
- You need to test all users in your database making every request O(n) where n is the number of registered users
brcrypt is made for passwords. Don't use it for tokens
- SHA256 is preferred

Auth tokens are typically lax, so we must understand the rules of when the token is sent
All 1st party requests contain lax cookies
- As long as the site making the request is the same as the site that set the cookie, it will be sent
- Here "site" means the protocol and host combination. Not the port
  - Example: A request from localhost:5000 to localhost:8080 is considered SameSite
A 3rd party requests contain lax cookies if it both:
1. Is a GET request
2. Navigates to your app
This is a major reason why GET requests should not change the state of your app
- A GET request should only get information
- Since the user is navigating to your app, an attacker cannot see the response