A Less Than Ideal Way To Do 2-factor
probably just shouldn't use cell networks for 2-factor
I have concerns with how Duo does phone two-factor authentication and think we can all learn from the way Google does it.
The issue:
- If a user has their password compromised it’s easy to convince them to authenticate a 2-factor request without doing anything that would set off a red flag. This is due to the specific way Duo does phone call authentication.
Attacker required information:
- User password
- Phone number
The attack:
- Threat actor compromises a password
- Threat actor uses OSINT to determine victim’s phone number based on the last 4 numbers that duo discloses in the 2-factor login.
- Threat actor calls the victim and uses any facade to convince a user to merge a call (transferring between departments, bringing manager to the call, verification call to verify phone number (My phone carrier has done this))
- Threat actor send two factor phone request and user merges the call.
- Threat actor (not user) presses a key to authenticate the 2-factor request.
Why this works:
- User only needs to be convinced to merge a call- this will probably not set off a red flag since it’s not a probe for more information.
- Duo does not tell the user what is being authenticated that would set off any red flags
- Duo accepts input before the the push call explains the context of the call
How to fix this:
- Full disclosure of the context of the call before accepting user input ex: “You are authenticating for user@account.com. If you were not expecting this call please hang up now otherwise press any key after the beep”
- Switch to the method Google uses: Give context for the call and give the users a token to type in. This gives a user more time to realize something is wrong
Read other posts