Push notifications with simple approve or deny buttons are not secure enough for less savvy users. It can even trick more experienced professionals. I believe the vulnerability here is called MFA fatigue, in which a threat actor would spam a user with login prompts until the user chose to approve them. The user assumes there was some bug with the system and got tired of clicking deny, or clicked approve by mistake. The user might also click approve if the actor times their attack when the user is likely to unlock their vault to start their work day (around 8 or 9:00 am is standard where I live).
This exploit might occur on a public computer where the user forgot to fully log out of their Bitwarden account, or on a device that was compromised by an attacker.
The flow should be as follows. Device A is the device the user is logging into. Device B is the existing, logged-in mobile device.
- User chooses the “Log in with device” option on Device A
- Notification is delivered to Device B with an approve or deny request
- If approved, user is given a 6-digit code on Device B
- User enters the code into the prompt displayed on Device A
This method mitigates MFA fatigue because the actor is required to prove ownership of both Devices A and B at the same time. It is impossible for the user to complete authentication using only Device B.
In my opinion, this should be the default flow. Individuals would have the option to switch back and only use the approve/deny prompt, available in account settings. It should be an enforceable policy for organizations, e.g. “Require pattern-matching” under “Passwordless Login.”
Here’s a link to a Microsoft blog on MFA fatigue mitigation: Defend your users from MFA fatigue attacks - Microsoft Community Hub.
Bitwarden’s own September Vault Hours, recently released on Youtube here: Bitwarden Vault Hours: September 2022 - YouTube, featured a segment talking about the issues with accept/reject authentication prompts. Minutes 10-12 cover the important parts of the attack.
I believe the above (steps 1-4 under “What’s the solution”) is a similar flow to Apple’s 2-step verification between a user’s trusted Apple devices. Apple also includes some metadata about the request in their approve/deny step where they show the user the estimated geo-location of Device A. I’m not sure if that’s a necessary addition for Bitwarden.