I’ve created an organization and have 30 paid ‘seats’ for my colleagues. For the organization I’ve set up “TWO-STEP LOGIN” (2FA) as required, but it only gives you a simple checkbox.
However, as a user I can also opt to use “Email” (instead of something like an Authenticator App or Yubikey) as a “second” factor:
I do not consider “Email” a second factor, as it will likely be available on the same device as where you use your Bitwarden tooling. In any case, I want to enforce (either through disallowing some, or only allowing some) the types of 2FA people can use.
How can I enforce specific 2FA methods for my organization members?
Note: most of us will be using Authenticator Apps (like Authy) or YubiKey.
Hmm, I see I tagged my post as a “FEATURE REQUEST”, but to a degree it’s also a “QUESTION” since it might already be possible to do what I want?
Or perhaps the lack of response from the community or team indicates I’ve got a weird edge case situation?
Hi @jeroenheijmans - this is a good question. Currently, you can’t specify the method of 2FA for a user, only that they have at least email two-step enabled.
We do have a backlog item to work on this and allow some specification, but since org users aren’t really org users (and have access to premium 2fA) until they’re confirmed, it creates a chicken-egg scenario where the user needs to enable a two-step solution they technically don’t have access to yet
Thx @tgreer for the response!
Would the chicken-egg scenario be solvable by not giving people access to secrets and management features, until they’ve set a certain 2FA method from a whitelist of options?
But I might not understand how 2FA and organizations interplay? In my specific scenario I just want users to enable something like Authy or Google Authenticator or a Yubikey as their second factor, before they’re allowed to do/see anything in my organization.
The underlying problem to me is that e-mail is not a good second factor. If I could blacklist email as a second factor before someone gets access to my org’s stuff that would also be okay.
Either way: appreciate the feedback and your thoughts, as well as a nice product!
Currently, the access to shared secrets (the ability to decrypt them) happens upon the confirmation step, which is a key exchange and is pretty much the step.
We’re tinkering with ideas on granting ‘temporary’ flags to allow premium or other 2FA selection before that point, but it will involve some fancy URL work, yet to be determined
Clear. Thanks for your update, I look forward to seeing new info when/if you decide to give this priority.
I would also like to see this feature implemented. I have an interest in allowing only WebAuthn (FIDO2) for the MFA option for my organization. At a minimum, it would be nice to state which MFA option was used in the event logs.