With use of multi-factor authentication rising, end-users can find themselves fiddling with codes and authentication apps frequently throughout their days. For those who rely on Microsoft Authenticator, the experience can go beyond momentary frustration to full-blown panic as they become locked out of their accounts.
That’s because, due to an issue involving which fields it uses, Microsoft Authenticator often overwrites accounts when a user adds a new account via QR scan — the most common method of doing so.
But because of the way the resulting lockout happens, the user is not likely to realize the issue resides with Microsoft Authenticator. Instead, the company issuing the authentication is considered the culprit, resulting in wasted corporate helpdesk hours trying to fix an issue not of that company’s making.
The core of the problem? Microsoft Authenticator will overwrite an account with the same username. Given the prominent use of email addresses for usernames, most users’ apps share the same username. Google Authenticator and just about every other authenticator app add the name of the issuer — such as a bank or a car company — to avoid this issue. Microsoft only uses the username.
Making this situation worse is that when a Microsoft overwrite happens, it’s not easy to determine which account is being overwritten. This can cause authentication issues with both the newly created account and the account that is overwritten. Moreover, users can potentially not realize a previously created account was annihilated until they attempt to use it again, whether that’s weeks or months later.
There are multiple workarounds. The easiest is for companies to use any other authentication app. Not using the QR code scan feature — and manually entering the code — will also sidestep the issue, which doesn’t appear to arise when the authenticated accounts belong to Microsoft.
CSO Online found complaints of this problem dating back to 2020, but it appears to have been in place since Microsoft Authenticator was released in June 2016. (For historical context, Google was the first Authenticator app, having been launched in 2010.)
One such complaint in 2020 noted the workaround to manually enter the information, but it was dismissed as not viable for an enterprise audience.
“I believe the fix, sorry, I mean workaround for this is to use the Secret Key from the Identity Provider and manually type this into the Authenticator app during setup,” the user wrote. “Unfortunately, this is not very helpful in an enterprise environment, especially when the average end user rarely knows anything about the inner workings of authentication, and seeing a random string of characters is intimidating.”
‘A big problem with usability and cybersecurity’
This problem got attention recently when Australian IT consultant Brett Randall posted about it on LinkedIn.
In his post, Randall described participating in a recent vendor training session: “As we logged into their system, we were presented with a QR code to scan for MFA. A number of attendees opened Microsoft Authenticator, scanned the QR code, and proceeded to overwrite another application’s TOTP (Time-based One-Time Password) key,” Randall wrote.
“Here’s how it should work and how every other authenticator app out there — Google, Okta, etc. — work. When you scan a QR code for MFA, it generates a string with a series of values. Other apps take two of these values — the label and the issuer — and join them together to form the unique ID for that key. Microsoft, on the other hand, ignores the standard and just takes one value — the label. And that’s typically your email address. Which means, Microsoft Authenticator will overwrite the last TOTP key that used the same email address. This can be disastrous.”
He added: “Watching a room full of people lose access to other systems as they gradually scanned a QR code and Microsoft Authenticator overwrote their keys to other systems was painful. But trying to get Microsoft to recognize the issue and do something about it? That’s been nigh on impossible.”
“If you haven’t picked an authentication app, why would you pick Microsoft?”
— Tim Erlin, VP of product at Wallarm
CSO Online contacted various other security and IT specialists and asked them if they could re-create the problem. They all could.
“The help-desk burden is not trivial. This is one where I think it’s a design flaw,” said Gary Longsine, fractional CTO at IllumineX. “As far as recommending the app, this would prevent me from using Microsoft Authenticator. I wouldn’t recommend it to anyone for that reason.”
Tim Erlin, VP of product at Wallarm, said, “Users will be locked out and will need to get back in. Once you add one entry that is using the email address, the second entry will conflict. And once you have overwritten, you won’t know which one was overwritten.”
He added, “It’s possible that this problem occurs more often than anyone realizes because [users] don’t realize what the cause is. If you haven’t picked an authentication app, why would you pick Microsoft?”
Erlin speculated that this problem initially happened because of an historic disconnect between security engineers and end-users. “This is a small example of a big problem with usability and cybersecurity. This is what happens when apps are developed by engineers who don’t have a strong knowledge of customers,” he said, adding that Microsoft hasn’t bothered to fix it because Microsoft Authenticator is a free product and therefore doesn’t generate revenue.
David Meltzer, chief product officer at Netography, re-created the problem and found it disconcerting. “I tried this to experience it myself. It is clearly a bug. It is a fairly straightforward thing [for Microsoft] to fix. Every other authenticator can handle it.”
Asked for comment, Google spokesperson Kimberly Samra wrote that “it’s correct that we don’t overwrite codes. That was an explicit decision.”
Microsoft says users, issuers to blame
Microsoft confirmed the issue but said it was a feature not a bug, and that it was the fault of users or companies that use the app for authentication.
Microsoft issued two written statements to CSO Online but declined an interview. Its first statement read: “We can confirm that our authenticator app is functioning as intended. When users scan a QR code, they will receive a message prompt that asks for confirmation before proceeding with any action that might overwrite their account settings. This ensures that users are fully aware of the changes they are making.”
One problem with that first statement is that it does not correctly reflect what the message says. The message says: “This action will overwrite existing security information for your account. To prevent being locked out of your account, continue only if you initiated this action from a trusted source.”
The first sentence of the warning window is correct, in that the action will indeed overwrite the account. But the second sentence incorrectly tells the user to proceed as long as two conditions are met: that the user initiated the action; and that it is a trusted source. In almost all relevant situations, both would apply. The user did indeed initiate the action (as opposed to a cyberthief trying to break in) and the site (such as a bank or hotel) is trusted.
Therefore, a user following those instructions would proceed and overwrite the accounts. It’s also worth noting that the message offers no means of not overwriting the account, other than abandoning the entire authentication effort. Users following the instructions would experience the problematic overwrite.
A few days after its initial response, Microsoft unprompted sent a different statement. The second one was much longer, blaming issuers:
“When you scan a QR code, the Authenticator app uses a label given by the vendor to set up your Time-based One-Time Password (TOTP) account. However, some sites or vendors don’t include the issuer — the site name or Identity provider name — in the label. This may result in a situation where a user may already have an account with the same label and the app attempts to overwrite the existing TOTP account with the new one they are scanning. In situations where a user has an existing account with the same label, users are always presented with a message prompt to confirm overwriting an existing TOTP account in their app and can make a conscious choice to proceed or not. We are always working on enhancing our products and will take this into consideration and apply it to future improvements.”
That last sentence is the only indication we have seen from Microsoft that it might fix the issue.
As for the actions of “some sites or vendors,” Randall said there are a limited number of ways to resolve this situation.
“It seems there are two options here to avoid end users accidentally overwriting other apps’ keys. We audit every application’s otpauth and go through the hassle of trying to convince every company doing it ‘wrong’ to fix it. Or Microsoft fixes this once and then we never have to worry about it again,” Randall said.
“By the way, I’ve tested this behavior in 14 other authenticator apps so far. None of them exhibit the same collision behavior that Microsoft Authenticator does,” he added. “I gave up at 14 because at that point, it’s obvious Microsoft are the ones who are doing things poorly here.”
Randall listed the apps he tested: Google Authenticator by Google; Okta Verify by Okta; Duo Mobile by Duo Security; LastPass Authenticator by LastPass; 2FA Authenticator (2FAS) by Two Factor Authentication Service; Twilio Authy by Authy; Salesforce Authenticator by Salesforce; OneAuth by Zoho; ForgeRock Authenticator by ForgeRock; Authenticator 7 by SMM Service; Authenticator App by 2Stable; Auth0 Guardian by Auth0; OTP Auth by Roland Moers; and Authenticator 2FA Sentinel by Tommaso Carpi.