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

91–100 of 148 posts

Re: Bearer tokens are just awful

#91

Post by joshstrange »

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.

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

What commonly used authentication method doesn't have this exact same issue? Storing the U/P (which is terrible for other reasons) has the same issue. Using sessions has the same issue. Using API keys has the same issue. What auth method are you using that is somehow tied to the device that can't be trivially spoofed?

Re: Bearer tokens are just awful

#92

Post by dismantlethesun »

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.

Isn't this issue also present with other popular authentication systems like cookies and client side certificates? If you have a key, you can access the system. If you can copy the key, you can access the system from another location. It's simple as that.

People keep asking to have super smart locks that somehow recognize stolen keys, but how can they?

Re: Bearer tokens are just awful

#93

Post by [deleted] »

Sirened wrote: post #79
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.

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

[deleted]

Re: Bearer tokens are just awful

#94

Post by spacemanmatt »

mjg59 wrote: post #67
jillesvangurp wrote: post #61

Earlier quoted context omitted.

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.

In the bank's server, the data might be about you but it does not belong to you. The best you can get is a copy. Regulations control what the bank may publish about you without consequence but the implementation is their purview not yours.

Re: Bearer tokens are just awful

#95

Post by spacemanmatt »

Another "JWTs are awful" post that fails to coordinate cookies, browser security policy for cookies, and JWT expiry into the coherent security apparatus that many of us use without problems or fanfare.

The anti-hype against JWTs is unjustified.

Re: Bearer tokens are just awful

#96

Post by spacemanmatt »

mormegil wrote: post #62
xnorswap wrote: post #31

Earlier quoted context omitted.

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

Long-time fan of joepie. Worth a follow.

Re: Bearer tokens are just awful

#97

Post by mjg59 »

joshstrange wrote: post #91
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.

> 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. What commonly used authentication method doesn't have this exact same issue? Storing the U/P (which is terrible for other rea…

Hardware-backed client certificates.

Re: Bearer tokens are just awful

#98

Post by spacemanmatt »

mjg59 wrote: post #42
iso1631 wrote: post #33

Earlier quoted context omitted.

So I have a service using openid and I use google to authenticate the person logging in. I do that, then that's done. Now I could simply issue a session cookie, or a permament cookie, to the client so we never have to use google again. Or I could make it so that cookie lasts 10 minutes before reauthentication. I can use a refresh token which means they don't need to reauthenticate but if google expires the connection…

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.

> I, as the company paying for your service, have no direct ability to influence the policy that you apply to the tokens you issue

a) why would you want that burden b) you're never gonna get it

Re: Bearer tokens are just awful

#99

Post by mjg59 »

dismantlethesun wrote: post #92
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.

Isn't this issue also present with other popular authentication systems like cookies and client side certificates? If you have a key, you can access the system. If you can copy the key, you can access the system from another location. It's simple as that. People keep asking to have super smart locks that somehow recognize stolen keys, but how can they?

Approaches that use asymmetric crypto have the advantage that you can use keys that can't be copied - if only the TPM or secure enclave has access to the key, I know that the only copy of the key is on the device.

Re: Bearer tokens are just awful

#100

Post by aaomidi »

I legitimately don't get the point with all of this.

At the end of the day it's stored the same way on the client side. For any large service you need to have a database call anyway.

Why is there so much written about effectively the same strategy?

Post reply on HN