3 ms·

> In theory you could just hand someone a randomly generated blob, but then you'd need to keep track of which blobs you've issued and when they should be expir

> In theory you could just hand someone a randomly generated blob, but then you'd need to keep track of which blobs you've issued and when they should be expired and who they correspond to Is this so difficult?

recuter 5y ago
It isn't until it is. And wherever you store it is a juicy target.
- zabzonk 5y ago
  And more secure would be....what?
  - withinboredom 5y ago
    Not localstorage. :) I've seen them in http-only cookies which is sent with every request but not inspectable by js. The server can automatically refresh the token every-so-often transparently without the client even being aware or able to influence it in any way.
- mike-cardwell 5y ago
  When will "until it is" kick in? It has never kicked in for me...
  - zimpenfish 5y ago
    I've worked at a couple of places where the session token lookups were the bulk of database traffic - to the extent that one place had to split it off to its own cluster just to stop it clogging everything up.
- gary_0 5y ago
  Wouldn't you just store it in the same place you're storing the main authentication data (eg. password hashes)? [edit] I guess that database would get hammered pretty hard on every request, unless you use caching... which might be what you're getting at.
  - recuter 5y ago
    I'm sure tptacek will be along shortly to elaborate. One would think it gets stored in the database, but man all these hashes are so slow to generate. And which library are we using again for that? bcrypt? scrypt? Seems unnecessarily slow. I bet SHA256 is good 'nuff, and way faster. Lets just meanwhile call the cloud consultant to move this to a separate service. Have you heard the good word about AWS Cognito? I heard its web scale. Nah, too expensive, we should just write our own real quick how hard can it be..
  - icedchai 5y ago
    Most sites would be lucky to have this problem. Store your sessions in redis and call it a day.
dub 5y ago
It's strictly more complex without much additional benefit. To have zero-trust random blob tracking you'd still need public key infrastructure, and you'd have a system which is overall more complex and has more ways to break (running out of data storage, network partitions to the database, etc.). A revocation list would be a smaller, easier-to-distribute dataset if you were going to keep data related to specific tokens around.
- zabzonk 5y ago
  I don't see why you need a revocation list - you just need to check access date with the security key. And do a sweep say every couple of hours to delete the security keys that haven't been used.
  - danbulant 5y ago
    If a user decides to logout from certain device, or when you need to log out an active session early
  - Sirened 5y ago
    Revocation is important for SSO and, generally, on corporate systems. When you fire an employee and suspend their systems access, you really don't want a dangling session token to be useable, so you need to support early revocation. The revocation lists will be comparatively very small and so distributing them is less of a challenge. It's mostly just a pain.
ghayes 5y ago
These are just sessions (e.g. session cookies). The arguments against using database-stored sessions are generally brought up in the context of microservices or decentralized systems where that service/machine that keeps track of sessions becomes a bottleneck/single point of failure for a much larger system.
- jiggawatts 5y ago
  Session tokens are easy to shard / partition to any number of machines. Just use a random identifier like a GUID. Allocate IDs to machines using either the prefix or any one of the scalable hashing algorithms.
  - RedShift1 5y ago
    But that's boring technology that has worked for decades. We don't want that. /s
Arnt 5y ago
It is surprisingly difficult in desirable cases, for example if you want your backend architecture to be spread across several sites and with no single point of failure. If the client starts using the token immediately, propagating that token to all servers before the first use is a harsh requirement.

recuter 5y ago

It isn't until it is. And wherever you store it is a juicy target.

zabzonk 5y ago
And more secure would be....what?
- withinboredom 5y ago
  Not localstorage. :) I've seen them in http-only cookies which is sent with every request but not inspectable by js. The server can automatically refresh the token every-so-often transparently without the client even being aware or able to influence it in any way.
mike-cardwell 5y ago
When will "until it is" kick in? It has never kicked in for me...
- zimpenfish 5y ago
  I've worked at a couple of places where the session token lookups were the bulk of database traffic - to the extent that one place had to split it off to its own cluster just to stop it clogging everything up.
gary_0 5y ago
Wouldn't you just store it in the same place you're storing the main authentication data (eg. password hashes)? [edit] I guess that database would get hammered pretty hard on every request, unless you use caching... which might be what you're getting at.
- recuter 5y ago
  I'm sure tptacek will be along shortly to elaborate. One would think it gets stored in the database, but man all these hashes are so slow to generate. And which library are we using again for that? bcrypt? scrypt? Seems unnecessarily slow. I bet SHA256 is good 'nuff, and way faster. Lets just meanwhile call the cloud consultant to move this to a separate service. Have you heard the good word about AWS Cognito? I heard its web scale. Nah, too expensive, we should just write our own real quick how hard can it be..
- icedchai 5y ago
  Most sites would be lucky to have this problem. Store your sessions in redis and call it a day.

dub 5y ago

It's strictly more complex without much additional benefit. To have zero-trust random blob tracking you'd still need public key infrastructure, and you'd have a system which is overall more complex and has more ways to break (running out of data storage, network partitions to the database, etc.). A revocation list would be a smaller, easier-to-distribute dataset if you were going to keep data related to specific tokens around.

zabzonk 5y ago
I don't see why you need a revocation list - you just need to check access date with the security key. And do a sweep say every couple of hours to delete the security keys that haven't been used.
- danbulant 5y ago
  If a user decides to logout from certain device, or when you need to log out an active session early
- Sirened 5y ago
  Revocation is important for SSO and, generally, on corporate systems. When you fire an employee and suspend their systems access, you really don't want a dangling session token to be useable, so you need to support early revocation. The revocation lists will be comparatively very small and so distributing them is less of a challenge. It's mostly just a pain.

ghayes 5y ago

These are just sessions (e.g. session cookies). The arguments against using database-stored sessions are generally brought up in the context of microservices or decentralized systems where that service/machine that keeps track of sessions becomes a bottleneck/single point of failure for a much larger system.

jiggawatts 5y ago
Session tokens are easy to shard / partition to any number of machines. Just use a random identifier like a GUID. Allocate IDs to machines using either the prefix or any one of the scalable hashing algorithms.
- RedShift1 5y ago
  But that's boring technology that has worked for decades. We don't want that. /s

Arnt 5y ago

It is surprisingly difficult in desirable cases, for example if you want your backend architecture to be spread across several sites and with no single point of failure. If the client starts using the token immediately, propagating that token to all servers before the first use is a harsh requirement.