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

71–80 of 148 posts

Re: Bearer tokens are just awful

#71

Post by mjg59 »

vbezhenar wrote: post #68

I don’t get this article. How are you supposed to validate hardware? There’s no API for that. You can bind session to IP but that wouldn’t work for modern mobile connections. Ideally hardware should have protected private key with manufacturer signature. And API to sign something. Then you can bind session to hardware. But that’s not available today.

You don't verify the hardware directly. You provide a mechanism for client certificate validation (I issue the certs, I can assert that they're tied to hardware), and you provide a callback for validating device state (I define the validation policy, I compare that against the data that I have and say yes or no). It's not about services taking responsibility for this themselves, it's about providing mechanisms for customers to have their own policies enforced.

Re: Bearer tokens are just awful

#72

Post by RedShift1 »

jiggawatts wrote: post #30
ghayes wrote: post #14

Earlier quoted context omitted.

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.

But that's boring technology that has worked for decades. We don't want that. /s

Re: Bearer tokens are just awful

#73

Post by nannal »

mjg59 wrote: post #66
Sirened wrote: post #64

Why does the author assume we want to associate a bearer token with hardware at all? When my services issue a JWT, I am issuing a right to talk to my service. If you want to take that token and move it to your phone, neat good for you. If someone steals your laptop and dumps the secret, that's sure as hell not my problem to solve. The application layer is not the appropriate place to apply a mitigation for a user's l…

You're free to assert that it's not your issue to solve, and I'm free to assert that I'm not using your service as a result. It is possible to provide equivalent functionality without it being trivial to exfiltrate authentication tokens to other devices, and I can't see any good reasons for refusing to do so.

Your expectations might be too high, would you like all applications to monitor if you enter a bad part of town and revoke tokens just in case?

Re: Bearer tokens are just awful

#74

Post by mjg59 »

nannal wrote: post #73
mjg59 wrote: post #66

Earlier quoted context omitted.

You're free to assert that it's not your issue to solve, and I'm free to assert that I'm not using your service as a result. It is possible to provide equivalent functionality without it being trivial to exfiltrate authentication tokens to other devices, and I can't see any good reasons for refusing to do so.

Your expectations might be too high, would you like all applications to monitor if you enter a bad part of town and revoke tokens just in case?

No, I'd like applications to check with me whether I was ok with the state of my user and their device.

Re: Bearer tokens are just awful

#75

Post by soco »

xnorswap wrote: post #58
soco wrote: post #50

Earlier quoted context omitted.

I didn't think about this, nice feature, very useful in a very distributed system. From the end user (human) perspective on the other hand, it will be stored in a password manager and will need authorization calls and and and - so the only improvement I see is that you can't use "123456" as root account credentials anymore.

I don't think a user should be able to tell the difference. The initial handshake would still use something like passwords or API keys to authenticate the user. The difference is post-login, where authentication can return for example a 'session key' or can return a JWT or other token that can then be used to say, "I've logged in, I'm xnorswap and I'm allowed in the system until 202204051200Z. I'm allowed access to v…

Post login scenario which can happen also after a password authentication :) I mean it already happens, in places... (but your point about distributed heavy duty systems still stands, to keep in mind)

Re: Bearer tokens are just awful

#76

Post by _8j50 »

I agree with OP. The security model is similar to kerberos tickets or ntlm hashes.

Revokable Private key authorizarion is the best way to go imho. I don't mean at the transport layer but at the HTTP/app layer. This should replace not just bearer tokens but authentication cookies as well. Each connection is authenticated by the final server.

Hopefully you can store the private key on fido or tpm as well to make theft harder, forcing attackers to maintain persitent compromise of your host.

Re: Bearer tokens are just awful

#77

Post by 3np »

mjg59 wrote: post #71
vbezhenar wrote: post #68

I don’t get this article. How are you supposed to validate hardware? There’s no API for that. You can bind session to IP but that wouldn’t work for modern mobile connections. Ideally hardware should have protected private key with manufacturer signature. And API to sign something. Then you can bind session to hardware. But that’s not available today.

You don't verify the hardware directly. You provide a mechanism for client certificate validation (I issue the certs, I can assert that they're tied to hardware), and you provide a callback for validating device state (I define the validation policy, I compare that against the data that I have and say yes or no). It's not about services taking responsibility for this themselves, it's about providing mechanisms for cu…

You are talking about SGX-style TEEs, is that correct? Effectively putting hardware manufacturers as ultimate issuers with corresponding ultimate authority (ie spoofing, revocation, tracking)

Or if not, how would you envision it?

Re: Bearer tokens are just awful

#78

Post by 3np »

lelanthran wrote: post #39
sokoloff wrote: post #18

Earlier quoted context omitted.

It could be used to tie that logged in user to other web sessions that are currently anonymous.

> It could be used to tie that logged in user to other web sessions that are currently anonymous. If those other sessions are anonymous, why do they have the token? See, I'm not very experienced in web-dev, and I'm very much aware that I may not know what I am talking about. I'm just trying to understand how the tracking data in the bearer token will "leak". Can you give me a scenario, like "Client goes to SiteA, is…

You may have different personas that you want to separate. Ie your identity as a local county representative, your identity with a socialist online forum, your identity as employee, your identity as someone discussing weird sexual kinks.

For all you need to identify but you don not want them to be linkable to each other or your government-issued ID.

This is part of why relying on phone number validation for gatekeeping is an issue. (Try registering at Discord or Twitter via tor. I'll wait)

Re: Bearer tokens are just awful

#79

Post by Sirened »

mjg59 wrote: post #66
Sirened wrote: post #64

Why does the author assume we want to associate a bearer token with hardware at all? When my services issue a JWT, I am issuing a right to talk to my service. If you want to take that token and move it to your phone, neat good for you. If someone steals your laptop and dumps the secret, that's sure as hell not my problem to solve. The application layer is not the appropriate place to apply a mitigation for a user's l…

You're free to assert that it's not your issue to solve, and I'm free to assert that I'm not using your service as a result. It is possible to provide equivalent functionality without it being trivial to exfiltrate authentication tokens to other devices, and I can't see any good reasons for refusing to do so.

Is this a wholehearted departure then from the whole "Simplicity Principle"? Not to be a complete ass, but in your view is there a defensible reason why every single layer of the entire network stack does not guarantee integrity? It would make things more reliable, after all you would still be guaranteed integrity even if TCP is broken! But we don't do that because we acknowledge that maybe we should be solving issues at the poignant location in the stack rather than just haphazardly shoving things in because we need said things in general.

I'm not disagreeing with your underlying point, really. I do agree that authentication is broken in that it fails to provide the actual guarantees we think it does. This is what I was getting at with my point above about issuing a right to talk to my service--that is, in reality, all any practical authentication system can provide today. You simply can't be certain the TPM your service stashed it's keys is secure without forcing attestation (again, problematic). Therefore, as far as your service can assume, your client may have just published the keys for the world to see. This leaves you in no better a theoretical position and it does not solve any of the problems identified with any other auth mechanism purely because it is not fundamentally.

Re: Bearer tokens are just awful

#80

Post by saagarjha »

Sirened wrote: post #64

Why does the author assume we want to associate a bearer token with hardware at all? When my services issue a JWT, I am issuing a right to talk to my service. If you want to take that token and move it to your phone, neat good for you. If someone steals your laptop and dumps the secret, that's sure as hell not my problem to solve. The application layer is not the appropriate place to apply a mitigation for a user's l…

I get the feeling that the author is speaking from the context of corporate zero trust, where they would like certain policies enforced on an endpoint before it is allowed to access a service, and thus transferring the token to an unmanaged device is considered a problem.
Post reply on HN