4 ms·

Or you can put device/or ip related info baked into the token. That way when the user device or ip changes, you can invalidate the token.

mjg59 5y ago
Device info is spoofable, and tying it to IP means the phone experience is just awful.
- lowwave 5y ago
  For sure, but then the user assume they know what they are doing. It is to prevent cookie hijacking.
lelanthran 5y ago
> Or you can put device/or ip related info baked into the token. That way when the user device or ip changes, you can invalidate the token. yeah, I always wondered why there isn't a standard field in the JWT containing a fingerprint/hash of the client's machine/browser/etc.
- samarthr1 5y ago
  Advertisers would love such a thing
  - lelanthran 5y ago
    > Advertisers would love such a thing Why? It doesn't give them any more info than they already have (the logged-in user!)
    - sokoloff 5y ago
      It could be used to tie that logged in user to other web sessions that are currently anonymous.
      - lelanthran 5y ago
        > It could be used to tie that logged in user to other web sessions that are currently anonymous. If those other sessions are anonymous, why do they have the token? See, I'm not very experienced in web-dev, and I'm very much aware that I may not know what I am talking about. I'm just trying to understand how the tracking data in the bearer token will "leak". Can you give me a scenario, like "Client goes to SiteA, is then redirected to login on SiteB which grants the token, and then goes to SiteC which reads the token".
        3np 5y ago
        You may have different personas that you want to separate. Ie your identity as a local county representative, your identity with a socialist online forum, your identity as employee, your identity as someone discussing weird sexual kinks. For all you need to identify but you don not want them to be linkable to each other or your government-issued ID. This is part of why relying on phone number validation for gatekeeping is an issue. (Try registering at Discord or Twitter via tor. I'll wait)
  - lowwave 5y ago
    You can hash all that info, so if the user provide the right info (ip, browser string whatever), then the session key would be reconstructed as true.
- iso1631 5y ago
  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 still concerned with compromised machines.
  - Adiqq 5y ago
    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 we can ensure that for our purposes token will expire quickly.
    - mjg59 5y ago
      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.
  - lelanthran 5y ago
    > How would that be verified? Any information the client sends to the server can be spoofed by another fake client. I'm obviously not understanding how bearer tokens work (another user downthread also contends that fingerprint will work, so I'm pretty certain at this point that I have the wrong mental model). My understanding is as follows: 1. Client logs into gmail/google/facebook/wherever, and gets a signed token-generating-token. 2. Client goes to legit SiteA. SiteA has no access to the token-generating-token granted in #1 above. 3. SiteA pops up "continue with google/fb/etc" and user clicks "continue", at which point google/fb/etc gets a request for a new token using the TGT to authenticate the user. 4. The final-token is returned to the client, and can be sent to SiteA by the client as proof of identity. 5. SiteA can verify final-token with google/fb/etc. My question is, why can't the token-generating-token (TGT) embed the hashed fingerprint[1], which is generated by the issuing server, and will never be seen by SiteA? The final-token can use that hash as added entropy into the salt used for the key that signs final-token, because the issuing server will have the fingerprint-hash that allows it to check the signature of any final-token relayed to it. [1] Browser-fingerprinting may not be totally unique, but it should be good enough (so, you don't include the IP, but the issuing server can figure out what country it is and use that instead.)
- mjg59 5y ago
  If someone's in a position to exfiltrate the JWT, they're almost certainly in a position to extract all the information they'd need to reproduce the fingerprint. It'd be a short term strategy until attacker tooling caught up.
- lowwave 5y ago
  >yeah, I always wondered why there isn't a standard field in the JWT containing a fingerprint/hash of the client's machine/browser/etc. Good that you brought it up. That's why I still bake my own verification session system.

mjg59 5y ago

Device info is spoofable, and tying it to IP means the phone experience is just awful.

lowwave 5y ago
For sure, but then the user assume they know what they are doing. It is to prevent cookie hijacking.

lelanthran 5y ago

> Or you can put device/or ip related info baked into the token. That way when the user device or ip changes, you can invalidate the token. yeah, I always wondered why there isn't a standard field in the JWT containing a fingerprint/hash of the client's machine/browser/etc.

samarthr1 5y ago
Advertisers would love such a thing
- lelanthran 5y ago
  > Advertisers would love such a thing Why? It doesn't give them any more info than they already have (the logged-in user!)
  - sokoloff 5y ago
    It could be used to tie that logged in user to other web sessions that are currently anonymous.
    - lelanthran 5y ago
      > It could be used to tie that logged in user to other web sessions that are currently anonymous. If those other sessions are anonymous, why do they have the token? See, I'm not very experienced in web-dev, and I'm very much aware that I may not know what I am talking about. I'm just trying to understand how the tracking data in the bearer token will "leak". Can you give me a scenario, like "Client goes to SiteA, is then redirected to login on SiteB which grants the token, and then goes to SiteC which reads the token".
      - 3np 5y ago
        You may have different personas that you want to separate. Ie your identity as a local county representative, your identity with a socialist online forum, your identity as employee, your identity as someone discussing weird sexual kinks. For all you need to identify but you don not want them to be linkable to each other or your government-issued ID. This is part of why relying on phone number validation for gatekeeping is an issue. (Try registering at Discord or Twitter via tor. I'll wait)
- lowwave 5y ago
  You can hash all that info, so if the user provide the right info (ip, browser string whatever), then the session key would be reconstructed as true.
iso1631 5y ago
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 still concerned with compromised machines.
- Adiqq 5y ago
  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 we can ensure that for our purposes token will expire quickly.
  - mjg59 5y ago
    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.
- lelanthran 5y ago
  > How would that be verified? Any information the client sends to the server can be spoofed by another fake client. I'm obviously not understanding how bearer tokens work (another user downthread also contends that fingerprint will work, so I'm pretty certain at this point that I have the wrong mental model). My understanding is as follows: 1. Client logs into gmail/google/facebook/wherever, and gets a signed token-generating-token. 2. Client goes to legit SiteA. SiteA has no access to the token-generating-token granted in #1 above. 3. SiteA pops up "continue with google/fb/etc" and user clicks "continue", at which point google/fb/etc gets a request for a new token using the TGT to authenticate the user. 4. The final-token is returned to the client, and can be sent to SiteA by the client as proof of identity. 5. SiteA can verify final-token with google/fb/etc. My question is, why can't the token-generating-token (TGT) embed the hashed fingerprint[1], which is generated by the issuing server, and will never be seen by SiteA? The final-token can use that hash as added entropy into the salt used for the key that signs final-token, because the issuing server will have the fingerprint-hash that allows it to check the signature of any final-token relayed to it. [1] Browser-fingerprinting may not be totally unique, but it should be good enough (so, you don't include the IP, but the issuing server can figure out what country it is and use that instead.)
mjg59 5y ago
If someone's in a position to exfiltrate the JWT, they're almost certainly in a position to extract all the information they'd need to reproduce the fingerprint. It'd be a short term strategy until attacker tooling caught up.
lowwave 5y ago
>yeah, I always wondered why there isn't a standard field in the JWT containing a fingerprint/hash of the client's machine/browser/etc. Good that you brought it up. That's why I still bake my own verification session system.