Some of our users on our website have two or more accounts they use to log in. With each device they log in a specific device ID is generated. This device ID is stored on the device itself and on the server. We use this device ID to confirm whether the device needs to fill in a 2FA code or not. If we don't recognize the device ID, they must fill in their 2FA code. A device ID is 1 on 1 coupled with an account right now. So when a user logs out and logs back in with the same account, they won't need to fill in their 2FA because the device ID would match. After two weeks, the device ID times out, and we ask for a 2FA code again and send a new device ID to be used.

However, when a user logs out and logs into a different account, the device ID is not recognized with this user. The server sends a new device ID to be used to authenticate the user and a 2FA code is asked. Some users switch a lot with their accounts and have complained about needing to fill in their 2FA all the time.

But what I am really worried about is whether it's safe to keep a whole list (depending on amount of accounts they logged in with) of device ID's on the client side. If the device somehow got taken over, these IDs could be read and used to skip the 2FA. This time not for a single account, but multiple accounts. But then again, if a device got taken over, there are probably bigger issues to be worried about.

I feel like I am overthinking this issue.

1 Answer 1


It's probably best to ask the user what they want to do, after they sign in (including 2FA if needed). In particular, offer the ability to:

  1. [Default] Forget the other account on this device (requires 2FA for it when they next sign in)
  2. Remember both on this device (neither will need 2FA in the future, for the usual time period)
  3. [Optional] Combine accounts such that either one can be used to authenticate the other (also requires authenticating the other account at the same time).

You can of course provide suitable advice warnings about the risks (option 1 is default behavior and what you should always use with a public computer, option 2 is for shared computers where people mostly trust each other but if you don't want to let others bypass 2FA for your account you need to explicitly sign out, option 3 [if offered] is for the same person with multiple accounts, and shouldn't be used with anybody else you don't trust in the "joint account" sense). Ultimately, though, the decision is already in the user's hands - they could use different browser profiles, or different OS user accounts, or different browsers, or a shell script that swaps out the cookie/local storage DB on demand (which is basically a hack for browser profiles, of course), or whatever - so the goal is accommodate their needs without making other users less safe.

For the technical details, it depends a lot on how you remember devices. If it's an opaque token per user, you'd need to adjust the storage format to either tolerate a list of tokens or store multiple tokens in different records (e.g. prefixed with a user ID) and send the appropriate one (or all of them, e.g. if they're stored in cookies, and let the server sort it out), or you need to update the back end such that a single opaque token can refer to multiple users. That last option shouldn't actually be hard; presumably each user can have multiple devices already, so if you store a unique token on each (instead of reusing the tokens, which shouldn't be possible because they should be hashed in the DB) then you need a table of token:UID mappings, and if you remove the constraint on uniqueness of the token, one token can map to multiple UIDs). If you instead use JWTs or similar signed tokens, you can easily mint a new token that is valid for multiple parties (does require updating the server to handle this case, but should be easy).

With all that said... consider switching to (or at least offering) a better 2FA method. Webauthn supports a wide range of authentication agents; it's perhaps best known as a way to use security tokens like Yubikeys, but it can also be used with biometrics and/or platform authentication (e.g. Windows Hello on Windows, TouchID/FaceID on MacOS/iOS, fingerprint or device lock code on smartphones, etc.). These are generally sufficiently low-effort that the cost of using them, even every time you sign in at all, is not a problem. If you're "sending" a 2FA code through anything other than a push notification, that's probably either SMS (not very secure) or email (widely varying security, although usually acceptable these days).

You must log in to answer this question.

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