Threat model:

Malicious user gaining physical access to browser cookies (e.g., 3rd party repair guy copying cookies to his own device or something like that). Let's say legit user did not clear cookies beforehand.

Possible mitigation:

Pre-authorize user device:

  • Get user's browser signature via JS and save it in a db for later use (dbCopy). This is done by an "admin" account physically present in the device before a "regular" user can use it.

Now in every HTTP request of the user, the web app will:

  1. Get browser sig via JS (currentRequestSig)
  2. Set cookie hash = hash('sha256', currentRequestSig + randomToken) in user's browser
  3. Store copy of the hash and currentRequestSig in the app's db
  4. Get the cookie hash
  5. Make sure the associated currentRequestSig of the cookie hash is the same as dbCopy
  6. Make sure hash is not yet used before
  7. Mark hash as used in db
  8. Delete hash cookie

✓ Browser is verified at this point, user can proceed with using the app

Threats mitigated

  • If malicious user copies the cookie hash to his device, it will not work because of browser sig mismatch. This assumes browser sig is hard to replicate.

  • If malicious user disables JS, effectively disabling steps 1-3 (an HTTP requests therefore begins in step 4 with a copied cookie), the cookie he copied will still not work because it's already used before (step 6 will invalidate it).

My question is, is this a viable solution to mitigate physical cookie theft, or is it overkill and I am missing something?

  • You are trying to defend against an attacker that already has user or even admin privileges. That is going to be tricky if there is no hardware security approach involved, but that would be infeasible in a web context. Here, a fault is that the JS can't be trusted by the server. Attacker could manipulate browser to create a predictable signature, then terminate session to force new pre-authorization? Even better, currentRequestSig can be obtained remotely by any website that the browser visits…
    – amon
    Commented Jan 19, 2021 at 7:13
  • The Brave web browser is developing a feature to randomise the browser’s fingerprint. Some privacy extensions to other browsers do similar things. Do you want to break your website for privacy-aware users?
    – Mike Scott
    Commented Jan 19, 2021 at 7:23
  • @amon This assumes that pre-authorization code was done by an "admin" account so it can't be done by the malicious user. Not sure why currentRequestSig being obtained by any website will affect this though?
    – IMB
    Commented Jan 19, 2021 at 8:00
  • @MikeScott This app is actually an internal app, not made for general public use.
    – IMB
    Commented Jan 19, 2021 at 8:03
  • I think part of the problem in this discussion is that it's not entirely clear what messages are sent when in your protocol. E.g. the hash is generated in the browser, but also stored in the server's DB, and can only be used once. Drawing a diagram would clarify this for you.
    – amon
    Commented Jan 19, 2021 at 9:26

1 Answer 1


This is almost useless for preventing cookie theft. You are relying on a non-secret property of the browser (every site you visit knows your browser signature) to attempt to provide security. This will just not work. All this will do is force the person copying the cookies to carry out one more step1: Grab a copy of the browser fingerprint as well. Remember that JavaScript on client side can not only be disabled, it can be modified too. The attacker can now simply replace the currentRequestSig function with one that will always return the victim's browser signature.

1This assumes there is some rate-limiting implemented server side which prevents simply bruteforcing the browser signature.

  • Isn't the scenario you describe mitigated by step 6 above?
    – IMB
    Commented Jan 19, 2021 at 8:05
  • @IMB No, it isn't. Once the attacker has the browser fingerprint, they can create a new hash by appending a new random token and hashing it.
    – nobody
    Commented Jan 19, 2021 at 8:11
  • What if the random token in step 2 is a random secret provided in the server side that the attacker can't just generate on his own?
    – IMB
    Commented Jan 19, 2021 at 8:18
  • 1
    @IMB What stops the attacker from requesting the random token from the server?
    – nobody
    Commented Jan 19, 2021 at 8:19
  • 1
    @IMB The only thing different about the unauthorized device is that it has a different browser fingerprint. Since the attacker has obtained a copy of the authorized fingerprint, they can present the server with the stolen fingerprint instead of their own, and the server won't be able to tell the difference between the devices.
    – nobody
    Commented Jan 19, 2021 at 8:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .