Comment by c22
4 months ago
> Unbeknownst to him at the time, Google Authenticator by default also makes the same codes available in one’s Google account online.
This sounded absolutely crazy to me so I went to open Authenticator on my phone and lo and behold it offered me the option of linking to my account and "backing up my codes in the cloud" to which I declined.
But I had never seen this behavior before, so is this new? It did not seem to be enabled by default in my case.
What's crazy to me is that Google would allow access to a foreign device from a single click. It would be easy for a person to accidentally click it, or for a kid playing on their parents advice to click it when it popped up. I really can't understand why they wouldn't send a code that would have to be entered instead; it would be far less prone to those kinds of problems.
"foreign device" based on IP geolocation is pretty tricky and annoying.
My home in Texas had an IP address which a lot of databases had as supposedly being in Montreal. It was like that for years. Gotta love so many sites trying to default to French.
As a network admin I have found that whitelisting only US address space for my companies IPs drastically reduces how many attacks we get.
7 replies →
How would a code help? The victim has already bought into the social engineering. If the person on the phone asks the user to read out a code, they will. If the person on the phone asks them to enter a code (i.e. the version of this kind of prompt where the user needs to enter a code on the phone matching the one showing on the login page), they will.
Every step you make someone who is being socially engineered jumo through, is an extra chance for them to realize what is happening, especially if those steps contain warnings.
Google only added this feature recently. I am really conflicted about this feature. Without it you need to either save every TOTP code when you first set up the account or manually disable 2FA on every account and then enable it again so you can enroll it on a new phone. I used it when migrating to my most recent cell phone but then disabled it. Of course you have to trust that Google actually deletes the codes from your account.
Same with me, I had setup MFA using Google Auth for an important account I use.
Next day the phone broke, and I lost that account forever. I had not written the backup codes down anywhere.
Generating and storing your passwords, OTPs, and passkeys in a fully E2EE system like 1Password is effectively a root of trust, although you also have to trust (a) the password manager company, (b) whatever third-party systems and devices they use to build and deliver their software, (c) the quality of their cryptosystem, and (d) whatever device you use to decrypt/access secrets in your vault.
I trust 1Password. They are very open about how they encrypt data and how the key is derived. I like how they store your encrypted data locally in a SQLite DB. My only real concern is with storing passkeys because they cannot be stored locally yet and you are granting 1Password control over your access to any site you need a passkey stored with them. They are working on a passkey exporting process. I would feel better if I could have the same Passkey stored by 1Password and Azure and Google.
12 replies →
Yup. If you DON'T have this feature, you're depending on every user who has TOTP 2FA to actually save their backup codes somewhere they can retrieve ~years later or back up their TOTP some other way manually. Naturally, most users will fail to do this, so you'll have to deal with how to securely reset the accounts of people whose phones got lost or destroyed.
But then if you DO have it, you have to deal with the situation in this story, where if you can compromise their one key account, you get all of their TOTP codes too.
There is a big gap in the greater security landscape here. I personally use hardware authenticators for this reason, but I have to manually enrol each security key for each account.
Really what I would like is a root of trust which maybe is a cipher text which I can store in several physical locations, and then my security keys are derived from that root of trust. Then when I set up 2fa with a service it is using the root of trust and seeing that my security keys are is derived from that root of trust. This allows me to register the root of trust only once and then I can use any key derived from it.
Some cryptocurrency hardware wallets such as Trezor's are usable exactly how you want: they support fido2/webauthn and derive their keys from the recovery seed phrase. You can write down the recovery seed phrase, initialize other hardware wallets with the same recovery seed later on, and they will present to a computer as the same fido2/webauthn token.
If it's hardware it can break or be lost or stolen.
1 reply →
Just checked and Google authenticator seems to be synced to my account, which is a huge SPOF and not what I want. It's possible that I did this without realising, but does anyone know of a way to revert authenticator to local-only? I don't see anything obvious.
> It's possible that I did this without realising
IIRC on my platform, when they added the feature they turned it on by default, as an auto-installed update.
And if you're logged into the gmail app on the same device that also logs you into authenticator.
You didn't do anything wrong.
FWIW, I still remember recoiling in horror when I was asked whether I wanted to sync my Google Authenticator stuff.
I remember getting prompted for it on iOS when they added it. I still have it turned off.
Better option is to not use Google's TOTP app. Use something else
You can't revert, they keys are sent, they have them. They can't un have them. You'll need to rotate your MFA.
> You can't revert, they keys are sent, they have them. They can't un have them. You'll need to rotate your MFA.
Not true. See https://news.ycombinator.com/item?id=42471459
4 replies →
> does anyone know of a way to revert authenticator to local-only?
To answer my own question: tap the profile pic (top right on Android) and choose the Use Without an Account option. Removes codes from cloud storage and any _other_ devices. Mentioned in TFA.
I am literally mind f** by the wording “Use Authenticator without an Account”. This is one of the most tortured and cryptic phrases I have seen. Government legalese is more straightforward than Google.
I use Authy and it does this too. I like that I can get the code on my phone or tablet. I also keep paper copies of the original QR codes in a safe place.
The trick with Authy is to disable multi-device access unless you're in the process of adding another device, so hackers and scammers can't add their own devices to your account without your aid. If you leave the setting enabled, someone may get your TOTP secrets from Authy before you can stop them.
If there is a trick to doing something securely, then that is already an automatic fail.
No. That's not "the trick". As soon as it's in the cloud, it's over, it's gone, you've lost the game.
2 replies →
You can just decode the QR code and use whatever secret is in there to generate the OTP codes. TOTP isn't that complicated, it's really just a second password that the system generates.
While true, I haven't yet seen an authenticator app that let's you just dump the topt code yet...
1 reply →
It is at least relatively new. Years ago I had to try the Google “hard landing” account recovery process because it wasn’t happening, which is how I learned that they had that form going to an email address which had been deleted. Fortunately I had paper recovery codes in my safe.
Google rolled out that hare-brained "improvement" in an update to Google Authenticator a few months ago, with the nice extra that for some users, when you dared unselecting the new cloud backup checkbox, the secrets stored in the app were instantly corrupted in some way, so you were locked out of your Google accounts immediately as a bonus <chef's kiss>. Happened to a family member, luckily they had a working emergency access method. We will never use Google Authenticator again.
Recommended alternative: 2FAS (https://play.google.com/store/apps/details?id=com.twofasapp) which allows you to import the secrets from Google Authenticator via QR codes, and has a local backup feature (e.g. to a USB drive).
As a side question: How do I, as a novice, vet a 2FA?
This has all the "looks nice", but I have no reason to trust this recommendation over any other social engineering.
1 reply →
I was one of the fools who installed the iOS 7 beta onto a phone that I depended on with Google Authenticator. The app had a compatibility issue with that beta release that caused it to disappear all my 2FA seeds except, very fortunately, for my Gmail. There was a bit of a ruckus about this here https://news.ycombinator.com/item?id=6112077.
Since then, I always use at least two 2FA apps at the same time.
I used andOTP for years, until the author stopped working on it. While it still likely works fine, I've switched to Stratum, which likewise supports import from the Google Authenticator export QR codes as well as from andOTP, authy, and others.
Ugh, yeah, that update.
You didn't have to do anything, either, the update just instantly corrupted some 2FAs. How can an app not do a TOTP? It's literally just math.
I had to recover a few MFAs from backup codes due to that.
I'm shocked how often one of my ~50 colleagues asks me to reset their 2FA. It's every 6-8 weeks or so.
Their personal accounts will be affected in the same way (lost phone, new phone etc).
Was about to say this but yeah.
Big brains at google didn't understand the number '2' in 2FA
They added this recently, because lots of people complained to Google that they lose their tokens; Authy and others started to gain traction because they did synchronization. Google was pretty much forced.
I know, 2FA loses the entire point when it's synchronized. But, well. People lose their stuff all the time!
I've had customers tell me that they cannot use email verification to meet a 2FA compliance requirement because it's not a second factor, but somehow SMS is. I always push back with "why not just good old TOTP" and the answer is that it's too easy for a customer to lose because it is only on their device. Like yeah... that's what makes it a real second factor.
It’s possible to synchronise secrets without sharing them with a third party: just encrypt them locally, transmit to third party, download to other device, decrypt.
This could be made easy for users by having each device share a public key with the third party (Google, in this case), then the authenticator app on one device could encrypt secrets for the other devices.
This would be vulnerable to Google lying about what a device’s public key is, of course, but enduring malice is less likely (and potentially more detectable) than one-time misbehaviour.
2 replies →
The active ingredient in 2FA as practically implemented for nearly everyone has never been the 2. It's mostly just not letting humans choose their entire password.
Most people wouldn't realise they can't recover their TOTP codes. But the hacker would still need to know your password surely
...so you agree that this is missing the '2' in 2FA?
14 replies →
It's because everybody wants to put everything in 2FA protocols, because people just can't use passwords...
And the fact that one of those doesn't lead to the other passes way over their heads.