With all the hype surrounding Authenticator Apps, I decided to enable the Microsoft Authenticator on my personal Microsoft account. Microsoft describes the Authenticator as “More secure. Passwords can be forgotten, stolen, or compromised. With Authenticator, your phone provides an extra layer of security on top of your PIN or fingerprint.” As a naturally curious security professional, I am constantly trying out new security services and decided to test Microsoft’s claims.
I downloaded the Authenticator app and added my personal Microsoft account to it. The app asked for my Microsoft password and email verification code. Note that both of these are vulnerable to a simple phishing attack. I completed the registration process and logged into my account several times using the Authenticator app to verify that it worked. It did. I could log into my account without a password.
My assumption, after enabling the app, was that no one else could log into my account without me approving it first through the Authenticator app. It goes without saying that no one should be able to register another Authenticator app on my behalf without me approving it first with the Authenticator app that I already have.
So I asked a friend to try to add my personal Microsoft account to his Microsoft Authenticator app. After he entered my email address I got a push notification on my mobile device. I opened the push notification on my device and selected “Deny” to deny him from continuing. But my friend was faster and selected “use password instead” on his phone moments before I selected “Deny”. My friend was then able to enter my password and email verification code and successfully register his Microsoft Authenticator using my account. Microsoft completely ignored me pushing the Deny button and didn’t provide any feedback that a new Authenticator app was registered on my behalf. Microsoft Authenticator would not prevent a criminal from accessing an account once they have obtained a username and password.
After this experiment we were both able to log into my account, each with our own phones. But what happens if one of us chooses Allow and the other chooses Deny? Apparently first to click wins. If the attacker tries to log in and clicks Approve first, the victim can click Deny but it won’t matter – the attacker will get in and once again – no indication is sent to the victim that someone got in.
Where was the extra layer of security that Microsoft Authenticator claimed? While the Microsoft Authenticator app was easy enough to use (as any Authenticator App), is it simply providing a false sense of security?
Using biometrics and push notifications for security purposes should incorporate many additional layers of security resulting in a dynamic, risk-based approach to authentication and authorization. The best systems carefully assess and correlate a host of indicators and variables from the device and the session in real time to validate the user and revalidate if necessary. In the examples above there were plenty of red flags that should have generated alerts and blocked the imposter before access was provided to the device. If you’re serious about device and system security, continuous adaptive risk should be a foundation to your organization’s IT security infrastructure.
Update: I received a few comments on whether 2FA was enabled or not in my tests above. This is not the point I was trying to make here. Even when 2FA is enabled, attackers can still choose to use Email or SMS as a second factor instead of the Microsoft Authentication App. Both Email and SMS are much weaker in terms of security. I’ll follow up next week with a post explaining how SMS and Email 2FA can be bypassed. My expectation is that once I enable an Authenticator App, attackers should not have an easy way of using SMS or Email instead to login or register another Authenticator App.