For compliance reasons, we want admins of a web app to work on it from devices (phones or computers) approved by IT. Or rather, they can work from other devices, but should get logged out quickly, so they won't forget an open session someone else can use.

We want to minimize both false positives (sessions on untrusted devices considered to be trusted) and false negatives, but false positives are more important.

The current plan is to place cookies/local storage on approved devices, and check their presence during requests. But this solution has drawbacks:

  1. The users can copy the browser profile (which includes both) to another device, and I don't see a way to reliably detect this. Solution: we can at least detect if the same cookie is used from multiple IPs at the same time, or add some device fingerprinting. Of course, device fingerprinting is not completely reliable and browser vendors try to make it harder (with good reason!).
  2. Some users clear cookies or browser cache. It's perfectly acceptable if they delete whatever we end up using intentionally, making their device untrusted; but we want to minimize support requests from accidental deletions. To protect against this, we'll use all of cookies, local storage and ETags, and the presence of one will be enough.
  3. Ideally requests from different browsers used on the same device should all be considered trusted, but considering each browser separately is acceptable.

The app is implemented in Rails, though I don't expect it to matter much to the answers.

I considered using physical keys like Yubikey, but this wasn't accepted.

1 Answer 1


You will not be able to find a satisfactory solution.

If a browser tells your servers “I'm trustworthy”, you can't trust that. While it is conceptually possible to bind sessions to particular hardware, browsers do not expose the necessary APIs for that (though WebAuthn and DRM technologies implement parts of this). Even if you bind a session to hardware, this might not convey relevant security properties.

You have correctly noted that credentials, tokens, and keys can be copied to another device (unless they are sealed to hardware in the device, which browsers don't tend to support). You should consider why you really need to prevent this?

  • Do you want to prevent authorized users from circumventing security policies?
  • Or do you want to prevent malware from exfiltrating access tokens?

I assume you're primarily concerned about malware and hackers. But to defend against that threat, it doesn't help that much to know whether the user is logged in on a particular device. Instead, you want to defend against the risk of device compromise by configuring the devices to be secure (for example, by installing updates quickly), and by training users to only use approved devices. Also, you can defend against abuse of stolen device credentials by not verifying that requests come from some “trusted” device (which can be compromised), but by verifying that requests do indeed come from an authorized user.

For trustworthy user authentication, the primary concern typically isn't device compromise, but phishing. Passwords and one-time-passwords (e.g. TOTP, SMS codes) can be phished. OTPs are a small defense, because they require some user action for authorization, but the codes can still be entered into a phishing site. This is why hardware security keys are state of the art. Through the use of asymmetric cryptography, these credentials cannot be accidentally entered on the wrong site. They are highly phishing resistant. It is quite disappointing that your organization didn't accept Yubikeys (or similar keys from other vendors).

Such security keys are relevant to your original goal because they allow you to bind sessions to hardware. While they don't make it possible to bind sessions to a particular computer, they do demonstrate that the session was initiated by someone who holds a physical key, presumably the authorized user.

You might also add additional checks, such as ensuring that the browsers user-agent string describes an authorized device configuration. However, do not mistake these for security barriers. Everything that the browser sends to your servers can be faked. These are more useful as an anomaly detection and training tool.

  • Of course dealing with malware and hackers is very important, but this particular task is about the "prevent authorized users from circumventing security policies" part. Feb 13, 2023 at 8:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.