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:
- Get browser sig via JS (
currentRequestSig
) - Set cookie
hash = hash('sha256', currentRequestSig + randomToken)
in user's browser - Store copy of the
hash
andcurrentRequestSig
in the app's db - Get the cookie
hash
- Make sure the associated
currentRequestSig
of the cookiehash
is the same asdbCopy
- Make sure
hash
is not yet used before - Mark
hash
as used in db - 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?