figure out sessions

[komuw]

• https://github.com/gorilla/sessions
• https://github.com/gofiber/fiber/tree/a5b2b8989b071e8da47e185514e84f983e40a632/middleware/session
• https://github.com/unrolled/secure

[komuw]

https://docs.djangoproject.com/en/4.0/topics/http/sessions/

[komuw]

If we decide to use memory store, we'll run into issue of sticky/non-sticky sessions

[komuw]

maybe we should just stay out of the session business; it's up to app developers to figure that out with their databases.

[komuw]

https://gist.github.com/komuw/4d44a25e1b6786100ffe0308106e80f2

[komuw]

Assume we're trying to minimize the fraction of requests that have to hit the database. 
Mainstream web application frameworks tend to already have features that help with this.

Give them a bag of attributes and get back a tamper-proof (optionally encrypted) string, 
using HMAC-SHA2 and AES-CBC. Put the string in a cookie. 
The server only remembers a root secret, and can pull user data out of the cookie instead of the database. 
This is how Rails sessions work.

You can’t generally use general-purpose user sessions for API tokens. 
But you can use the same features to build API tokens. 
Share the root secret among multiple services - maybe that's fine - 
and microservices don't have to rely on a central service.

These tokens are relatively simple, and can be stateless. What's the catch? 
You’re effectively using tokens as a database cache, and cache consistency is frustrating.
You’ve lost the simplest form of token revocation. 
You're not validating tokens against the database, 
so now you have to come up with another way to tell if they’ve been revoked. 
A pattern I’ve seen a bunch here, and one that I kind of like, is to “version” the users. 
Stick a token version in the user table, have tokens bear the current version. 
To revoke, bump the version in the database; outstanding tokens are now invalid. 
Of course, you need to keep state to do that, but the state is very cheap; 
a Redis cache of user versions, falling back to the database, does the trick.

• from https://fly.io/blog/api-tokens-a-tedious-survey/#platform-tokens

[komuw]

• https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence
• https://paragonie.com/blog/2016/09/untangling-forget-me-knot-secure-account-recovery-made-simple
• https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016
• https://paragonie.com/blog/2017/02/split-tokens-token-based-authentication-protocols-without-side-channels

[komuw]

JWT fails miserably at invalidation, or How do you log out the user?
The answer is, you don't. You can't. 
You (the server) can tell the user's client software to forget their JWT and 
hope they'll do it, but you can never be sure.

• from https://apibakery.com/blog/tech/no-jwt/
  Normal sessions that are not backed by a db and rely solely on cookies also have the same issue.
  You can delete the cookie, but a malicious client can decide not to honour the delition.

To solve this problem, save this in the cookie.

{
 ... stuff
 expires: timestamp   // check it is not expired.
request_ip: some-ip  // check they are using same IP as what was set before??
}

Of course, all this is authenticated and encrypted.
However, what if you set the timestamp to 2weeks, and then you decide you want to logout the user today(maybe to fix a security issue)?

[komuw]

see also: https://docs.djangoproject.com/en/4.1/topics/http/sessions/#using-cookie-based-sessions on replay attacks