Objective

This document stands as a place for me to jot down notes and thoughts about session management. Common questions, and discussion points.

1. Should I use JWTs?
2. How should I generate my own secure random tokens?
3. How should I pass tokens between the client and server?
4. Do I need to be able to invalidate a token?

Why do I need to manage a session, what is it?

Web Applications are stateless. That means from the server side, at the moment the server recieves a request from a client (user) it has no idea who the user is making the request. Typically, the client will send a session identifier along with it’s request.

• What format should I use for the session id?
• What’s the best way to tag the session id onto the request?
• Should the session ID contain information about the user?

Token Options

What should the token format be? How should I create a token?

1. Random Token
2. JWT
3. Secure Cookies

Session IDs

You can generate your own Session IDs using your language’s builtin CSPRNG tooling. Generate a secure random number and use that as the session id for the current user. Pass that token back and forth between the client and server.

You will need to somehow track which SessionID is assigned to which user, which means you’ll need to store the token in a database, on the filesystem or somewhere else. Each time you get a request from the user, you will need to hit that datastore to find the right user.

Strict vs Permissive Tokens

There are 2 ways to accept

• Permissive: allows clients to provide their own tokens.
• Strict: the web app forces their tokens on the user. Tokens can only be generated by the app. If you get a weird token, then you force one you generated back on them.

What makes a good random token?

1. Length: The longer your token the harder it is to brute force by attackers.
2. Entropy (Randomness): Needs to be able to prevent attackers from guessing a valid token.
3. Meaningless: you don’t want to disclose information about the user through the session.

Don’t generate tokens based on just a username, ip address, time or anything guessable. If an attacker figures out that you are just SHA-246 hashing the users email. Then they could easily write a script to generate session tokens based on a list (email dump?) or email addresses they think are in your system. Dont do it.

For more information checkout the wikipedia page on CDPRNGs.

What does cryptographically secure mean?

Use a CSPRNG or Cryptographically Secure Pseudo-Random Number Generator must hold up to 2 tests:

1. next-bit test. How guessable is the next bit in a stream of bits when generating a random number?
2. state compromise extensions: if an attacker figures out the state of the PRNG being used, will they then be able to reconstruct the stream of bits?

Are there non cryptographically secure pseudo-random number generators? Why tools should I use?

Check your language docs to ensure the random builtins you’re using are indeed cryptographically secure. As an example, here are the docs for PHP’s rand() builtin.

Caution This function does not generate cryptographically secure values, and should not be used for cryptographic purposes. If you need a cryptographically secure value, consider using random_int(), random_bytes(), or openssl_random_pseudo_bytes() instead.

Here’s the docs around GoLang’s crypto/rand package:

Package rand implements a cryptographically secure random number generator.

JWT (JSON Web Tokens)

• What are JWTs?
• Why were they created, what problems did they solve?

Here’s the JWT (pronounced “jot”) Spec: https://tools.ietf.org/html/rfc7519

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.

When should I use JWTs?

authorization, particularly for one-time use

When should I not use JWTs?

to represent long-lived persistent session state

Pros

• doesn’t need a server side store?
  • Why not? Cuz the token is verified to not be altered when we parse it from the client?

Cons

• Large data size over the network, much larger than a generated token.
• contains claim data about the user.
• invalidation?

Session Management

What machanism should I use to pass the session ID back and forth between the client and server? There are a few ways to do this:

1. Cookie
2. HTTP Header
3. Query Parameter

Why should I use a cookie?

In a word, expiry.

From OWASP:

The preferred session ID exchange mechanism should allow defining advanced token properties, such as the token expiration date and time, or granular usage constraints. This is one of the reasons why cookies (RFCs 2109 & 2965 & 6265 [1]) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods.

A few other reasons to use cookies:

• Secure Attribute: The “Secure” cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection.
• HttpOnly Attribute: attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object.
• SameSite Attribute: allows a server define a cookie attribute making it impossible to the browser send this cookie along with cross-site requests.
• Domain and Path Attributes: attribute instructs web browsers to only send the cookie to the specified domain and all subdomains.
• Expire and Max-Age Attributes: Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the “Max-Age” (that has preference over “Expires”) or “Expires” attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based until the expiration time.

Resources:

• DZone: Stop Using JWTs as Session Tokens - Randall Degges
• PONYFOO.COM: JSON Web Tokens vs. Session Cookies: In Practice
• Ask HN: Cookies vs. JWT vs. OAuth
• Stackoverflow: SPA best practices for authentication and session management
• REST API security Stored token vs JWT vs OAuth
• OWASP: Session Management Cheat Sheet
• Stop using JWT for sessions - Sven Slootweg
  • HN Comments interesting that this challenges a lot of items in the article.