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.
Off on a tangent here, but I think now is the proper time to say that people, when it comes to security, have no idea what’s good for them.
Before Google implemented this cloud sync feature, people were constantly complaining online about how they really wanted their TOTP codes to sync when they got a new phone. Nobody stops to consider the security implications of chasing convenience, but if you stop to warn them, suddenly you’re the bad guy for creating problems or “opposing their solution”.
You need some form of backup though or you can lose access to your accounts if you lose/break your phone. A lot of sites give one time use backup codes but not all, and you still need somewhere secure to store those.
You need to print them out and put them in a drawer. No need to overthink this one,
Same goes for the MFA secrets, just print the whole list.
Yes that exposes you to a whole different type of attacks but they’re a lot more targeted and I would argue that as a functioning adult one has to deal with storing some sensitive physical papers at some point anyway.
This is what crypto wallets recommend you do. I don’t see why that’s a bad solution for backing up.
A note in your password safe is secure enough.
That’s what I do. But now thanks to Google I must change them…
That takes your multi factor and gives it a single point of weakness again, undermining the whole point. If your password safe is compromised, the attacker now has both the password and a code.
I think the problem here was using Google as the account email, the password vault, and the TOTP sync. If they at least had separate services, such as using Microsoft Authenticator for TOTP instead of Google, it would have been harder to compromise everything.
When I was in cybersecurity the most irritating argument someone tried to use to get approval was “everything is hackable nowadays so the requirements are unnecessarily difficult”. They might have had a point if we weren’t talking about HIPAA compliance…
This is like saying every lock is pickable so don’t lock the door at all.
They only way I sync my 2FA codes is in an encrypted json to my own hard drive via a sync app to my NAS.
Can it be exploited? Certainly.
Will I be a target at home? Probably not. More likely at work.
So you went and put all your trusted passwords, 2FAs, FIDO2, and other secrets with Google? Looks like these tech companies are turning into data dragons. Only a matter of time before some adventurers decide to loot the dragon.
I would argue such big companies could be trusted to some extend with storing stuff securely.
You don’t hear much of a data breach from Google.But other other hand you had the Microsoft e-mail incident…
I personally don’t trust them because of the Edward Snowden revelations.
You can trust nothing lol.
The only thing you could trust is a fully air-gapped system you personally update and patch with a manual attached storage (like USB SSD/HDDs) and never ever let it see the light of the internet.The NSA is not a threat to your cybersecurity. If they want information from you they will put you in a van and beat you with a wrench until you give them the password. If the US Govt has decided you are a threat your problems are bigger than if someone can steal your Steam account.
I don’t think it matters what 2fa the target had here, the attackers had him hook line and sinker. The bigger issue is that the attacker new everything about how the company worked internally, including staff. I would not be surprised if this company was already compromised, either from an external actor or internal.
hehe ‘Data Dragons’
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.
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.
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.
deleted by creator
I’ve said this many times before:
Sometimes it is the free things that are the most expensive things of all/in the end.
—Someone/something
Oh, so that’s why it keeps whining that internet access got disabled! I was wondering why something that displays hashes of the current time would need network access.
deleted by creator
Wow that’s an amazing tool, I can’t believe I haven’t come across this one before. Thanks for sharing!
This is the best summary I could come up with:
A security company is calling out a feature in Google’s authenticator app that it says made a recent internal network breach much worse.
The attack started when a Retool employee clicked a link in a text message purporting to come from a member of the company’s IT team.
It warned that the employee would be unable to participate in the company’s open enrollment for health care coverage until an account issue was fixed.
Shortly afterward, the employee received a phone call from someone who claimed to be an IT team member and had familiarity with the “floor plan of the office, coworkers, and internal processes of our company.” During the call, the employee provided an “additional multi-factor code.” It was at this point, the disclosure contended, that a sync feature Google added to its authenticator in April magnified the severity of the breach because it allowed the attackers to compromise not just the employee’s account but a host of other company accounts as well.
“The additional OTP token shared over the call was critical, because it allowed the attacker to add their own personal device to the employee’s Okta account, which allowed them to produce their own Okta MFA from that point forward,” Retool head of engineering Snir Kodesh wrote.
In an email seeking clarification, Kodesh declined to comment, citing an ongoing investigation by law enforcement.
The original article contains 455 words, the summary contains 226 words. Saved 50%. I’m a bot and I’m open source!
And that’s the reason to not use an online authenticator. Just fucking use Aegis or some other FOSS authenticator ffs.
