Bearer tokens are just awful • Hacker News Board

Re: Bearer tokens are just awful

#121

Post by [deleted] » Tue, Apr 05, 2022, 8:37 PM UTC

thwayunion wrote: post #110

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…

> If someone steals your laptop and dumps the secret, that's sure as hell not my problem to solve. I'm actually curious about the legal situation of stuff like this. Specifically, 1. You issue me a token, 2. that token gets stolen, 3. the stolen token is used to run up a big bill on your service, 4. I refuse to pay that bill (the case being "my laptop was stolen and your service was stolen -- sucks to by both of us,…

[deleted]

Re: Bearer tokens are just awful

#122

Post by arcbyte » Tue, Apr 05, 2022, 9:01 PM UTC

thwayunion wrote: post #110

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…

> If someone steals your laptop and dumps the secret, that's sure as hell not my problem to solve. I'm actually curious about the legal situation of stuff like this. Specifically, 1. You issue me a token, 2. that token gets stolen, 3. the stolen token is used to run up a big bill on your service, 4. I refuse to pay that bill (the case being "my laptop was stolen and your service was stolen -- sucks to by both of us,…

Legally it depends on the service that was stolen. Was this a banking or credit website where some consumer protections might apply or do you have any contractual limitations on cost that may protect you?

But generally you will be liable for the costs incurred from items stolen from your custody. You must then recover those costs from whoever stolen from you

Re: Bearer tokens are just awful

#123

Post by mooreds » Tue, Apr 05, 2022, 9:02 PM UTC

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 like a good rant as well as the next person, but had some issues with this one.

> What if we have a scenario where a third party authenticates the client (by verifying that they have a valid token issued by their ID provider) and then uses that to issue their own token that's much longer lived?

He might as well be complaining about car keys. Yes, if I leave my car key in the door of my car, bad things will happen. If you issue a long lived bearer token, bad things will happen.

Bearer tokens are credentials. Short lived and limited, but still credentials. You have to take care of credentials!

Use short lived bearer tokens and refresh tokens. Threat model the ramifications of someone stealing the token. If you really higher assurances, look into client bound bearer tokens (DPoP and MTLS in the OAuth world.)

For a common use case (I work for an auth provider, more details in my bio) of browsers or native applications integrating with other applications and APIs, what are other options for verifying a client is authorized to access a resource:

* sessions, probably with cookies. Well known, solid technology. Requires you to either have sticky sessions (so every client request goes to the same server) or a common session store (redis, etc).

* client certificates. If you control all deployment (intranet, employee laptops, etc) can be an option. https://buoyant.io/mtls-guide/ is a good resource if you are doing service to service communication.

* API keys. How do you like your credentials with no internal data structure. Plus, they live forever until you build a rotation system. Yay!

* client bound tokens as mentioned above

I'm not sure what other options are available.

Edit: formatting

Re: Bearer tokens are just awful

#124

Post by nybble41 » Tue, Apr 05, 2022, 9:25 PM UTC

mjg59 wrote: post #113

Sirened wrote: post #108

Earlier quoted context omitted.

100%! As a _user_ I personally would love if I could store all my session authentication info in my device's TPM/SEP for my own safety. I do this with my SSH keys for specifically the reason you suggest—I like that my private keys are non-exportable and so installing a public key on a server is a solid authentication for one device and one device only. This, however, only establishes trust on _my_ end. My SSH servers…

https://github.com/google/go-attestation is a free implementation of remote attestation that's not associated with any CPU type and will work on anything that has a TPM. But what we want here isn't really remote attestation (which implies attesting to the overall state of the device), it's key attestation (where you verify that the key was generated on a legitimate TPM). But there's still a legitimate privacy concern…

> key attestation (where you verify that the key was generated on a legitimate TPM)

This is the same problem, just one level further down. The scheme depends on hardware acting against the desires of its owner—whether we're talking about the entire system or just the TPM portion. The privacy concerns are real but not the full extent of the problem.

Re: Bearer tokens are just awful

#125

Post by nybble41 » Tue, Apr 05, 2022, 9:28 PM UTC

mjg59 wrote: post #112

nybble41 wrote: post #106

Earlier quoted context omitted.

That approach requires remote attestation (or you can't trust the TPM / secure enclave), which is far too much to ask unless you actually own the device being used to access the service.

The credential issuer is (in general) not in a position to make a determination whether the device is trustworthy or not. In an ideal world, I (the person responsible for the security of the device) would be able to ask the issuer to delegate that decision to me (which is what we want for a full ZTA experience), but in the absence of that it's legitimate for the issuer to assume that when the client asserts that a ke…

> in the absence of that it's legitimate for the issuer to assume that when the client asserts that a key was generated in hardware that it was telling the truth

You want the credentials to be non-extractable. The client wants to extract the credentials and use them somewhere else. Blind trust in an unsupported assertion from a client with diametrically opposing goals is not much of a security model.

Re: Bearer tokens are just awful

#126

Post by dzhiurgis » Tue, Apr 05, 2022, 9:51 PM UTC

mjg59 wrote: post #120

dzhiurgis wrote: post #119

Earlier quoted context omitted.

That’s why you use platform that already solved IP address and other client fingerprinting. If you are really paranoid - you setup alert policies when users are exfiltrating suspicious amount of info.

IP fingerprinting is unhelpful - the user experience for mobile devices becomes terrible. Any other client fingerprinting is easily duplicated.

> user experience for mobile devices becomes terrible

Cant have Your cake and eat it too

> client fingerprinting is easily duplicated.

Far from it.

Re: Bearer tokens are just awful

#127

Post by mjg59 » Tue, Apr 05, 2022, 9:53 PM UTC

mooreds wrote: post #123

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 like a good rant as well as the next person, but had some issues with this one. > What if we have a scenario where a third party authenticates the client (by verifying that they have a valid token issued by their ID provider) and then uses that to issue their own token that's much longer lived? He might as well be complaining about car keys. Yes, if I leave my car key in the door of my car, bad things will happen.…

> If you issue a long lived bearer token, bad things will happen.

I can issue a short lived bearer token, and another service I don't control can then decide based on that to issue a long lived one and I have no generic way to gain insight into that.

Re: Bearer tokens are just awful

#128

Post by thwayunion » Tue, Apr 05, 2022, 9:54 PM UTC

arcbyte wrote: post #122

thwayunion wrote: post #110

Earlier quoted context omitted.

> If someone steals your laptop and dumps the secret, that's sure as hell not my problem to solve. I'm actually curious about the legal situation of stuff like this. Specifically, 1. You issue me a token, 2. that token gets stolen, 3. the stolen token is used to run up a big bill on your service, 4. I refuse to pay that bill (the case being "my laptop was stolen and your service was stolen -- sucks to by both of us,…

Legally it depends on the service that was stolen. Was this a banking or credit website where some consumer protections might apply or do you have any contractual limitations on cost that may protect you? But generally you will be liable for the costs incurred from items stolen from your custody. You must then recover those costs from whoever stolen from you

> Was this a banking or credit website where some consumer protections might apply

Let's assume not.

> or do you have any contractual limitations on cost that may protect you?

I guess in this hypothetical case the person whose laptop was stolen cancels the credit card before the charge is made.

> But generally you will be liable for the costs incurred from items stolen from your custody.

Right... but who was the victim of theft here? The service provider or the client of the service provider?

> You must then recover those costs from whoever stolen from you

So... can the service provider sue you to pay for unauthorized use of your account? Or would that get thrown out and then they would have to go sue the person who actually stole the service?

I think it's clear to me that once the service provide gets cash from the person whose laptop was stolen, it's the problem of the person whose laptop was stolen. But if not, is the problem of the service provider?

Re: Bearer tokens are just awful

#129

Post by mjg59 » Tue, Apr 05, 2022, 9:56 PM UTC

nybble41 wrote: post #125

mjg59 wrote: post #112

Earlier quoted context omitted.

The credential issuer is (in general) not in a position to make a determination whether the device is trustworthy or not. In an ideal world, I (the person responsible for the security of the device) would be able to ask the issuer to delegate that decision to me (which is what we want for a full ZTA experience), but in the absence of that it's legitimate for the issuer to assume that when the client asserts that a ke…

> in the absence of that it's legitimate for the issuer to assume that when the client asserts that a key was generated in hardware that it was telling the truth You want the credentials to be non-extractable. The client wants to extract the credentials and use them somewhere else. Blind trust in an unsupported assertion from a client with diametrically opposing goals is not much of a security model.

I'm not the service owner. I care about credentials on my clients being hardware backed, and I have enough control over the platform to have reasonable confidence that they'll make a truthful assertion. Clients managed by other people may have different priorities, and should be able to make their own decisions.

Re: Bearer tokens are just awful

#130

Post by mjg59 » Tue, Apr 05, 2022, 9:58 PM UTC

dzhiurgis wrote: post #126

mjg59 wrote: post #120

Earlier quoted context omitted.

IP fingerprinting is unhelpful - the user experience for mobile devices becomes terrible. Any other client fingerprinting is easily duplicated.

> user experience for mobile devices becomes terrible Cant have Your cake and eat it too > client fingerprinting is easily duplicated. Far from it.

> Cant have Your cake and eat it too

Or we could just use credentials that can be tied to the hardware, and then we have stronger security assertions than tying to IP, and without any degraded user experience.