Comment by lelanthran | Hacker News Reader

Comment by lelanthran | Hacker News Reader

Parent Full thread

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

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.

that's not how it works. the step 4 should be more like: the continue button forwards the client with temporary code (usually in query string), that can be used to request token, with combination of additional secret token (that should remain private/secret), by backend application.

the client never sees the final token, unless the SiteA returns the token to the client, or the exchange of the code happens on the client side. in both cases these are the definitions of incorrect implementation, as the exchange should take place in the backend.

in most implementation you can/should send additional parameters like `nonce` or `state`, which can/should be used to protect against reply/forgery attacks.

Nonce always raises an eyebrow -- In the UK it's a term for child-sex offender ("not on normal courtyard exercise")

Here it means "number used once". Jargon is context-sensitive that way—and we're discussing cryptography, not the UK's legal system.

Reply on news.ycombinator.com