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

51–60 of 148 posts

Re: Bearer tokens are just awful

#51

Post by xnorswap »

mjg59 wrote: post #48
xnorswap wrote: post #43

Earlier quoted context omitted.

So you're worried that a very short lived compromise of a SSI / federated auth layer can lead to long-lived compromises of everything it grants access to because a short time can be used to generate long-lived auth to third parties? That's a legitimate concern, any compromise of the SSI needs a complete refresh of anything it's touched, including refreshing all API keys, keyrings, etc. Hopefully as the ecosystem matu…

No, I'm worried that if someone has temporary access to a machine that has one of these long-lived tokens, they may continue to have access to anything that that long-lived token grants access to.

But then there's no third party in that scenario, that's down to whoever was issuing those tokens and is part of securing their service.

Re: Bearer tokens are just awful

#52

Post by mjg59 »

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…

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.

Re: Bearer tokens are just awful

#53

Post by drewcoo »

So logically, that's a lacking thesis. And, in fact, an intentionally misleading one.

That said, I'm a big proponent of zero trust.

My real question from this, though, is who actually does zero trust right? I'd really like to know. I would love to work there and prove it works. Ping me if you do that, please.

Re: Bearer tokens are just awful

#54

Post by iso1631 »

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.

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

Re: Bearer tokens are just awful

#55

Post by mjg59 »

xnorswap wrote: post #51
mjg59 wrote: post #48

Earlier quoted context omitted.

No, I'm worried that if someone has temporary access to a machine that has one of these long-lived tokens, they may continue to have access to anything that that long-lived token grants access to.

But then there's no third party in that scenario, that's down to whoever was issuing those tokens and is part of securing their service.

I control my laptops. I control the policy for my identity provider. The service that hosts my source code is a third party, and defines their own policy which may not match mine.

Re: Bearer tokens are just awful

#56

Post by jillesvangurp »

michaelt wrote: post #29
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.

This is a common problem in enterprise single-sign-on systems. The issue is: If the user presses the 'log out' button, you want it to take effect within a few seconds. But if logouts are simply a timestamped record expiring, they'd have to expire within seconds, and that would basically mean re-authenticating on every single request. And at the same time, some webapps have shitty re-authentication flows (like discard…

It's tradeoff. If you require tokens to be invalidated instantly, there's no way around the notion of doing some kind of lookup when you are validating the tokens. It could be as simple as having a database/memory store somewhere with invalidated tokens or all the still valid tokens. You might cache those for a few seconds so the performance overhead would be pretty minor. You can make this as strict/complicated/slow as you need it to be. It's up to the validating party to decide just how strict they want to be.

But mostly, the device simply deleting the tokens when the user clicks logout is good enough though. Logout does not protect against mitm attacks of course. But that's not what logout is about. And if you have attacks like that going on, the user clicking logout or not does not matter anyway because you can't trust anything they do since you can no longer tell them apart from whomever is attacking. All a logout signals is the user throwing away their tokens (and probably a lot of other local state).

Which is why world + dog uses either tokens that never expire or tokens with expiration times that are pretty long. In our case we use access tokens and refresh tokens. The access tokens are refreshed regularly and the refresh tokens expire after a few months. So, the only users that we force through repeated login procedures are those that don't regularly use our app. Anything more would be annoying. And yes, if their devices get hacked, those users have would have an issue. That's the tradeoff. The user using a token they just threw away is not a real problem because they wouldn't. The user's tokens getting stolen is a different problem. That's why having the tokens expire eventually is a good thing.

Long expiration times are not appropriate if you are a bank for obvious reasons. So, they tend to use expiration times measured in minutes typically and use additional authentication around sensitive transactions.

Re: Bearer tokens are just awful

#57

Post by iso1631 »

mjg59 wrote: post #44
iso1631 wrote: post #38

Earlier quoted context omitted.

That's github's service, before choosing to use it you should look at these policies (who and how github enterprise trust tokens) and see if it matches your needs. If you were running the service, then the power to trust those tokens is with you.

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.

Re: Bearer tokens are just awful

#58

Post by xnorswap »

soco wrote: post #50
xnorswap wrote: post #17

Earlier quoted context omitted.

Isn't the fundamental difference that a password needs checking against a stored per-user value such as password hash and therefore needs a database lookup, while a token can be validated through just the cryptographic signature and therefore avoids hitting the central database?

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 view users and create reports".

Re: Bearer tokens are just awful

#59

Post by mjg59 »

Adiqq wrote: post #32
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…

I also wonder how feasible would be to use TPM. Is it even supported for use from web applications? I'm also don't aware about similar hardware solutions for mobile devices. Another thing, it's mentioned that we don't control how tokens are created by some third-party, but still, we can use something like Keycloak with external identity provider and client in this case would use token from our Keycloak. In that case…

I'm not aware of any web APIs for secure key storage. That feels like something that would be of value, but coming up with a way to attest to the key being hardware-backed is hard to do without privacy impact - you need some sort of intrinsic hardware-tied key to validate that, and then anyone you do that validation with can tie a key back to the intrinsic key and associate accounts. The Trusted Computing Group tried to solve this with Privacy CAs, which were supposed to issue certificates for intermediate keys that could be randomly generated. But nobody's stepped up to run one, so we're left with Direct Anonymous Attestation, which it turns out may not be possible with the cryptographic features that TPMs provide.

Overall, hardware-backed identity is probably viable in enterprise scenarios where you don't have the same expectation that company-owned hardware will respect your privacy, and we don't have a great solution for doing it at consumer level, and that probably impairs our ability to offer any sort of browser-level API for it.

Re: Bearer tokens are just awful

#60

Post by shanehoban »

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 this fails, the user is redirected to the login page.

It works quite well IMO. This setup lets me authenticate cross domain requests without any trouble. I was previously used to doing everything same domain via standard PHP sessions.

Post reply on HN