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

81–90 of 148 posts

Re: Bearer tokens are just awful

#81

Post by jillesvangurp »

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.

Well, if you are a paying customer, of course we'd be happy to address and accommodate your wants, needs, fears, etc. in exchange for the appropriate fee. Otherwise, sorry, but it just doesn't work that way.

Re: Bearer tokens are just awful

#82

Post by eurasiantiger »

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…

> You could have extremely short expiration but then you're back to having to round-trip to re-authenticate often (or in an auto-refresh situation, one where you're back to checking for expiration yet again).

GraphQL clients like Apollo can solve this by re-authenticating transparently on error and reissuing the same request.

Re: Bearer tokens are just awful

#83

Post by iso1631 »

lelanthran wrote: post #69
iso1631 wrote: post #16

Earlier quoted context omitted.

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

The desire is a hash that doesn't change on a frequent basis, as that's a bad workflow (frequent reauthentication), but one which can't be knowingly cloned

The threat is someone with momentary access to the client machine (either in person or via another exploit) can clone the data.

The server has many things to use for a browser hash, including some stuff that doesn't change very often (you would have to exclude things like screen resolution if you didn't want to reauthenticate your laptop everytime you unplug from a dock for example), but they are all based on information sent by the browser, and thus can be cloned by a process running on the client's machine (even including any Elastic Curve magic ciphers which would be pullable from memory)

The only things that couldn't be cloned would be things not sent by the machine, but instead generated by the network -- IP address etc (network spoofing being a completely different attack, although quite easy to do from a coffee shop)

However using that data would be awful as a workflow as many people will change IP address on a frequent basis

The problem is that with many services, the compromise of a client machine can get a token that never expires. The solution is for the service to require reauthentication periodically.

Re: Bearer tokens are just awful

#84

Post by vlod »

shanehoban wrote: post #60

I recently learned how to use Bearer tokens with a PHP JWT interface and disagree that they are `just awful` (I'm a FE dev for perspective). I have a setup of a 24 hour token that holds the necessary information to authenticate the user's requests (like a PHP session really), along with a 30 day refresh token. My Vue FE detects when a 401 status code is returned (using axios) and attempts to refresh the token. If thi…

Generally the problem is that if your computer gets stolen (or cookie/localstorage etc), the attacker has access to your account for 24 hours. i.e. until there's a check against a disabled-user-list (in the database).

The progression then becomes to reduce it from 24 hours to say 5 minutes (to reduce the attack window, which may or may not be adequate). It then becomes almost the same as validating the user session on each request (not quite, but you start debating if using jwt is worth it at all).

Re: Bearer tokens are just awful

#85

Post by aPoCoMiLogin »

lelanthran wrote: post #69
iso1631 wrote: post #16

Earlier quoted context omitted.

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

that's not how it works. the step 4 should be more like: the continue button forwards the client with temporary code (usually in query string), that can be used to request token, with combination of additional secret token (that should remain private/secret), by backend application.

the client never sees the final token, unless the SiteA returns the token to the client, or the exchange of the code happens on the client side. in both cases these are the definitions of incorrect implementation, as the exchange should take place in the backend.

in most implementation you can/should send additional parameters like `nonce` or `state`, which can/should be used to protect against reply/forgery attacks.

Re: Bearer tokens are just awful

#86

Post by heavenlyblue »

xnorswap wrote: post #49
ptsneves wrote: post #35

Earlier quoted context omitted.

Yes but then you add revocation and you are back at a centrally stored database to check against.

That's correct. There are scenarios where it still makes sense. It's plausible that it would more efficient for some high traffic services to push (the somewhat rare) revocation notices out to endpoints as still being more efficient. For example imagine a whatsapp clone. People send thousands (probably tens of thousands) more messages than they issue password/auth resets. Having the incoming message endpoint maintain…

Actually I never thought about this problem this way, but it seems like in an abstract way the difference between the password and the revocation lists is that of the size of the set:

What is larger, the set of all passwords, or the set of all revoked users?

In most cases the set of all revoked users would be multiple orders of magnitude smaller than the set of of all passwords.

Thanks for writing this message, it made it click for me for some reason.

Re: Bearer tokens are just awful

#88

Post by michael1999 »

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…

Who says authentication needs to stay at the app layer?

Re: Bearer tokens are just awful

#89

Post by iso1631 »

aPoCoMiLogin wrote: post #85
lelanthran wrote: post #69

Earlier quoted context omitted.

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

that's not how it works. the step 4 should be more like: the continue button forwards the client with temporary code (usually in query string), that can be used to request token, with combination of additional secret token (that should remain private/secret), by backend application. the client never sees the final token, unless the SiteA returns the token to the client, or the exchange of the code happens on the clie…

Nonce always raises an eyebrow -- In the UK it's a term for child-sex offender ("not on normal courtyard exercise")

Re: Bearer tokens are just awful

#90

Post by joshstrange »

jillesvangurp wrote: post #45
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.

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…

I've deployed JWT a number of times and you're right, it's absolutely fine. The nay-sayers have some of the worst arguments against it I've ever heard and most can be summed up as "if you implement it badly then you can shoot yourself in the foot"... no shit.

I use short-lived JWTs that can be refreshed with another token (revokable on the server and gives a nice way to present "here is where you are logged in" to a user in their profile where they can easily deauth a "Login Device"). By using JWTs everywhere (web and mobile) it means all my endpoints can easily verify the token, grab the user id, and perform the allowed actions for that user's given role (I use roles, but you could also use permissions/claims though that can ballon the JWT quickly depending on how you represent the permissions/claims).

As long as you use a good crypto algo, don't set your JWT's expiration for a long time, and reject JWTs that have an expiration longer than your default expiration, you are golden.

Post reply on HN