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

111–120 of 148 posts

Re: Bearer tokens are just awful

#111

Post by nybble41 »

iso1631 wrote: post #89
aPoCoMiLogin wrote: post #85

Earlier quoted context omitted.

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")

Here it means "number used once". Jargon is context-sensitive that way—and we're discussing cryptography, not the UK's legal system.

Re: Bearer tokens are just awful

#112

Post by mjg59 »

nybble41 wrote: post #106
mjg59 wrote: post #99

Earlier quoted context omitted.

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.

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 key was generated in hardware that it was telling the truth.

Re: Bearer tokens are just awful

#113

Post by mjg59 »

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

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, in that the attestation is still rooted in an immutable key that would allow anyone who performed key attestation with you to associate your identity with a specific computer.

Re: Bearer tokens are just awful

#115

Post by protontorpedo »

I don't understand. Even if you had a cryptographic challenge mechanism to be verified by specialized hardware in the client, if I control the client then I must be able to "poke around in the API" from it anyway. I think your best bet to prevent this is to to detect abnormal client behaviour and block it.

Re: Bearer tokens are just awful

#116

Post by iso1631 »

mjg59 wrote: post #63
iso1631 wrote: post #54

Earlier quoted context omitted.

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

Either github's systems are good enough for you to use, or they aren't.

If they aren't, you need to find or implement something that is good enough.

Re: Bearer tokens are just awful

#117

Post by mjg59 »

iso1631 wrote: post #116
mjg59 wrote: post #63

Earlier quoted context omitted.

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

Either github's systems are good enough for you to use, or they aren't. If they aren't, you need to find or implement something that is good enough.

That is, in fact, what I'm trying to do - this is the explanation for why I'm doing so.

Re: Bearer tokens are just awful

#118

Post by zshrdlu »

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…

Sounds to me like the author is essentially bemoaning a presumed lack of an invalidation mechanism, and thus declares "Bearer tokens considered harmful".

Re: Bearer tokens are just awful

#119

Post by dzhiurgis »

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

Re: Bearer tokens are just awful

#120

Post by mjg59 »

dzhiurgis wrote: post #119
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 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.
Post reply on HN