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

101–110 of 148 posts

Re: Bearer tokens are just awful

#101

Post by fragile_frogs »

ThePhysicist wrote: post #36

I think the article mixes up several different problems. Both cryptographic keys and opaque tokens are "possession factors", i.e. if you have them you can authenticate against a service. Signature-based authentication schemes are mostly used to protect against replay attacks, which are easy to perform with an opaque token as it won't change. That said you can tie both opaque and cryptographic tokens to additional fac…

You can actually securely store a key pair inside of indexeddb by setting extractable to false [1]. You can then get a reference to the key and perform your allowed key usages without JS touching the key.

[1] https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...

Re: Bearer tokens are just awful

#102

Post by julianlam »

mjg59 wrote: post #97
joshstrange wrote: post #91

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

Sure, and you can do that, as long as you realize the corresponding trade-off in usability.

Tell me again how adoption-at-large of PGP encrypted email is coming along?

Re: Bearer tokens are just awful

#103

Post by kmac_ »

It would be nice to see some alternatives, "it's awful" isn't very constructive. From my experience JWTs significantly simplified development: simple model, easy to understand, standardised, easy to "debug". Show me something that can compete.

Re: Bearer tokens are just awful

#104

Post by shakezula »

kmac_ wrote: post #103

It would be nice to see some alternatives, "it's awful" isn't very constructive. From my experience JWTs significantly simplified development: simple model, easy to understand, standardised, easy to "debug". Show me something that can compete.

It’s also not supposed to be the last stop in your security model - it’s supposed to be the first.

Re: Bearer tokens are just awful

#105

Post by mjg59 »

julianlam wrote: post #102
mjg59 wrote: post #97

Earlier quoted context omitted.

Hardware-backed client certificates.

Sure, and you can do that, as long as you realize the corresponding trade-off in usability. Tell me again how adoption-at-large of PGP encrypted email is coming along?

What trade-off in usability? We don't have standardised mechanisms for sites to provision their own certificates, but if we did then this would be entirely transparent to users in a way that PGP isn't.

Re: Bearer tokens are just awful

#106

Post by nybble41 »

mjg59 wrote: post #99
dismantlethesun wrote: post #92

Earlier quoted context omitted.

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.

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.

Re: Bearer tokens are just awful

#107

Post by Sirened »

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.

Revocation is important for SSO and, generally, on corporate systems. When you fire an employee and suspend their systems access, you really don't want a dangling session token to be useable, so you need to support early revocation. The revocation lists will be comparatively very small and so distributing them is less of a challenge. It's mostly just a pain.

Re: Bearer tokens are just awful

#108

Post by Sirened »

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.

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 cannot know or trust that my keys are well guarded because, for all they know, I have a crumby TPM and/or store them unencrypted in my .ssh folder. You cannot make a trust decision based on TPM storage because you have no idea what the TPM actually did (or if aforesaid TPM even _exists_ at all) unless you require remote attestation, which is both non-portable, non-free, and requires you support only users who have a specific variety of CPU.

Re: Bearer tokens are just awful

#109

Post by nybble41 »

jillesvangurp wrote: post #56
michaelt wrote: post #29

Earlier quoted context omitted.

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…

> But mostly, the device simply deleting the tokens when the user clicks logout is good enough though.

The issue with "simply deleting the tokens" is that this offers no way to force another device to log out. You can only log out the device you're using. If you were to lose your laptop, for example, there is no way to go into your account settings and force the laptop to delete its login tokens, hopefully before an adversary can gain access to them—you need some way of invalidating them on the server.

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

If you're okay with invalidating all tokens together then you can avoid storing lists of valid or invalid tokens by tying them to some part of the account state such as a token generation counter or timestamp. The tokens would only be valid so long as that state remains unchanged. Logging out would then consist only of updating that one field in the account.

Re: Bearer tokens are just awful

#110

Post by thwayunion »

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…

> If someone steals your laptop and dumps the secret, that's sure as hell not my problem to solve.

I'm actually curious about the legal situation of stuff like this. Specifically,

1. You issue me a token,

2. that token gets stolen,

3. the stolen token is used to run up a big bill on your service,

4. I refuse to pay that bill (the case being "my laptop was stolen and your service was stolen -- sucks to by both of us, but it's not my obligation to reimburse you for that theft"),

5. You sue me.

What happens? I'm actually genuinely curious, with respect to "stolen services": whose problem is it, really?

What if we insert a new step between 3 and 4 where I tell you the token was stolen, but you choose to accept the token anyways (because eg there wasn't an automated process and the ticket takes a few hours to be resolved)?

(The "you" hear is of course meant to be generic, not Sirened specifically :))

Post reply on HN