Flexibility to require hardware based 2FA FOR EACH SIGN IN ?

bitkeeper

I assist Managed clients with basic Opsec as part of our Managed Security Service.

I've run into multiple use cases where there is a legit requirement to make use of Yubikey 2FA FOR EACH SIGN IN. Even if that sign in is on the same day on the same endpoint on the same OS user account. (Or, if a single factor is the only option to use the hardware key vs access that is granted through user entering a password through a keyboard). This is mostly industrial environments where there is shared access to the same desktop and physical security is weakened due to easy access to these endpoints.

This support article mentions extension settings that could be a good start, https://support.1password.com/auto-lock/#manage-auto-lock-in-the-1password-app but the mentioned options are not present for 1PW extension v 2.3.7 ... ?

Also, this would be applicable for both the Binary and Browser Extension sign in. I assume the default synch between extension and binary would take care of this. But currently there is no option to force hardware based 2FA required for each sign in.

Ideally the user should have the flexibility to
1. Force Hardware 2FA requirement for each sign in.
2. Use the Hardware Key as primary factor.

Thoughts appreciated.

---

1Password Version: Not Provided
Extension Version: 2.3.7
OS Version: Mac OS + W10
Browser:_ Chromium brased

Ben

Hi @bitkeeper

2FA serves a different role with 1Password than traditional authentication-based services because 1Password's security is encryption based.

Authentication and encryption in the 1Password security model

The function of 2FA with 1Password membership accounts is to help protect the device authorization process. Once a device is authorized, 2FA is no longer required unless you subsequently deauthorize the device through the web app or the browser/app's locally cached copy of the secret is cleared. Essentially 2FA helps prevent a replay attack from authorizing a device. We did not design our 2FA implementation to help if someone has access to one of your authorized devices. 2FA does not prevent you from accessing locally cached data (e.g., while your device is offline or while we are offline).

The information in this thread may help, but the short answer is it isn't possible to configure 1Password to prompt for a Yubikey beyond the initial device authorization process. I hope this helps clarify why 2FA works the way it does for 1Password.

Ben

bitkeeper

Hi, Ben.

This makes total sense form an engineering point of view. And against advanced threats I absolutely love 1PWs approach focusing on E2E with PAKE + 2SKD to protect content.

There are two aspects that I'd like to bring to the discussion. If I'm missing the point, bare with me. But in the world I move in I believe these are worthy to at least consider.

1. The Human Factor
   Humans are creatures of habit. In onboard technically challenged HVAs I've found the cognitive dissonance in introducing them to a Password Manager + MFA easily reach the point of impracticality for their Opsec. A key way to mitigate this is to create a CONSISTENT security ritual for them that they can follow from a to b to c. Believe me, in some cases it is far better to spend your energy on the WHAT to do than trying to do a skills transfer on the WHY when onboarding an HVA. (This is not the case always, but often is).
   All the security engineering motivation aside, and only focussing on the UX for the technically challenged human: I'd love to have the flexibility to be able to use 1PW in a way that creates a consistent security ritual. (E.G.: Open Browser, Click Extension to unlock, Master PW, Key, go.) This is the single reason that some HVAs had to be migrated back from 1PW to alternative (less secure) PW managers. Which I personally hate doing, but to ensure an effective security ritual as part of their Opsec ended up outweighing the technical benefits of the 1PW E2E first philosophy.

2. Threat Level Factor
   The most advanced lock could sometimes be defeated with a single piece of gum stuck in the latch by an opportunistic adversary (that thinks different than the engineer that built it). Just focusing on the advanced threat that would attempt to decrypt content on the other side of the castle wall might miss the script kitty with a keylogger that has physical access to a shared computer. A replay attack on an authorized endpoint completely defeats the most advanced encryption setup.
   Having authentication (especially a hardware token) as an additional layer on top of encryption adds value to the depth of defence. There is a reason why you de-authenticate a device to become untrusted after a set time, right? Why not give the user flexibility to decide how long that time is? And should they choose to make it zero, so be it. And perhaps even delete the local cached data on sign out... At least they have that option.
   If the 1PW app / webapp refuses to attempt to decrypt without authentication, that forces the adversary to move to more advanced attacks on the data cache. And this might be enough to exhaust their resources. Which ultimately all of us are trying to do.

I guess this is just a long way of saying. Defence in depth. You already have the authentication layer, why not make it possible to put it to more flexible use should a user choose to do so?

Love what you guys are doing.
Keep making the world a better place.

Ben

Thanks @bitkeeper. I'll be happy to share this input with our security and UX teams. One point of clarification I'd add:

There is a reason why you de-authenticate a device to become untrusted after a set time, right?

We do not. Once authorized a device remains authorized until manually deauthorized (or if the secret is cleared through some other means such as wiping the device).

And one rebuttal:

A key way to mitigate this is to create a CONSISTENT security ritual for them that they can follow from a to b to c.

Outside of the initial setup process for each device, this is (or, is expected to be) the experience as-is.

Ben

bitkeeper

Thanks, @Ben

I've run into re-sign in requirements on iOS that needed the physical key and the user did not have it with him (while travelling) since that was not part of his regular opsec security ritual. I might have mis-interpreted the trigger for this coming from 1PW.

Ben

I've run into re-sign in requirements on iOS that needed the physical key and the user did not have it with him (while travelling) since that was not part of his regular opsec security ritual. I might have mis-interpreted the trigger for this coming from 1PW.

Interesting; thanks. If the trigger did indeed come from 1Password it would be worth while to investigate why. If this happens again please have them get in touch so we can troubleshoot.

Ben