Pattern-Matching Authentication
Why the current system is vulnerable
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).
Where users are affected
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.
Whatâs the solution
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.â
Related topics + references
-
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.