4 ms·

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 introduc

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.)
- iso1631 5y ago
  The desire is a hash that doesn't change on a frequent basis, as that's a bad workflow (frequent reauthentication), but one which can't be knowingly cloned The threat is someone with momentary access to the client machine (either in person or via another exploit) can clone the data. The server has many things to use for a browser hash, including some stuff that doesn't change very often (you would have to exclude things like screen resolution if you didn't want to reauthenticate your laptop everytime you unplug from a dock for example), but they are all based on information sent by the browser, and thus can be cloned by a process running on the client's machine (even including any Elastic Curve magic ciphers which would be pullable from memory) The only things that couldn't be cloned would be things not sent by the machine, but instead generated by the network -- IP address etc (network spoofing being a completely different attack, although quite easy to do from a coffee shop) However using that data would be awful as a workflow as many people will change IP address on a frequent basis The problem is that with many services, the compromise of a client machine can get a token that never expires. The solution is for the service to require reauthentication periodically.

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

iso1631 5y ago
The desire is a hash that doesn't change on a frequent basis, as that's a bad workflow (frequent reauthentication), but one which can't be knowingly cloned The threat is someone with momentary access to the client machine (either in person or via another exploit) can clone the data. The server has many things to use for a browser hash, including some stuff that doesn't change very often (you would have to exclude things like screen resolution if you didn't want to reauthenticate your laptop everytime you unplug from a dock for example), but they are all based on information sent by the browser, and thus can be cloned by a process running on the client's machine (even including any Elastic Curve magic ciphers which would be pullable from memory) The only things that couldn't be cloned would be things not sent by the machine, but instead generated by the network -- IP address etc (network spoofing being a completely different attack, although quite easy to do from a coffee shop) However using that data would be awful as a workflow as many people will change IP address on a frequent basis The problem is that with many services, the compromise of a client machine can get a token that never expires. The solution is for the service to require reauthentication periodically.