5 ms·
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
by mjg59 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.
- 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.