Hacker News new | ask | show | jobs
by unscaled 390 days ago
tptacek's survey was already mentioned here, but I think it should be more famous. https://fly.io/blog/api-tokens-a-tedious-survey

Unfortunately, it seems like 99% of the industry decides which token to use based on Medium articles, LLM responses or how many unmaintained packages that implement this thing they can find on NPM.

JWT is mostly used as an access token, but for the vast majority of use cases it's a bad fit. If you've got low traffic no strict multi-region deployment requirements, random IDs are the best approach for you. They are extremely lean and easy to revoke. It's pretty secure: the only common vulnerabilities I can think of with this approach are session fixation[1] and timing attacks[2]. Both attacks are preventable if you take just a few simple precautions:

1. Always generate 32-byte session IDs using a cryptographically secure random number generator on authentication. (Never re-use existing session IDs for new logins)

2. Either use a cryptographic hash (e.g. SHA-256 or Blake2b) of the session ID a the database field used when querying sessions or make sure that the Session ID field is indexed with a hash-based index (B-trees are susceptible to timing attacks).

In cases where you really cannot use Session IDs, your service is usually big enough and important enough to use custom Protobuf tokens even a more special-purpose format like Macaroons. These formats give can be far more compact and give you full control on designing for your needs. For instance, if you want flexible claims (with most of them standardized across your services), together with encryption, you can use a combination of Protobuf and a libsodium secret box envelope.

[1] https://owasp.org/www-community/attacks/Session_fixation

[2] e.g. https://github.com/advisories/GHSA-cvw2-xj8r-mjf7

3 comments

I use JWT and a half dozen other standards, not by choice though, I wished I could do what you suggest it would simplify everything a ton, but I'm not going to roll my own multi-org/SSO/2FA auth platform. Needing those auth features is what made me use these standards not because my app is big, it's not it's tiny.
> or make sure that the Session ID field is indexed with a hash-based index

Using a hash index instead of a btree isn't a 100% guaranteed solution because there may be craftable collisions (because e.g. postgres's index hash is not cryptographic) which cause fallback to linear comparison across the values inside the hash bucket:

https://dba.stackexchange.com/questions/285739/prevent-timin...

So hashing the ID before the DB lookup is better.

sessionID is vulnerable to stealing cookies. Some games - if you lose your session cookie, you might as well lose your account and everything you have on it.

you can of course bind sessionID to the IP address, but this is extra effort you need to put. in JWT land you can just put the IP addressed inside the payload and forward requests with non-matching IP to reauth and regenerate JWT for their new IP in case customer is roaming networks