8 ms·
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
by jillesvangurp 5y ago
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. Verifiable information, signed by us with our private key, exchanged over https. That's not information the bearer of the token needs to be aware of but it is something our APIs can trivially verify and use as a basis for authenticating the bearer of the token. Pretty neat mechanism. Nothing wrong with it. Used at scale by world + dog on the internet without a lot of issues.
And before somebody starts ranting about JWTs being awful: same argument. They don't have to be but they can might if you decline to use sane crypto. So, use it properly and you're fine. It's not that hard.
- mjg59 5y agoAnd 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.
- jillesvangurp 5y agoThat'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 both bearer tokens and JWTs. Nothing inherently wrong with that. If your require these things, do them. If you don't, then don't.
- mjg59 5y agoI, 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.
- jillesvangurp 5y agoWell, 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.
- spacemanmatt 5y agoIn 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.
- joshstrange 5y ago> 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?
- mjg59 5y agoHardware-backed client certificates.
- julianlam 5y agoSure, 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?
- mjg59 5y agoWhat 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.
- dismantlethesun 5y agoIsn'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?
- mjg59 5y agoApproaches 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.
- nybble41 5y agoThat 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.
- Sirened 5y ago100%! 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.
- mjg59 5y agohttps://github.com/google/go-attestation 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.
- dzhiurgis 5y agoThat’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.
- mjg59 5y agoIP fingerprinting is unhelpful - the user experience for mobile devices becomes terrible. Any other client fingerprinting is easily duplicated.
- dzhiurgis 5y ago> user experience for mobile devices becomes terrible Cant have Your cake and eat it too > client fingerprinting is easily duplicated. Far from it.
- joshstrange 5y agoI'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.