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

61–70 of 148 posts

Re: Bearer tokens are just awful

#61

Post by jillesvangurp »

mjg59 wrote: post #52
jillesvangurp wrote: post #45

Earlier quoted context omitted.

Exactly, all of the reasons bearer tokens might be awful are essentially self inflicted pain. Simple suggestion: don't do that and do it right instead. It's an opaque blob, by design. Which means it could be anything. Including something bearing useful information that you can verify in a sane way. In our case, we use JWT tokens that contain a few claims, are signed, have an expiration token, etc. Not awful at all. V…

And if I compromise a system that possesses one of those JWTs, I can copy it elsewhere and have access to all the resources that JWT grants me access to. You're not tying it to a specific device, and you're not providing a mechanism to verify the device state when making the access decision.

That's why we use expiration times. If I was a bank, I would be using very short expiration times and also use second factors. And have a lot of ceremony around releasing our app. And if I cared enough I would indeed add some claims narrowing down the scope of the token to a device, require our user to wear tin foil hats, and what not. Security measures are proportional to the thing they protect. Plenty of banks use both bearer tokens and JWTs. Nothing inherently wrong with that.

If your require these things, do them. If you don't, then don't.

Re: Bearer tokens are just awful

#62

Post by mormegil »

xnorswap wrote: post #31
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.

A big limitation is forced early expiration. If you need to do that then you end up needing to share expiration information and therefore need to share something that might as well be a password hash. So for example it's not great to use instead of a session key. You could design a system where you have, say, 6 API endpoints and instead of the API endpoints needing access to the authentication db, you use bearer toke…

Yeah, there is this classic: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...

Re: Bearer tokens are just awful

#63

Post by mjg59 »

iso1631 wrote: post #54
mjg59 wrote: post #42

Earlier quoted context omitted.

I, as the company paying for your service, have no direct ability to influence the policy that you apply to the tokens you issue. If you start issuing tokens that are good for decades, I have no trivial mechanism to detect that.

Ask before you spend the money, stick it in the contract. If you don't like the answer don't sign the contract.

There's no universe where a typical tiny customer is going to be able to impose policy on a large vendor, and there's just not that many vendors in this space. So, yes, I could go with "We're not going to use Github or Gitlab or any similar vendor because they don't meet our needs in this respect" but then I'm probably going to spend a bunch of time explaining to my board why we're reimplementing issue tracking and CI and that's likely to be some rough chuckles.

Re: Bearer tokens are just awful

#64

Post by Sirened »

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 laptop getting stolen (even if you in theory could).

Re: Bearer tokens are just awful

#65

Post by mjg59 »

iso1631 wrote: post #57
mjg59 wrote: post #44

Earlier quoted context omitted.

You're a 5-person startup. How do you verify that all of Github's token issuance policies align with your needs?

Don't. Run your own. It's a cost of business, you can either rely on the standard terms of your suppliers, or you can supply your own, it's far easier than the vast majority of industries. Git especially is a federated system that has no need for things like github.

Or we could invent better solutions where we didn't need to depend on policies imposed by vendors? The value that Github provides isn't around their git hosting, it's all the integrated features. Reimplementing that isn't going to be trivial - there's a reason so many people use hosted Git rather than doing it themselves.

Re: Bearer tokens are just awful

#66

Post by mjg59 »

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.

Re: Bearer tokens are just awful

#67

Post by mjg59 »

jillesvangurp wrote: post #61
mjg59 wrote: post #52

Earlier quoted context omitted.

And if I compromise a system that possesses one of those JWTs, I can copy it elsewhere and have access to all the resources that JWT grants me access to. You're not tying it to a specific device, and you're not providing a mechanism to verify the device state when making the access decision.

That's why we use expiration times. If I was a bank, I would be using very short expiration times and also use second factors. And have a lot of ceremony around releasing our app. And if I cared enough I would indeed add some claims narrowing down the scope of the token to a device, require our user to wear tin foil hats, and what not. Security measures are proportional to the thing they protect. Plenty of banks use…

I, as your customer, don't control your expiration time. But I, as your customer, would like to be able to apply my choice of policy to tokens that you issue that grant someone access to my data, because otherwise I don't control access to my data.

Re: Bearer tokens are just awful

#68

Post by vbezhenar »

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.

Re: Bearer tokens are just awful

#69

Post by lelanthran »

iso1631 wrote: post #16
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.

How would that be verified? Any information the client sends to the server can be spoofed by another fake client. The stuff which can't be spoofed (say introduced by the network - IP address etc) can changed for legitimate clients (roaming between wifi and 4g for example) Unless you use something like a "trusted" hardware module the client has no access too (which is mentioned in the article), but the article is stil…

> How would that be verified? Any information the client sends to the server can be spoofed by another fake client.

I'm obviously not understanding how bearer tokens work (another user downthread also contends that fingerprint will work, so I'm pretty certain at this point that I have the wrong mental model).

My understanding is as follows:

1. Client logs into gmail/google/facebook/wherever, and gets a signed token-generating-token.

2. Client goes to legit SiteA. SiteA has no access to the token-generating-token granted in #1 above.

3. SiteA pops up "continue with google/fb/etc" and user clicks "continue", at which point google/fb/etc gets a request for a new token using the TGT to authenticate the user.

4. The final-token is returned to the client, and can be sent to SiteA by the client as proof of identity.

5. SiteA can verify final-token with google/fb/etc.

My question is, why can't the token-generating-token (TGT) embed the hashed fingerprint[1], which is generated by the issuing server, and will never be seen by SiteA?

The final-token can use that hash as added entropy into the salt used for the key that signs final-token, because the issuing server will have the fingerprint-hash that allows it to check the signature of any final-token relayed to it.

[1] Browser-fingerprinting may not be totally unique, but it should be good enough (so, you don't include the IP, but the issuing server can figure out what country it is and use that instead.)

Re: Bearer tokens are just awful

#70

Post by danbulant »

zabzonk wrote: post #34
dub wrote: post #9

Earlier quoted context omitted.

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 toke…

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.

If a user decides to logout from certain device, or when you need to log out an active session early
Post reply on HN