Enhancement Request: Authorize TOTP via Yubikey, Windows Hello, etc..

Community Member

Hey Team,

There are a lot of sites that use TOTP for 2FA. It's very convenient to have 1Password enter the TOTP code, but using 1Password to store both the password and TOTP is, well.. not ideal.

This could be improved if there was an option to authorize the use of TOTP via some other 2FA device, eg. a Yubikey, Windows Hello, etc..

While still not ideal, at least if an attacker gained access to a device while 1Password was unlocked, they wouldn't be able to get access to both the password and TOTP without the user intervening.

This would, I think, also require that any viewing/editing of the record would require the master password, Windows Hello, etc.

I'd love to hear your thoughts :)

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided


  • Thanks for the request here. While I can certainly see where you're coming from, I think there's a far easier solution that's being overlooked: keeping 1Password locked when it's not in use. We have an auto-lock function if you feel that you won't remember to do so yourself.

    To be clear, I don't say this to brush off your request. Rather, the request itself sort of falls into the category of double verification, which has been addressed here before. 1Password does a very, very good job of making sure that if it's locked, your data is safe. Assuming that 1Password will be unlocked at the time of an attack should be solved by figuring out how to keep 1Password locked during those times. That way, rather than your Logins and other sensitive data being protected by some form of authentication (as would be the case using something like a security key), it's protected by encryption. We've described why that's preferable here.

    An attacker with full access to your unlocked copy of 1Password would be able to do any number of things, even without being able to access your TOTPs. They'd be able to view your Starter Kit, which contains both your account password and your Secret Key. They'd be able to view your email credentials and potentially submit a request to your email provider to reset or disable two-factor authentication on your behalf by using your email password. They'd be able to download their own copy of your Emergency Kit for later use.

    That's not to mention the danger of leaving your device itself unlocked. Someone with access to your unlocked device, but a locked copy of 1Password, would still be able to do quite a bit of damage. They may be able to install some form of malware. Assuming that you don't manually log out of every website that you visit, they may be able to open your web browser and visit those services using your accounts without the need to use 1Password at all. If you're someone that uses an email application instead of a website, they'd be able to completely delete your 1Password account using access to your email address. Or worse, with access to your email address, they'd even be able to use the "forgot my password" function available through most services to bypass your passwords completely.

    So coming back around to it, I'd suggest setting up auto-lock with 1Password if you haven't done so already. Feel free to make it as strict or as lenient as you care to. I'd also strongly recommend setting up auto-lock at the operating system level on your device, as well. That'll ensure that someone with physical access to your device won't be able to do anything at all, with or without 1Password.

  • somegentleman
    Community Member

    Thanks for your response, I really appreciate you taking the time to write up a detailed explanation.

    I already have auto-lock enabled and my device auto-locks at an operating system level too.

    The SSH Agent operates in more-or-less the same way as what I've mentioned. Whether 1Password is locked or unlocked, it'll always prompt for (in my case) Window Hello authorization.

    From my perspective, this seems almost identical to something like a TOTP, as the secret (TOTP seed/SSH private key) is not revealed to the client, only a time-limited derivative.

    Personally, I like this behavior - I just think it would be nice to extend this to other types of secrets.

This discussion has been closed.