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.
Honestly this is why software TOTP is a shitty MFA form for businesses.
Sure it’s free, easy, and pretty much universal…but if you’re gonna MFA as a business, you are better off using hardware tokens, or yubikeys, or even smartcards. If you have to try on an app, it should be limited to work-issued phones so they could be locked the hell down.
The problem with hardware authenticators is compatibility across devices. One job I worked at a while back used Yubikeys, which were great… if you were logging in from your work PC. If you need to access your work email from your phone, that wasn’t really an option without getting an exception made to your account, which required IT doing a manual reconfig of your account. And obviously they were reluctant to do that, because that just opened up more security risks that the Yubikeys were meant to prevent.
Software authenticators are much more convenient for the average user, because getting a code or approving a login via push notification is much simpler and works on nearly any device. And the willingness of the average user is a MAJOR factor in data security. If your security protocol is too difficult for the user, they’re going to develop bad habits by taking shortcuts. They’ll disable security systems, leave their authenticator plugged in even when they’re away from their machine, etc.
Sometimes the less technically-secure option is actually more secure, due to the human element.
Yubikey and other hardware security keys now support NFC which makes the mobile support really good. A quick tap to the back of the phone and you’re done.
deleted by creator
Oh, that’s good to know! It’s been years since I’ve used one, so I don’t think the support was there yet. That definitely relieves some of the problems I had with them, in that case.
Yeah, I had one of the earlier ones Yubikeys without NFC. I remember having to get a USB mini to full USB converter and plug it into that to login to things like LastPass. Thankfully I only needed to do it once for the initial login.
Push notifications are even worst that TOTP codes. Users can just hit accept without thinking, especially if they have gotten used to lots of things asking for it. An attacker can just keep sending requests hoping someone clicks on one of them and then they are in. At least with a code you need to get something from the users first. Hardware tokens with USB-c or NFC like the yubikey can be used on mobiles as well.
I mean that sounds more like a money problem to me. There all multiple different types of yubi keys that work for different types of USB and lightning as well as NFC if you want that. The only reason you wouldn’t be able to use a yubikey on your phone is because you weren’t supplied with a yubi key that works with phones and only the cheapest option with a regular USB A plug.
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.
A combination of software and hardware is needed. I’ve had a yubikey since ~2010. Now I have 3 for different purposes. Mostly to unlock accounts for the first time on a device, then use software for subsequent logins.