Comment
For personal use, watch out if you use Google Authenticator with sync to the cloud feature. If your Google account is compromised, e.g. you get phished:
-
Your 2FA for other accounts might be compromised as well.
-
If you use the GMail address for other accounts’ password recovery, the passwords for those accounts may be reset/compromised too, regardless of how complex the passwords are.
Question
For personal use, because “Google Prompt” on an Android device is automatically the default 2FA for Google account, can you delete this default 2FA method and just enable a FIDO2 key on Google’s account?
Summary
Google’s Authenticator app, designed for generating Multi-Factor Authentication (MFA) codes, was criticized by a security company called Retool for exacerbating a recent internal network breach. The breach occurred when an employee received a deceptive text message, leading them to share their login credentials, including a Temporary One-Time Password (TOTP), with the attackers. The situation escalated due to Google’s Authenticator sync feature introduced in April, which allowed the attackers to compromise multiple company accounts once they gained access to the employee’s Google account.
This synchronization feature stored MFA codes in the cloud, making them vulnerable if the Google account was compromised. Retool argued that Google employed unclear settings for disabling this feature, making it challenging for users and administrators to prevent. As a result, the attackers exploited this vulnerability to gain access to various accounts, including VPNs and internal systems, enabling them to take over specific customer accounts in the cryptocurrency industry.
Retool’s security shortcomings were also highlighted, as they relied on TOTPs, which can be phished with relative ease, instead of adopting more secure industry-standard MFA solutions like FIDO2. While Google defended its syncing feature, emphasizing its benefits for user convenience, they acknowledged the preference for local storage of OTPs in enterprise environments.
There’s a good argument to be made that Retool used the Google Authenticator issue to deflect attention away from Retool’s culpability in the compromise.
In conclusion, the incident underscores the importance of adopting FIDO2-compliant MFA for robust security, while Google’s Authenticator app is seen as a middle-ground option that may be inadequate for enterprises where security is paramount.
Almost everything has trade-offs.
Personally I’d prefer a combination of methods. Company-owned lockdown phones with certificates for software and biometrics to unlock. Push based number-matching (like MS Auth) on approved and controlled mobile devices for access into the environment.
Hardware pin+digit tokens are a second best, as it’s very easy to train people to be suspicious of anyone asking for their code…but they can be cumbersome to use.
Smartcards can be alright if they are combined into physical access badges so leaving it in your computer can’t really work if you need it to get out of the building/elevator/parking garage. But they can be a serious PITA to administer and a lot of applications don’t support it natively, and a huge burden for users if they have to use it on mobile (or if you order laptops that don’t have builtin readers).
This is my take also, which is don’t put all your eggs in one basket. For my critical systems I typically use a memorized sentence and a key stored on a hardware device that is pin protected. I carry two hardware devices from different vendors with different accounts on each to further limit what can be accessed if any were compromised. If supported, I also use Aegis and Bitwarden (different accounts on each) for OTPs as a third gate.
It can be annoying at times, but its not as crazy as it sounds. I can get access to anything in about 30 seconds.