Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bearer tokens are just awful

mjg59.dreamwidth.org

Post reply on HN
Print view View original

21–30 of 148 posts

Re: Bearer tokens are just awful

#21

Post by xnorswap »

mjg59 wrote: post #15
iso1631 wrote: post #2

So don't set the token to expire after the "heat death of the universe", make the user reauthenticate after an appropriate time for the service being used.

The problem is that you don't have control over what third parties are doing here. You may have control over the policies associated with tokens issued by your identity provider, but how do you audit the policies that third party services are applying to their tokens?

I don't understand the argument here, if you're not issuing the tokens then they're not your responsibility.

Can you give a more fleshed out example, why should you audit third party services?

Re: Bearer tokens are just awful

#22

Post by mjg59 »

lelanthran wrote: post #7
lowwave wrote: post #4

Or you can put device/or ip related info baked into the token. That way when the user device or ip changes, you can invalidate the token.

> Or you can put device/or ip related info baked into the token. That way when the user device or ip changes, you can invalidate the token. yeah, I always wondered why there isn't a standard field in the JWT containing a fingerprint/hash of the client's machine/browser/etc.

If someone's in a position to exfiltrate the JWT, they're almost certainly in a position to extract all the information they'd need to reproduce the fingerprint. It'd be a short term strategy until attacker tooling caught up.

Re: Bearer tokens are just awful

#23

Post by lowwave »

lelanthran wrote: post #7
lowwave wrote: post #4

Or you can put device/or ip related info baked into the token. That way when the user device or ip changes, you can invalidate the token.

> Or you can put device/or ip related info baked into the token. That way when the user device or ip changes, you can invalidate the token. yeah, I always wondered why there isn't a standard field in the JWT containing a fingerprint/hash of the client's machine/browser/etc.

>yeah, I always wondered why there isn't a standard field in the JWT containing a fingerprint/hash of the client's machine/browser/etc.

Good that you brought it up. That's why I still bake my own verification session system.

Re: Bearer tokens are just awful

#24

Post by lowwave »

samarthr1 wrote: post #10
lelanthran wrote: post #7

Earlier quoted context omitted.

> Or you can put device/or ip related info baked into the token. That way when the user device or ip changes, you can invalidate the token. yeah, I always wondered why there isn't a standard field in the JWT containing a fingerprint/hash of the client's machine/browser/etc.

Advertisers would love such a thing

You can hash all that info, so if the user provide the right info (ip, browser string whatever), then the session key would be reconstructed as true.

Re: Bearer tokens are just awful

#25

Post by mjg59 »

xnorswap wrote: post #21
mjg59 wrote: post #15

Earlier quoted context omitted.

The problem is that you don't have control over what third parties are doing here. You may have control over the policies associated with tokens issued by your identity provider, but how do you audit the policies that third party services are applying to their tokens?

I don't understand the argument here, if you're not issuing the tokens then they're not your responsibility. Can you give a more fleshed out example, why should you audit third party services?

Hypothetical: I have a Github Enterprise org. Users log in via my identity provider to gain access. Github then issues a long-lived oauth token to the Github Desktop app. An attacker compromises a user's laptop and copies that oauth token. That attacker now has access to all my private repos until I notice and revoke it.

Re: Bearer tokens are just awful

#26

Post by withinboredom »

zabzonk wrote: post #8
recuter wrote: post #5

Earlier quoted context omitted.

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

And more secure would be....what?

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.

Re: Bearer tokens are just awful

#27

Post by recuter »

gary_0 wrote: post #19
recuter wrote: post #5

Earlier quoted context omitted.

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

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.

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..

Re: Bearer tokens are just awful

#28

Post by 3np »

So what is the option, actually? TEEs and TPMs which the end-user and device owner/operator/admim have zero control or insight into (or is this also under the scope of the "local enclave"?)

OP doesn't propose any in their opinion better alternatives. I'd argue for (roughly, on the move) client-side keys and cryptographic signing (mutual certs basically) and issuing session certs which could be counter-signed, with a short lifetime, but it sounds like they'd be against that too.

Under ZT, how precisely is one to confidently verify local state otherwise? There's a lot of value in the ZT paper and movement, but this particular aspect is both spooky and confounding.

Re: Bearer tokens are just awful

#29

Post by michaelt »

iso1631 wrote: post #2

So don't set the token to expire after the "heat death of the universe", make the user reauthenticate after an appropriate time for the service being used.

This is a common problem in enterprise single-sign-on systems.

The issue is: If the user presses the 'log out' button, you want it to take effect within a few seconds. But if logouts are simply a timestamped record expiring, they'd have to expire within seconds, and that would basically mean re-authenticating on every single request.

And at the same time, some webapps have shitty re-authentication flows (like discarding any unsaved work-in-progress and kicking the user back to the homepage) and they're only usable with a re-authentication periods measured in days.

Re: Bearer tokens are just awful

#30

Post by jiggawatts »

ghayes wrote: post #14
zabzonk wrote: post #3

> 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?

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.

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.
Post reply on HN