Hacker News new | past | comments | ask | show | jobs | submit login
Google Authenticator now supports Google Account synchronization (googleblog.com)
468 points by ortusdux on April 24, 2023 | hide | past | favorite | 333 comments



Ahem, I think making it much easier to transfer and backup 2FA codes is extremely important to make this area more useable. But I'm missing some parts here in this announcement how the data is protected? Is the security the same as for the Google Account itself, or are there additional checks or protection for the case where you need to restore 2FA to another phone?

And how are you supposed to handle the 2FA for your Google account? I mean I have U2F tokens which remove that concern, but that is far from the typical case. If you have the 2FA for your Google account in the Google Authenticator, which is probably a very common case, how does this entire thing work then when you need it, which is when you lose your phone?


> And how are you supposed to handle the 2FA for your Google account? I mean I have U2F tokens which remove that concern, but that is far from the typical case. If you have the 2FA for your Google account in the Google Authenticator, which is probably a very common case, how does this entire thing work then when you need it, which is when you lose your phone?

You open your safe and you use one of the recovery codes that you wrote down when you setup 2FA.


> You open your safe and you use one of the recovery codes that you wrote down when you setup 2FA.

HN rarely does humor, but when it does, it really cuts deep.

Can you really expect a typical person - including the tech-savvy ones - to keep a hastily written piece of paper for a decade or more, without losing it? My code card is clocking on a decade, I needed it only once (so far), and it's only pure luck that, in all those years, I haven't accidentally destroyed it or thrown it away.

Also: it only recently became apparent just how bad it is to lose access to your Google account. Most tech-savvy people I know don't even realize how many things in their lives are gated by that little login form. Non-tech-savvy folks? Maybe they'll figure it out in a decade, after enough people became thrust into poverty for the lack of Google 2FA recovery codes - enough many that it's as boring news story as car accidents.


Where do you keep your passport, if you have one? Your birth certificate? Any other important papers you have?

No, it's not reasonable to expect everyone to be well organized. Life can be chaotic. People lose stuff. We know this. Some people are so unfortunate as to lose all their stuff. Repeatedly. The level of organization people have varies extremely.

But I do expect there are hundreds of millions of typical people with houses and sufficient organization to hang onto to their important papers, and it's a good idea to add your backup codes to your other important papers. It's good advice, though not always applicable.


> Where do you keep your passport

Honestly, losing my passport probably wouldn't be as big a deal as losing access to my Google account.


Absolutely. Primarily because a passport comes out of process mediated by multiple humans for whom that is their only responsibility. It's a matter of few hundred dollars and a couple weeks to replace it.


I don’t know about replacement but there are lots of delays currently for US passports:

> The processing time for routine applications is taking from 10 to 13 weeks up from six to nine weeks for those who applied before Feb. 6, the State Department said.

> Expedited processing, which costs $60 more, is taking seven to nine weeks, an increase from three to five weeks.

https://www.axios.com/2023/04/24/passport-delays-2023-proces...


That's pretty absurd and definitely not how long it takes in all countries - but still probably quicker than recovering a Google account which you might not be able to do at all.


In Spain, renewing the passport is very fast and cheap!


All those important papers have recovery processes. It might involve a judge or signing documents in front of stern officials or having friends and family vouch for you, but governments and financial institutions and telcos can do it because they have to. Because life happens, and we can't always control it. But for online services, with no responsibility of care, it is easier to just lose customers than provide robust processes and accept the responsibility of letting you prove who you are. You can be homeless and ID less and still bootstrap all the important stuff, except your email and all the things that require email for recovery.


This is pure speculation and not practical advice, but if you were trying to get in to your accounts from a 'starting from nothing' situation, I wonder if you could get a passport etc. and then make a GDPR request for your data from google?

Obviously you wouldn't be able to get in to your account to use google's built in tools because you wouldn't have access, but if you sent a letter to their legal team with proof of your identity then they would be obliged to process the request by law (as I understand it).


This might (should) get you your data but that data won't include your passwords which (presuming basic competence) Google doesn't store. This means that you are still locked out of many things. The data might also not be in a format useful to laymen and will probably be incomplete in some way, e.g. excluding data you had access to with that account but isn't your in Google's opinon data like shared documents.


Google would need to know that remus@gmail.com belonged to the person making the GDPR request, or it would be an attack vector. From the providers point of view, you are asking for a copy of your data and data about you, and they are not going to give out data that might be yours. Maybe if you had linked a phone number, but even that is arguable.


> Where do you keep your passport, if you have one?

Nearby, 'cause I travel semi-frequently. Otherwise, in one of few designated drawers. I only kind of care, because replacing it isn't hard, just annoying - and I don't need my passport to get a replacement one.

> Your birth certificate?

Wherever. I don't care. If I need it, I can file a form, pay a small amount, and get arbitrary number of copies from the local government branch.

> Any other important papers you have?

The only important paper I store safely is the booklet the military gave me when I turned 18, related to then obligatory military service (which I didn't go to because of minor health issues). I only worry about tracking it because I don't know the process to replace it, and the military is Serious Business - but then, I'm sure the process exists. Also, I don't worry much, because chances I'll actually need it for something are nil (if shit hits the fan so much that I'll get called into service, nobody will care about that booklet - they'll hear me speak fluent Polish, they'll give me a gun and send to the meat grinder).

Also, relevant: most of the important documents - like my national ID (replaced twice over the past few years), passport, contracts, etc. - have an expiry date on the order of 10 years or less. My Google 2FA codes already existed for more, and I expect them to be valid for the next 10 years too.


My passport is in a safe place. But as for recovery codes, I was told you should never write your passwords down on a paper, right?

Passport is different from pass-code. Passport has no password.


I do quite a lot of tech support for older people and would add that forgetting passwords isn't the only issue, an even larger issue is people not understanding passwords at a conceptual level.

Try as I might, my mother doesn't understand the difference between an iPad device PIN, an Apple ID (rarely needed), her email password on this same device (Google-based in this case) and add a few dozen more.

All she knows is the device in her hand. The abstract model we have where we separate device, service, app, web page, different companies...simply does not exist for her, it does not compute. So even if she'd have the discipline to write down things, it would still not work. She doesn't even grasp what part is asking for what.

There's a reason big consumer services like Google and Facebook have not enforced 2FA: a vast population will severely struggle understanding what the hell it is and what to do.

Even when you do enable 2FA on Google yourself, it runs in "soft mode". It doesn't ask for 2FA for previously trusted devices/locations. Surely for good reasons.


> All she knows is the device in her hand. The abstract model we have where we separate device, service, app, web page, different companies...simply does not exist for her, it does not compute. So even if she'd have the discipline to write down things, it would still not work. She doesn't even grasp what part is asking for what.

So passkeys would be very practical for her if I'm understanding you correctly.


This is why I don’t like when people outright dismiss SMS as suitable second factor. Yes, it has problems, but it also has a recovery mechanism that is accessible for ”ordinary peope”.

The best solution (for me) would be to connect the Google Account to my government issued identity and utilize the strong authentication provided by government for account recovery.


I've been joking about a need for "notary factor" for a long time. There's an existing, deep and distributed network of notaries public that could be reused for stronger authentication in the modern world. In classic banking if you had a recovery problem you could send certain types of notarized letters to get stuff done. It was slow: however long it took to prepare the letter, find a notary public to get it notarized, and then presumably snail mail it to its destination. But sometimes slow is better: if someone is trying to steal my account, if they need to get the right forms notarized and mailed to the right PO Box, there are many steps along the way where I can intercede or a notary public can interject ("I won't notarize this because my ethics do not allow it.") or presumably human recipient at a PO Box can reject the mail for any number of violations or failures of documentation.

I think it would be great if the recovery mechanism for "ordinary people" took about the same amount of time as a notarized letter. In that worst case where you are locked out of your account for a week or two it won't feel great, but it also helps you feel better that some jerk trying to steal your stuff can't do it any faster either.

There are all kinds of fun technical things that could be used to actually build interesting "notary factor" tools. I think tech companies mostly reject how cool it could be to build because they see "slow" as a "bug" rather than a "feature".


> "I won't notarize this because my ethics do not allow it."

I heard those words uttered at my bank one day, and I became furious. I'd been using, in good faith, a licensed notary at a shipping store, and it turns out he'd been notarizing any damn thing I wanted without regard for proper form.

I had been extremely naive about notary publics, and when I ran into one with ethics, it cast the sketchy dude into sharp contrast.

Thankfully I've had no legal repercussions due to the invalidity of illegally notarized documents in the past, and I haven't needed to notarize something in a while since then.


In France there's L'identité Numerique by the Post Office where they provide you a digital identity, verified in person by a post office employee which you can then use to authenticate to various services.

EU ID cards also come with biometrics and NFC included, so they can be used to prove your identity digitally (there was a concept in France for an app that reads the NFC, makes you take a video selfie to confirm it's the same person, and then uses that to securely verify your identity)


I agree with this so much. As someone who has had a fair share of notorial interactions, it's low hanging fruit that notaries are not being used to authenticate users.

It could even be a means of fighting spam/bots while maintainh anominity.


> SMS as suitable second factor

It could be suitable, within certain boundaries, but no, given that sim swapping just means bribing (or simply social engineering with a crude fake ID) a minimum wage worker at a mall store, anyone whose identity is worth more than $50 to steal should never even consider it.

For example, if it could only be initiated from a browser where you have successfully signed in on at least two different days, or from a residential IP where you were seen recently.

I would much rather see a mailed postcard, as the last-resort fallback to a TOTP. Better to be locked out of your account for 4 days waiting for the mail, than to be locked out of it indefinitely while the criminal has full access.

> my government issued identity and utilize the strong authentication provided by government for account recovery.

Yes, that seems so obvious and yet to my American ears it sounds almost like science fiction. People here unironically argue that a national ID card is the Mark of the Beast from the Bible.


> I would much rather see a mailed postcard, as the last-resort fallback to a TOTP. Better to be locked out of your account for 4 days waiting for the mail, than to be locked out of it indefinitely while the criminal has full access.

What happens to the homeless or move?


The homeless can receive mail. General Delivery, mail addressed to them care-of some charity organization or shelter, any family or friend.

Mail forwarding is a thing for those who move, although TBH it would be prudent to use the "Do not forward" option on this, as mail forwarding itself is prone to fraudulent usage.

I guess if you've moved, you would need to mail them proof that you lived at the old address and that you live at the new address. I had to do that to claim unclaimed property with the state -- I had to send them some old bills or legal documents showing the old and new addresses.


SMS as a second factor is not bad - it has problems, but those shouldn't make the security worse than no second factor and strictly higher in most situations. The problem is that giving a company your number risks them letting an impostor use it as the only factor or in combination with useless "secrets" like publicly available personal data. This has happened often enough that you have to assume adding a phone number to your account makes it less secure.


Can't you recover your google account by SMS, even if you have GA turned on?


> Can you really expect a typical person - including the tech-savvy ones - to keep a hastily written piece of paper for a decade or more, without losing it?

Personally, I keep these in my password manager. My password manager is offline-only, and the database is regularly backed up, so this makes sense for me.


What you're describing already happened. When Google turned on 2FA for everyone, every librarian in the country was inundated by homeless people and old people who had just been summarily evicted from the Internet.


I keep my codes on an encrypted thumb drive I store in a fire proof box along with important documents.

As for the OP, it sounds really convenient but convenience is what led to Code Red Worm in 2001.


You have that thumb drive backed up? Because thumb drives can, occasionally, spontaneously fail, for no apparent reason whatsoever, and the fire-proof box isn't going to help (hell, it may make matters worse if futzing with it generates ESDs).

Also: where do you keep the encryption key for that thumb drive?


"The what in where?" says typical user.


Can you just reset my password to P@ssword2023!


No, it can't be a previous password


It was P@ssword2022! previously


It must contain a bizarre character that you would normally never use in a password.


My passwords always contain at least one poop emoji, the Sanskrit OM glyph, and the hieroglyph which means "motorcycle".


Sure, but you should know that OpenAI disputes the translation of the moto hieroglyph, and they use it to mean "UFO" which is against policy and therefore not allowed in your password.


But it can't be a space or a letter in your own non-english language, or our hashing algorithm breaks.


Scratch that, you can't use spaces at all.


Any user that didn't pay attention when they were loudly and clearly told "SAVE THESE CODES OR YOU MAY LOSE YOUR ACCOUNT" probably doesn't actually care about their account that much.


Or maybe, when they're first setting this up, excited about the new thing in their life that is their first smartphone or something, they don't realize yet that couple years down the line, half the things in their life will be gated by the Google account login form.

When first set up, the Google account really isn't something to care about. It only over time, and you getting used to all the conveniences it offers, that it slowly but surely becomes important.


Uhm, really? Company punts on how to actually secure it by saying "store in a safe place" so now it's all on the user? Aren't we back to writing your long, complex PW on a post-it note then, with the extra step of "lock up your post it!"?


> Company punts on how to actually secure it by saying "store in a safe place" so now it's all on the user?

Yes, it's on the user, who else would be responsible for that? A Google employee isn't gonna go to your house to install a safe for you so you can store it securely. You can argue all day that the average person often can't be trusted with these things but I fail to see how this is anyone's problem except their own, at some point we need to stop treating adults like babies that need their hands held through everything and let them learn that their decisions have consequences.

99% of people don't need that kind of security any way, just keep a piece of paper with the codes somewhere hidden that you can remember, you don't need to have access to them all the time unlike a normal password.


> at some point we need to stop treating adults like babies that need their hands held through everything and let them learn that their decisions have consequences.

Never underestimate the massive market advantage gained from treating adults like babies and handling all manner of frustrations for them.

UX researchers would call that "A good user experience."


I much prefer this approach (and can take responsibility because I feel perfectly empowered to make as many copies and backups of my recovery keys as I need to make it effectively impossible for me to ever be locked out), but this whole thing points to how giving people the security they claim they want is at odds with their convenience at every touchpoint. I have repeatedly refused a family member's request to set a front door access code that is any family member's birthdate, a very common habit because that's the kind of thing people want to use.

I continue to believe that security for nontechnical users is not a solved problem. WebAuthN or whatever may someday help solve this puzzle, but only if someone packages it in a way that is so frictionless that it's easier than just using your birthday and initials as your password for every account like my dad did. And if the recovery story for the "All my electronic devices fell into a lake" situation is something less exploitable than the pathetic SMS. I'm thinking notarized letter as someone else pointed out.


> giving people the security they claim they want

2FA is usually imposed onto people.

For example google just enabled it for me, and also imposed it to most active python developers who published on pypi.


Can't really blame the user when every (software) license agreement they have to click on also has more than 50% all caps. It's a form of fatique.

Even as a technician i stopped caring about all caps and the license agreement. It boils down to two choices "You want to use this? Click yes and agree on things you don't understand" or not use it at all.


And since everything has similarly complex license agreements it boils down to blindly agreeing to something or becoming a hermit.


I recommend not blaming victims or users. If a path is unclear, easy to forget, or out of the user's limited experience, it's the developers' fault.


Do you and people you know have a safe? Where I'm from, we generally don't use safes.

Do you consider your safe to be... safe? I'd imagine it to be relatively easy to get into, by picking the lock or sawing through the safe.


> Do you and people you know have a safe?

Yes. I'm not taking about a safe like you can see in the movies. Just a locked box.

> Where I'm from, we generally don't use safes.

That's on you.

> Do you consider your safe to be... safe? I'd imagine it to be relatively easy to get into, by picking the lock or sawing through the safe.

That's not the point. 2FA is about thwarting password leaks. If someone has physical access to my house and knows my passwords, I'm screwed, yes.

But since I don't live in a Jason Bourne movie, my threat model isn't a ninja who steals my passwords then comes into my house to hack my tiktok account. My threat model is breaking my phone and knowing that my backup passwords are in a minimally safe place where I expect them to be and weren't carelessly thrown away with old documents; and deter casual "attackers" like a niece who could be inclined to plunder my papers for coloring material.

And if I did live in a Jason Bourne movie, I'd expect the ninja to just beat me up when I get home and unlock my safe for him, assuming I had bought an unbreakable safe.


> And if I did live in a Jason Bourne movie, I'd expect the ninja to just beat me up when I get home and unlock my safe for him, assuming I had bought an unbreakable safe.

Here I was thinking you might blow him up with the toaster. Or crash him into a garbage truck after an extenuated car chase.


We live in the era of smart toasters. You'll need to use your 2FA tool before you can blow someone up with it, which kind of defeats the point when chased by a ninja that's after your 2FA tool.


> > Where I'm from, we generally don't use safes.

> That's on you.

In some places the general level of trust is so high that things like theft simply does not happen.

Yes there's a possibility one might lose valuable stuff not kept in safes. There's also the possibility of loosing the keys (or forgetting the combination) of the safe.

And lastly, wouldn't it be so badass ironic if the safe sent a code to your email for verification? :D


So 2FA is just for the tiny, tiny minority with a safe? What... Am I missing an obvious joke here?


Or you know, a drawer with a notebook in it.


> > Where I'm from, we generally don't use safes.

> That's on you.

Wait, are we expected to have to buy safes to use the internet now?


I mean, you should have a safe for a million reasons. Mine was bought from Groupon for $50 and wouldn't even keep out a determined teen if they didn't mind the intrusion being detected.

It just gives you a single location in your house which you know nobody could accidentally open up and misplace the contents. It's where our passports and other foundational government documents, ATM cards, and yes, 2FA materials go. When you keep that kind of stuff in say, a desk or nightstand drawer, it's vulnerable to the 'oh crap, we cleaned out that drawer' attack, where you or your family members toss that stuff inadvertently.

Try a safe, it's great.


Nah, I'm good. I have all the benefits you cite without having to bother with a safe.

I was just reacting to the somewhat bizarre idea that owning a safe is something we should be expecting people to do for their online stuff.


Well said. It's hard for me to imagine how an adult could have such an uneventful life that they don't possess anything worth locking up.


Who said people that don't own safes don't have anything worth protecting? Safes aren't the only option.


It sounds like you're choosing to interpret "safe" far too narrowly. I understand for opsec you likely don't want to share the specifics, but if you have "all the benefits" of my safe, good for you, sounds like you've got a safe:

* Single location for things you've only got one of, or which are super valuable and small

* Not somewhere that a burglar would just immediately check (rules out places like "nightstand drawer")

It sounds like you're just bragging that you've saved $50 by not having a true lock on your thing. I'm guessing you're pretty sure you've hidden it so well that a lock isn't worth "bothering with." Good for you! Enjoy your safe regardless.


Considering how much of our lives is on the internet, it's not a bad idea.


The main purpose of a home "safe" is fire protection. If my house burns down, the contents of my safe should be fine. Obviously a sufficiently motivated adversary can get in. But that (usually) isn't something I am worried about. Most internet hackers do not physically break into houses and open safes.


Yeah, we actually keep the key in the lock in ours. If someone gets in and really wants to steal it (note to potential thieves: there isn't anything worth your while), they could just carry the whole safe with them. It's only for preserving important documents in case of fire.


Many safes allow for securing to the floor, making porting it away require a bit more effort, possibly including power tools which are quite loud. Also they're quite heavy usually.

I remember as a child someone broke into our house while we were away to steal stuff. The safe wasn't bolted down, and they carried it from one end of the house to the other before giving up, either because they got spooked by something and bolted or because it was just too damn heavy.

Think about the logistics of it. If they're stealing a safe, that probably requires a vehicle. A vehicle is more identifiable and unless stolen makes it easier to track people if noticed or recorded. If stolen, there's a chance it will cause a problem immediately before, during or after the crime. If they don't use a vehicle, all the benefits of not using one, such as being able to take non-road paths and blend into crowds are negated. And if they choose to crack the safe on location, that adds time to the crime while doing so, and all time spent at the location of the crime increases the chance they'll be caught because someone notes something suspicious.

Like a lock on a house a safe within a house serves it's purpose not by making it impossible to gain access but by making it much more troublesome and likely to be noticed, changing the risk to reward ratio.


Th "protection" from home safes is a joke: typically 30-60 minutes at temperatures less than the heat generated by a house fire.


The house next door to me caught fire. By the time I saw the flames from my window and ran out the door, the fire truck was already preparing to douse the flames. Yes, I am lucky to live in an area with fast responses; no, not everyone is so lucky, yadda yadda yadda. But safes help. So do fire extinguishers. Get one for every floor in your house.


30-60 minutes is a very long time, do fire departments normally take that long to start dumping water on the house? Some site says "NFPA Standard 1710 establishes a 320 second or 5 minutes and 20 seconds 'response time' goal for not less than 90% of these type incidents."


A safe is extremely safe against hackers on the other side of the world. Quite safe against more local threats without special equipment and time on their hands.

Security is relative to your threat model!


My entire storage building just burned to the ground with my safe in it, all my paper codes, my laptop with all my auth on it.

Luckily by sheer fluke my phone was saved which has my TOTP apps on it or I would never get into anything again.


Why did the safe fail to protect the paper -- too hot, too long?


Lol the water from the fire service did more damage. Fire proof, but not high pressure water proof.


Just keep the backup codes in your wallet - most people protect their wallets pretty well.


I'd recommend obfuscating the codes in the event that you lose your wallet. You don't want a bad actor to find it and realise they can gain control of your account though they'd need to figure out your email first.


They need to figure out your email and password from your wallet contents, which is improbable. Anyone who takes your wallet just wants the cash and credit cards - and they toss the rest.


You can also buy a few cheap RFID stickers that can be overwritten from your phone. The cheapest stores like a kilobyte or so, which is plenty for quite a few codes.

You can glue them in inconspicuous "boring" places in plain sight, like under a mousepad or behind a movie poster hung on the wall.

Great way to hide secrets in your home without owning a traditional safe (which just screams "steal me! I'm the valuable thing in the room!" anyway.)


I keep all the backup codes in my wallet, next to the $5000 in small bills. /s

My backup codes are filed in an expando-file. There are far too many to cram into a wallet. Also, if I'm carrying them around with me when I don't need them, my risk/threat model now includes loss and theft of wallet. That's ridiculous and unnecessary.


Why would you label your backup codes as to what they go to? Of course that's silly. But if someone does get your wallet they still need to know the website they are for as well as your login and password. It is low risk.

Or just ignore the backup codes altogether. We mostly have "fake 2fa" - where you can reset your 2fa auth if you lose your device because otherwise customer support would be impossible. Almost every service allows this.


I don't understand this. Many backup code lists do print with very limited or no information on the account they match. But what is the need for this cloak and dagger? A backup code is only one piece of the puzzle and can easily be stored securely, "secreted away" if you will.

If I don't label my backup codes with account information, how do I know which code to enter when recovering an account? Trial and error across 20-30 scraps of paper?


When I was younger, I was run over by a car. The stuff I had been carrying was left at the scene and later blown away (or picked up by a street sweeper). Back then, textbooks cost less than rent payments. But I did have to do that homework all over again.


Relatively easy? Relative to what?


Relative to a naively imagined abstraction of a safe, perhaps.

A decent home safe can be reasonable protection against that loose scrap of paper with backup codes ending up in the trash can and may even keep it legible in the event of a house fire. But it is true, it won't be much help if you are targeted by safe crackers.


Relative to the wrench attack, I guess: https://xkcd.com/538/


or a little water damage, or a fire lasting more than 30 minutes.


Most decent safes are not trivial to pick, often using circular keys instead of the flat ones requiring a different type of pick. Newer safes don't even have keyholes but require that you actually know the combination.

As for drilling or sawing through it, that's going to take hours to do.


> As for drilling or sawing through it, that's going to take hours to do.

This is true for expensive commercial safes, but not for home safes. You can drill/saw through them relatively quickly. What you can't do is drill/saw through them without making a whole lot of noise.


You have to meet people where they're at.


Post by "Group Product Manager". It's a pretty useless post. Could've been 2 sentences.

From the support page:

> If you’re signed in to their Google Account within Google Authenticator, your codes will automatically be backed up and restored on any new device you use.

Still doesn't explain how it works. On the same page they're talking about synchronization:

> Google Authenticator 6.0 on Android and 4.0 on iOS introduces the option to keep all your verification codes synchronized across all your devices, simply by signing into your Google Account.

I don't understand why "people" think it's a good idea to hide any form of mental model or technicalities.

Provide people with a mental model. It will make it easier to understand all the Ws. People are not stupid. They will understand, as long as you can describe it properly.


Yep. Also missing from the announcement are any instructions on what people need to do to use the feature.


> To try the new Authenticator with Google Account synchronization, simply update the app and follow the prompts.



Nor the follow-up necessary should your account happen to be randomly blocked.


I believe the idea is that for as long as you still have 1 device signed in you can recover it by using one of the codes.


I remember pushing for this when i was at Google ~5 years ago. I wasn't on the team but I wrote 2 proposals, one to do QR code export and imports and another to sync codes using the google backup framework.

Neither was approved nor denied, just in limbo. But nice to see that both features have finally shipped. Sadly I have switched away to 1P, too much effort to move it all back.


Years ago I got FUCKED when I used Authenticator and bought a new phone. I just assumed everything would be backed up to iCloud, like everything else. I lost access to accounts which were almost impossible to retrieve. Millions of people have been screwed thus, turning people away from 2FA. I can't believe it has taken this long to enable sync.


Our onboarding docs specifically tell employees to NOT use Google Authenticator precisely because of this issue. I have no idea how Google let this fester for so long, literally if even one (1) person over there was using it and got a new phone, they should have known about the issue.


Yeah, same with my company. "DO NOT USE GOOGLE AUTHENTICATOR" is littered throughout our Intranet and onboarding docs in bold letters with recommendations for different options. And people still use it and lose their codes all the time.

Now it's tied to the Google Account which means it'll be tied to either their personal or work account and now we have to worry about personal account bans removing their 2FA or when they leave the company, our suspension process killing personal 2FA that were synced via the wrong account.


The best and safe way is to save qr codes and or strings to a seperate password database (I use keepass).


The app has supported bulk QR code export and import for years. This makes it easy to transfer to a new phone, and relatively easy to make physical backups.


Which only worked if you had both phones working at the same time... I'd bet a sizable portion of new phone enablements are due to losing the previous phone irrevocably.


When doing a factory reset because of whatever reason, this becomes an issue as well. You cannot take screenshots of the bulk export QR-Code on Android because of FLAG_SECURE, so you need to work around that and take a photo of the screen with a different device to import from later.

Also, as of last week, there existed an issue with special characters when trying to import and the app would just freeze or not recognize the QR code pattern at all, so you better had backups of all your secret keys.

Both issues made me switch to Aegis and appreciate my past self backing up the secrets with KeePassXC.


I have long migrated to Aegis and it is pretty awesome. Backups. Copy & Paste. Encryption. Auto-upload to Nextcloud. Better Interface (with names!). etc.


You'd save the QR code at the time you first used it on the old phone, and not wait for when you needed to transfer it.

For me, I'd usually be on the desktop when setting up 2FA anyway, so I'd just save the QR code from the desktop browser ("Save image as ..."). When I needed to set up a new phone, I'd open the saved image on the desktop and point my phone at the screen.


That's an absurd expectation. First of all, many users don't even have or use a computer. Of course, I personally do have one, but I'm often nowhere near one when I set up MFA on a new account. So then I guess I screenshot the QR code to my phone? But if I saved the image to my phone it gets stored in my photos backup anyway. Why would Authenticator not just back its own contents up, to that exact same spot, rather than me doing some crazy runaround that for some reason involves images?


It’s completely outside the realm of reality to expect “normal” people to do this. Most tech people don’t even do it.


Why go through this trouble and risk forgetting and getting locked out when you can simply switch to a better app?


The QR code encodes the actual secret data for the TOTP, so backing up the QR code is sufficient.

Screenshot -> Print is one backup method.

Screenshot -> Encrypt -> Save to secure location is another method.


Does that mean you need to take a new screenshot every time you add a new account?


Yes, but for my threat model I avoid 2fa for accounts that don’t really need it so in practice I’m not adding accounts regularly.


Nope, you can't screenshot the page, so you can't save the code and can't send it to another phone. This means you can never trade in a phone for a new one and if your phone is lost or stolen you're locked out of all your accounts forever.

They actively added code to prevent you taking screenshots, which is insane but true.


I'm on iOS and I'm able to screenshot the QR code with version 3.4.0 of the app. Maybe the screenshot lockdown is limited to Android?

In any case, if you're trying to create a backup there are other avenues of capturing the QR code - offline digital camera is probably the most secure way of doing so.


What if I drop my phone into the lake and need a new phone?


Well, hopefully you created a backup by storing a copy of the QR code somewhere :)


This literally happened to me and is the reason I no longer use Authenticator. Everything else on my entire phone restored, but not Authenticator.


Interesting - but not good enough. For the threat model TOTP solves, it is not absurd to want Authy-like functionality where codes can be backed up, encrypted, to a cloud service OR like Authone (?) which allows you to export the data to a file.


Right, just like I can carry a thumb drive around with my files and manually sync between every computer I use. Or just use Dropbox...


This is not a 2FA problem. It's a google problem, and the google problem is not limited to 2FA.

Do not use google-anything, for anything in production, ever. They make shiny products that depending on your point of view may be nice or just shiny. But their total solution is not a serious competitor to any of the major players. Any time anything depends on google, you risk it destroying a part of your business - yes, under a paid support contract.

I was doing a dc migration at a hospital once, and they used google authenticator. I'm waiting for the day some sysadmin who knows some dev who worked with some dev on an app that was banned from some phone that got resold, will cause all the storage, network, and sysadmins to lose remote login access to all their devices during a sev1 at 2am.


Incidentally, Signal works the same way on an Apple device. No backup. Lose your phone, and your entire chat history is GONE, together with all the media.

Apparently the authors of Signal consider backup to be less important than all the idiotic "story time" features and similar doodads.


I'm so much with you on this. I love Signal, but I'll never recommend it until it gets backup/restore. I have no clue why this is not prioritized over everything else.


I got burned once on this, then switched to Authy and never had any trouble with it again.


Now, try to switch away from Authy. That's the trouble you'll find.


There are ways: https://gist.github.com/gboudreau/94bb0c11a6209c82418d01a59d...

Not saying it's a particularly good way, but it's a way.


I know. I have been through it. It is a horrible way.


Yep, I’ve been using Authy for years because of this. Before that, I would have a second phone with GAuthenticator on it and when I scanned the QR code to set up a new account, I would do it with both phones simultaneously to make sure I had a backup. It always struck me as absolutely ridiculous.


Authy used to share its SDK TOTP codes with attackers via account recovery, and no backup password was needed. SMS hijacking led to authenticator takeover on Authy SDK-using sites like Coinbase. Which is partly why Authenticator and co. were originally designed to prohibit secret backup.


Why couldn't you use your old phone to get access and switch over?


If you damage your Android screen it is basically useless unless you have pre-emptively set up some kind of remote access process...

Twice I've had to spend hours manually resetting/renabling my 2FA after a phone was damaged, and sans buying a new screen just to get a backup of the phone, there aren't many other options.

(Similarly, this was the time I learnt that the UK gov does not issue backup codes for their 2FA and you just have to spend 45 mins on hold to have them reset it for you.)


Exactly this. I bought my current phone after I dropped my previous one and cracked its screen. I was only able to recover access to critical services because I have previously set up some Tasker automation connected to my Pebble watch, which enabled me to navigate the phone "in the dark" enough to turn on AirDroid, allowing me to screen-mirror the phone to the PC. Of course, all the 2FA tools have this stupid idea of blacking the screen when it's being mirrored - but fortunately, I was able to turn on USB debugging this way, at which point I plugged the phone in and used scrcpy to show a fat middle finger to Google and plain recover everything from Authenticator.


Now imagine trying to explain this to anyone outside of the tech industry. I imagine only a small percentage of software engineers and IT folks in general would be able to accomplish what you did. How easy it is to accidentally fuck yourself over with app-based 2FA is one reason I've been hesitant to recommend it to my non tech savvy friends and family. While SMS 2FA is a lot less secure, it's at least pretty much idiot-proof.


Yet this scenario (currently authenticated phone is gone) just seems a baffling concept to the people making these apps. I need to be able to make an offline backup for the day when the phone is lost or destroyed.


> and used scrcpy to show a fat middle finger to Google

Unfortunately Google has the last laugh here, because since Android 12 even scrcpy can no longer bypass FLAG_SECURE. Currently you'd have to start messing about with root and using some sort of Xposed and/or Magisk (?) module to disable FLAG_SECURE in order to be able to mirror that kind of apps with scrcpy again.


I had already wiped and sold the old phone by the time I discovered Authenticator wasn't working.


You can get the database out of the phone. It requires adb and root, though.


> Sadly I have switched away to 1P, too much effort to move it all back.

It seems like a very, very bad thing to store both your passwords, and TOTP codes in the same tool...


The main point of TOTP is that users passwords are mostly weak and reused across sites. TOTP protects those users from password stuffing and similar attacks.

If you are using a strong random password generated from 1PW you've already mitigated against that threat. TOTP isn't buying you much additional security. So for most folks it is just fine to store you TOTP seed in 1PW.

Unlike TOTP, passkeys _do_ buy you additional security in their phishing resistance. So you should always prefer passkeys/fido2 keys to TOTP if that is an option. Its still fine for most users to use 1PW as your passkey storage.


> If you are using a strong random password generated from 1PW you've already mitigated against that threat. TOTP isn't buying you much additional security.

Why isn't TOTP buying much additional security?

It seems to me that apart from password reuse it's mitigating many other potential problems: keyloggers leaking passwords from your device, passwords leaking from the authenticating server, etc.


Not exactly the question you asked but one reason FIDO/Ubikey provides more protection than TOTP is that it won't send codes to the wrong website. If you're being phished skillfully, and don't notice the URL is wrong, you're protected in that way. If you use TOTP you have to verify the URL manually.


Totp seeds leak from servers just as easily as passwords do.


One way passwords leak from servers is when they're being inappropriately logged (like at the POST-level), which is not going to happen for TOTP seeds.


True enough. However, unlike a password, you can’t take a hash of it and thus reduce the consequence of exposure. It’s just another shared secret, albeit one that doesn’t rely on the fallibility of human creation.

The only good solution is WebAuthn and related technologies (phone passkeys for disaster recovery), so that server side needs nothing more than a public key.


Furthermore the risk exposure to using TOTO in 1pw is almost insignificant. You can configure your 1password account to require 2FA when setting up new devices, and unlike Google here the decryption requires manual knowledge not shared with the cloud.

The only argument I can imagine is that if someone gets ahold of your phone it's either locked and they can unlock it or it's unlocked, in which case either your 1pw account and/or other TOTP apps are either locked or unlocked. In the worst case scenario where everything is unlocked, having a separate app is negligible.

Besides, AFAIK Google Authenticator doesn't require additional unlock steps, unlike authy or 1password.

You're better off worrying about how to avoid TOTP and securing 1password than about having TOTP codes stored alongside your passwords.


It literally protects you from key loggers. Isn't that important?


In practice, no. Key loggers are a minuscule threat to account security compared to weak passwords and password reuse.

But lets say you are in fact a user that gets targeted by an adversary capable of deploying a key logger against you. Does TOTP protect you? No! If you are compromised to that point, the attacker is also in a position to just hijack your sessions.

There isn't a threat model out there that is trying to solve the problem of "my end user device has been compromised but I still want to be able to use it to access sensitive systems without those systems being compromised."


Token binding was the closest we had - still lets a compromised endpoint in the right position steal and use the tokens from that device, but it's at least not persistent.


Keyloggers may not threaten people who habitually use personal devices, but I can see them still looming large for those who rely on public computers, in libraries, schools, coworking spaces, etc. YMMV.


True


I agree, and I'm a huge 1Password fan.

I use Authy instead, which also backs up TOTPs.

I'm also having the same thoughts about Google Auth: my email (Gmail) is a big target for gaining access to the rest of my digital life, and putting 2FA in the same hands seems risky. I'd need to do more evaluation to consider leaving Authy.


As a former Google Auth user, who bungled my own phone migration a few years ago - yeah, defense in depth is better but at the time, I was furious there was no way to recover my Google Auth and I had to go to every single service and reset my 2FA.

Storing both on 1Pass is not as secure, but the option is that once in a while you misstep and spend a week restoring TOTP setup (or lose entire accounts because your service provider has no functional customer support) then I'm amenable to stable but less secure options.


> It seems like a very, very bad thing to store both your passwords, and TOTP codes in the same tool

Yes. It defeats the purpose. But whenever you mention it, you will get lots of replies with plenty of hand-waving why this is still better and why it doesn't matter "much".

If you go to the effort of doing 2FA, do it right. Two Yubikeys, and a reasonably decent TOTP app (Authy qualifies as "reasonable") for those sites that do TOTP.


Very true, however as others have pointed out it all comes down to levels of security.

There are many non important accounts where I have 2FA, and both the password and the TOTP is in 1p. This should suffice for any brute force password attacks. However there are some accounts (like google) which one can consider more important for which I keep the TOTP on a separate app like Authy.

More recently I've been switching to yubikeys where possible.


Eh, it's still better than not having it. Which is likely the bar for a lot of casual users. Mostly the goal is to prevent password reuse I think, which comes down to convenience. And unless 1pass gets hacked (which could happen! see: LastPass) it's relatively secure for that purpose.


I'm more concerned about the one tool being cloud-based than anything.

I keep my 2fa backup codes in my Keepass safe. Where else will I keep them?


fwiw, Google Authenticator starting with 3.1.0 started supporting exports via QR code.


Yeah, but only as a means of transferring them to another device. Sure, you could abort the flow before the existing codes were deleted, but it was far from ideal.

I’m glad there’s finally real support for backing up codes.


Hmm no, I use this from time to time, and it really is just a way to copy the codes to another device. It won't delete them from the original device. It notifies the device owner after a few minutes that the TOTP have been exported, and it keeps a log of exports.

I'm in the process of moving to Aegis. It's FOSS, encrypts the file on the device, and supports the biometric lock. It can do a daily backup to a few sources, including the Google backup (I think) and personally I dump it to a folder that my Nexcloud will automatically upload to my personal server.


It doesn't delete them from the existing device. However, it exports them via qr code, which it prevents you from screenshotting, meaning you can never factory reset your phone or protect yourself from theft or loss. You can only transfer to another phone when you have both devices working at the same time.


How does a QR code prevent screenshotting?


Apps can set a flag disallowing screenshots by the operating system


Does the export invalidate the existing device after export ? it sounded like it's only for moving to a different device rather than having two at the same time.


What you are suggesting is technically impossible.

You'd need to involve the provider for changing token seeds.

At a client level, all you have is one seed.

If you save a seed, it can be used on any number of devices.


Not on iOS within the last year or so.


I would've even been happy if they didn't block you from screenshotting the QR export code. This has caused me so much pain over the years but nope, they refuse to change it.

This basically means you can never factory reset your phone without someone else using their phone to help you, which means you're forced to share your entire account and all your codes with a third party who might keep them forever.

You also can't preemptively back it up in case your phone is stolen or lost.

But nope, Google thinks they know best and in 2023 they still actively block you from keeping your accounts safe. It's mad.


You can go to a place that has self-service photocopiers and copy the QR code(s) from the export screen(s) to paper that way.

I just tested this using the copy function of my Brother printer/scanner, and my phone was able to successfully import from the printed export code.

I've only got 4 accounts in Google Authenticator (because I only have it because I wanted to help someone else once who was using it figure out something). The more accounts you have the denser the QR code will be, so it is possible that you might have to split the export into multiple passes with this method if you have a lot of accounts.


That was worst thing about google Authenticator was migrating to another device and amount of support my IT team had to deal with people upgrading phones. I can’t believe how long it took for an export feature.


Yeah, I switched away from Google for this reason. Pretty wild to think of the implications of losing your phone and having no backup. Even switching phones required resettings all your codes. Authy is a mess, but at least had this functionality when they were still actively worked on.


All you need is the OTP secret. I have all of mine stored in my bitwarden. I can plug and play them in any supporting app to keep generating the 2fa codes.


QR code export is an old feature. I have an Android emulator in my desktop justo to have backup of my codes.


Such a bizarre app. Instead of implementing push notifications in the "Google Authenticator" app, Google decided to add the logic to all other apps like YouTube. Before we introduced Okta, our users would get notifications like "Open the YouTube app on your phone to approve this login".

Whilst clever for the people who don't have Google Authenticator installed, it's just bizarre to ignore it when it's there.


They also once bizarrely replaced the `com.google.android.apps.authenticator` package with the new (and still used) `com.google.android.apps.authenticator2`, making everyone set up their accounts all over again or forgo updates: https://www.androidpolice.com/2012/03/22/psa-googles-authent...

The old one has its name changed to "(old)": https://play.google.com/store/apps/details?id=com.google.and...


Google's preference of their weird, bespoke authenticator over TOTP is also very annoying to anyone who would rather not. (it is required to add any additional authenticators, and the default authenticator)


It's more secure though.

TOTP are still phishable, the push notification includes information on where you're logging in from, so you at least have a chance to notice that the login is coming from Croatia and not your house.

FIDO is still vastly better though.


The weird thing is that even if you set up a separate hardware key it still prioritises your phone for some weird reason - it should not be like that.

(And no, enabling "advanced protection" doesn't count. It's well-meaning but it's too restrictive.)


Just because it's more secure doesn't mean I want to use it: it's poor UX, especially for those of us who don't carry a phone around 24/7. Even if you use FIDO or TOTP, it will always prioritise push notification and AFAIK you must enable push notification to use any other type of MFA.

Plus (unlike TOTP and FIDO), it's proprietary, making it harder to fit in my workflow. For instance, I can generate TOTP codes from my computer in order to seamlessly sign-in to services.


Any attack that can intercept TOTP codes (= some kind of MITM or local device compromise) can also request the unwanted actions with the IP of your device. All this does is prevent lazy attacks.


With Google Authenticator, there is no notification, is there? As a user, you have to open your phone, open the app, then scroll to the right code, and copy/paste it. (The lack of search in one of the reasons that made me switch to Aegis)

I always thought Okta was kind of weird, because it's just a notification that says "allow/deny" and it's easy to click the wrong one.


It's possible I'm confused by GP, but there's two things being discussed here I think:

First, Google Authenticator, which is in fact just totp which can be used for both Google 1p and any 3p TOTP thing. And second Google's push-notification based auth checks which are used for only certain 1P Google apps (like logging into your gmail or youtube).


Apple's is worse. At least google does let you use totp.


I'm not sure what Google is trying to belatedly do with Authenticator at this point. But making it less of a support nightmare is a good thing. And I expect somebody (finally) got pragmatic about it maybe not being ideal that users get locked out of all their critical accounts every time they loose their phone. I bet that generates a lot of support overhead for them.

2FA setup in general is a PITA to support with users in the real world. I speak from experience. It's too complicated. Too many different steps involved. People get stuck doing it. People get locked out of their accounts. Etc.

Most people with a clue would not use Authenticator but one of the many alternatives that do the same job but with a bit more convenience (like syncing secrets between devices).

I tend to use Authy. And of course Okta actually acquired Auth0, which created Authy. But you could also use many common password managers for this (except of course the Google or Apple ones people actually default to on their phones).

Meanwhile, Google, MS, Apple, and others are also pushing hard for passkeys. That seems more promising. But what worries me is that they regard this as a browser thing. So that still leaves a lot of mess outside of browsers. As well as their legacy of other supposedly user friendly ways of signing in. At this point most of them de-emphasize 2FA actually. Because it is such a support nightmare.


Regular reminder for Apple users that iOS/MacOS has support for TOTP codes out of the box. It fills the code like an autocomplete.

https://support.apple.com/en-gb/guide/iphone/ipha6173c19f/io...


So are you telling me you can just use vanilla iOS to store TOTP like with Authy or Google's Authneticator or 1PAssword but directly into the apple keychain?

That seems nice

Honestly I think apple could do a better job at camera -> qr ux flow


Yup. The catch is, it's kind of buried in System Settings.

Cable Sasser wrote a blog post that was making the rounds a few weeks ago, advocating for a dedicated app. He's right, the existing Apple implementation works great but it's still a lot for normies.

https://cabel.com/2023/03/27/apple-passwords-deserve-an-app/


> camera -> qr ux flow

You mean the idiotic little tiny yellow popup which only stays on the screen while the QR in view and must be tapped to activate... WTF were they thinking right? (You can add a "QR reader" button to your control center though which functions in a more sane way.)

Anyway yes you can do that, but I wouldn't use iCloud keychain at all because your Apple account, including ICKC, can be fully hijacked using one factor only - the passcode of the device an attacker has. People watch you unlocking in a bar, then grab your phone and run. Google "joanna stern iphone passcode" before moving any precious data into Apple's control.


Actually apple updated it so that when you lose sight of the QR code, the link gets moved to the bottom center of the screen, where it stays for a while. Why it's not always positioned there, I don't know. Having to chase a moving target on your screen is some real dumb design.


> Google "joanna stern iphone passcode"

https://www.wsj.com/articles/apple-iphone-security-theft-pas...

https://archive.is/tn9aq

TL;DR: if someone spies out your iPhone's passcode, they may be able to hijack other accounts synchronized with it.

In such situations, this simple passcode is like a master password, with with critical things such as PayPal and Apple Pay payments can be initiated to drain bank accounts.

Two-factor authentication also doesn't help, as their challenges can be approved easily once the iPhone is unlocked with the passcode.


Thanks for the Joanna Stern story, didn't know that.

But if an attacker has your iPhone with passcode they surely get access to your Google Authenticator or Auth app. How "not storing TOTP keys in iCloud" way is better in this case?


Great question! You prompted me to experiment.

I'm afraid you're right. I previously thought that my authenticator, Microsoft Authenticator (MSA), was taking advantage of the feature that banking apps use where it could detect that a biometric was updated (Finger added / Face added) and clear stored credentials in that case, meaning that it could only unlock credentials with the actual face that saved them.

Well, I was wrong. Holding my thumb over the face sensors twice yields an "Enter passcode" prompt which unlocks MSA. I assume Google Authenticator does the same. Just reinforces how thoroughly compromised you are if that single 6-digit code gets shoulder-surfed. facepalm

Note: I'm assuming the reason MS and Google made this choice is that since sync was added later (a few years ago for MS and this week for Google), if they did the secure thing which is technically to self-destruct all your keys if you've altered your biometrics, this would mean that a simple redo of your face scan or adding a finger would lose all your TOTPs, because there was not a fall-back password or something that secured those apps.

So I guess perhaps a more secure solution in this situation is 1Password? Because with that, if you can't pass Face ID, you'd have to enter your master 1pw key which hopefully nobody knows or can guess.


It does do that. Point and aim camera at totp QR code and it will ask to which account you want to store it to.


You need to store the password on the iPhone in this case, which is insecure. The whole point of having the second-factor auth is using two separate devices: a computer stores the password (in a password manager) and a smartphone generates the TOTP codes.


Lol. I remember the user who said to me "documentation or it doesn't exist".

And so I looked it up. Became pretty popular on hn.


I have started using Aegis on android which is fantastic. Backup and restore anywhere.

My advice would be to not have everything in one place, no matter which ecosystem you are on. Going all in is never a good idea whether its Google or Apple. Its great that Google has done this, but just use another app to manage that.


One would be crazy to keep their passwords and 2FA with a company, which does not provide customer service (unless you pay for Google One, which still doesn't cover all of Google)! I know, it's bad to store both passwords and OTPs in one place, but 1Password does this for me smoothly, and I trust time orders of magnitude more than Google, so, no, Google, you're too late to the party, plus, you need to regain our trust, which seems impossible at this point!


Pro tip- when presented with an OTP QR code, you can read it with as many things as you want.


Except for Microsoft’s. It took me twenty minutes of trying to realize that they have their own non-standard QR codes, and that I had to click “use another authenticator app” to get a standard one.


What does customer service have to do with trust?

Personally I would be a little weirded out if a customer service rep could access my account over the phone, especially in an account recovery situation where "I lost credentials oops".


Getting locked out and having nobody to talk to is a matter of trust!


Sure but just because you can call them doesn't mean you can trust them.


But not having a way to get in touch with actual human support makes it harder to trust a company (sure, there are more reasons to not trust Google, but lack of tangible support is subtractive to the totality of their trust).


Sure it does when they can lock you out and not provide you with a reasonable timeframe to resolve it.


I had always thought that the lack of cloud synchronization was a deliberate security feature. If my TOTP secrets sync to the cloud, doesn't that defeat the entire point of 2FA? Now, instead of my physical device being the sole second factor for authentication, anyone who is able to breach/intercept/coerce someone at Google into divulging/etc the TOTP secrets from Google's cloud storage, my accounts are toast...


While I agree and wouldn't use this personally, I do have argument in favor of it.

1) Attack vector reduced to one account which you maintain with healthy hygiene, and hopefully don't use with public systems, etc.

2) You can keep backup 2FA for single account instead of keeping for N accounts.


Agreed, it seems bizarre to me that any company especially Google would roll out something like this.


Google's authenticator has been outright harmful in how neglected it has been, especially when it comes to backing up your codes outside the app. This should be a very full-featured and well-maintained application considering how essential it is for security.

For years I've been telling anyone who'd listen to use Authy instead.


I'm not really in favor of putting 2FA codes in the Cloud, see that password manager that got hacked a few months ago. Granted, we can expect better from Google, but still, they're not accepting any liability.

Google Authenticator already has a QR-Code based very easy export procedure, I just backup my GAuth to my spare phone and tablet. It feels safer because it's physical.

Of course, not everyone has several devices, and physical security is not granted to everyone. I guess cloud-backedup 2FA is better than no 2FA, or than 2FA with no backup at all. But... Cloud ? for security stuff ?


I think rest assured your backups will be encrypted-by-password.

Though, I often find myself wondering if this represents going in circles with security. If the security surface of all of your 2FA keys now reduce to one measly password, well, wait a second, does protecting everything with two passwords count as 2FA?


"encrypted by password" doesn't mean much by itself: is the whole security chain open source ? audited by a third party ? as well as any changes ? Secured by the provider accepting responsibility for breaches and their consequences ? ...

Employees down to subcontractor's trainees can modify the code or pwd store... FYI, the industry standard for "risk of corruption" is: 3 months of wages. In low-pay countries, this means, literally, pocket change. How sure are you that whatever Google does is impervious to such insider bad actors, even if at a specific time their setup was indeed secure ?


Looks like I was wrong, not password-protected. Oops.


This. For me a TOTP app/tool will only ever output codes. If it offers to let me do anything else with the key, it's a no-go.


So what do you do when your phone falls down and breaks?


Account recovery codes & other means of backup authentication until I can generate new MFA tokens. It's really not a big deal, whereas it looks like the next big cloud hack will be.


I take my previous phone out of its drawer. Or my tablet.


Very funny. But how do you login into things without the otp seed?


Use another device with _another_ seed (since this is auth factor of ownership you must not share seed between multiple devices just like pki private keys and pgp keys). Or if you don't have backup otp generator then use backup codes.


It's standalone 2FA, not a paswword manager. There's no seed.


Oooooh, you don't understand how google authenticator works!


Try it: it works offline.


It doesn't work from a broken phone.


It's interesting to see some movement in this area. Is Google finally feeling some competition? I was looking for this feature years ago and had to switch to Authy and then to 1P. I'm wondering how many users did GA loose for not adding this basic functionality for years.


It would be awesome if Google were innovating again. That was a good company on the good days.


It would seem that the "secrets roach motel" model was the most secure and sane option for Authenticator. In that way, it mimicks the Yubikey or other hardware TOTP keys, where the secrets go in but they can't come out.

Everyone with a Yubikey knows that the secrets aren't coming out and they will need a backup. It would be foolhardy to rely on a Yubikey alone, when the risk model obviously entails loss or theft of the device itself. That's what paper codes are for.

It would seem that the QR export, and now this account sync, is Google weakening security as a concession to intense end-user pressure.

Yeah, it sucks to lose all your TOTP secrets at once; that's why you form a contingency plan and stow your paper backup or maintain a spare device.


You are of course completely correct, but this is a letting perfect be the enemy of good situation. I lost my phone overseas (my backup code was at home) and losing access to everything was so annoying I turned 2FA off on my google account for years.


Yes. When TOTP debuted, it was aimed at and designed by security engineers. Keeping secrets on-device was and is correct for serious uses.

Google Authenticator is a victim of its own popularity. Fortunately, the field moved on, and we now have WebAuthn and Passkeys for non-exportable private authentication keys.


Sadly, WebAuthn is also becoming a victim in the same way (at least on iOS).

The expectation is that WebAuthn private keys are stored in the secure enclave, which would be a comparable security guarantee to YubiKeys and other hardware devices.

"Passkeys" are now forcibly synced via iCloud, you can't use WebAuthn on iOS without enabling iCloud Keychain.


Huh, thanks, I wrongly assumed that Passkeys inherited WebAuthn’s attestations for hardware-backed keys. I guess organizations will need to ban Passkeys internally.


If you're on Android, you should checkout FreeOTP+[1], a far better OTP client.

FreeOTP Plus forked the same functionality of FreeOTP provided by RedHat with the following enhancement:

* Export settings to Google Drive or other document providers

* Import settings from Google Drive or other document providers

* Enhanced UI with material design with dark theme support

* Search bar to search token

* Provide more token details for better interoperatibility with other apps

* Utilize modern camera hardware to scan QR code faster

* Option to require Biometric / PIN authentication to launch the app

* Heuristic based offline icon for tokens of 250+ websites.

* More settings to customize the app functionality

[1] https://f-droid.org/en/packages/org.liberty.android.freeotpp...


Or Aegis Authenticator. It is basically a perfect app IMO.


I recommend http://totp.app for Android. You can even set the app as default on Android.


Note that there are two kinds of backups possible for TOTP secrets:

1. Backups that are specific to the app that made them. They can be used to restore the secrets to that same app on a new or replacement device, but might not help if you want to migrate to a different app.

2. Backups that can be restored to other apps.

If you aren't sure you are going to stick with the same TOTP app long term this could be important.

Sometimes there are third party tools that can take #1 type backups and give you back the secrets in a form suitable for other apps.

For example, Google Authenticator can export the secrets in the form of a QR code that contains the secrets for multiple account. Another instance of Google Authenticator can read that, but other TOTP apps might not be able to. But this tool [1] knows how to take the information in that QR code and decode it and split it into the individual secrets for each site. It can even generate QR codes of those for scanning into another TOTP app.

If you want #2 type backups that just work with most TOTP apps, there is a fairly easy way to get them. Whenever you set up a new account and a site gives you a QR code, simply take a screenshot before using that QR code to finish setting up the new account.

Store your collection of QR code screenshots somewhere safe.

If you ever want to migrate to a new TOTP app or to the same app on a new device open those saved screenshots and scan the codes.

If you've got an image display program that will let you open many at once restoring can be pretty fast. On my Mac for example I just do "open *.png" in the place I have the screenshots. That opens them all in Preview, with each one being a separate page. Then I tell preview to show one page at a time.

Then it is a matter of scanning one, hitting "page down" on the keyboard, and repeating until they are done. After two or three I'm in the groove and it goes pretty fast.

[1] https://github.com/dim13/otpauth


> backups possible for TOTP secrets: > > 1. Backups that are specific to the app that made them

I never thought about that. I always backup the key before I first use it, when it's shown for the very first time. Heck, I've written a CLI / text TOTP app (using some Java TOTP library) for my own use (fully offline / airgapped / paasword protected / showing six codes at once for the same code [+1 hour / now / -1 hour and previous code / current code / next code] and which also shows a public/commonly used example code, which is convenient to diagnose sync/clock issues).

> But this tool [1] knows how to take the information in that QR code and decode it and split it into the individual secrets for each site.

Like JBSW Y3DP EHPK 3PXP ?

In my experience every site that shows the QR code offers the possibility to see that secret (and those that don't are misleading users into thinking it's more complicated than it is).

A TOTP secret is just that: 16 or 24 or whatever characters. The QR is just an encoding of these characters. The "issuer" serves no role other than autofill the name of the service for you (and you're not forced to use the issued nameL you can use any name you want).

I never ever scanned a QR code to configure 2FA / TOTP for any site. I write the 2FA code down, then encode what I've written down (in at least two devices).


Too little too late. Everyone I know has moved to 1password or authy or yubikeys (or some combination).

I'll never understand why they didn't do this many years ago.


Yes. And also I don't trust Google that my Google account will keep working in the future. I am glad Authy has its own account.


Yep, way too late to keep me on it. I don't trust them anymore. You cannot just burn your users over and over and expect them to stay forever.


Years ago I updated authenticator and it wiped out all my entries, which led to an incredibly aggravating week of account recovery.

What happens to your data when google decides to lock your google account? Does your device keep a local copy or will it just shut down?


While we’re complaining about Google’s 2FA offering…

The issue described here started happening to me recently: https://www.googlenestcommunity.com/t5/Apps-Account/Why-is-G...

Summary- Google has added a “match the numbers in the app” style 2FA to YouTube. Makes sense- their video monopoly means that for many iOS users like myself it’s the only Google app they’ve got. Except…

1) It’s the default, and there’s no apparent way to change it, or even turn it off. This is annoying- I prefer TOTP since it’s more secure. There’s a Google Prompts section in the 2FA settings, but it says that I don’t have any supported devices. This actually makes sense, because

2) It doesn’t f*king work! Ever since they changed it from “press yes” to “match number”, the screen opens in the YouTube app and then loads forever. Which means I’ve got a spurious notification on my phone, a screen to dismiss next time I open the YouTube app (or several, because for some reason they can stack), and two extra clicks every time I log into Google on a new device.

Actually, I lied earlier- there is one way to disable it, and it’s to DISABLE ALL 2FA, as you can see people doing in that support thread. I honestly don’t blame them, but clearly less 2FA was not the plan of whoever’s idea this was. Speaking of support forums- I don’t think anyone at Google reads them, but they do read HN :))))


Wow, that link is such a great example of Google's "support."

"This channel is for troubleshooting Google devices. It is best to report this with YouTube support for better assistance. [...] I'll be locking this thread after 24 hours."

...just because the initial report contained the keyword 'YouTube', presumably. The reporter clarified the situation, and a different "support" team member comes in and regurgitates the same canned response! On Google's side, why even bother replying at all if that's all you're going to do?


Just an FYI here: Google's community support forums aren't well named as their intended purpose is for users to answer other user's questions. For the community to support each other.

For actual support you need a paid account to reach out to.

You could argue that it's badly named and should just be called Google's community forum instead, which is what it really is.


Outside of google employees, who even posts to these community support forums? Simps for Google?


Have you seen answers.Microsoft.com, the most useless support community on the internet full of „independent advisors“ aka Microsoft simps just sending links to irrelevant documentation?


While we're at it, have you seen the Apple ones? 3 year old threads with 100 messages of people saying 'I have this same issue' and zero response from Apple.

Some examples of the subjects of these threads:

- SD Card readers in original M1 Macbook Pro not working

- Bluetooth headphones balance getting messed up randomly (so old someone created an application to automatically center balance)

- Specific Intel Macbooks crashing after using a Thunderbolt dock exactly twice.

All of them with no response from Apple at all and no fixes in sight.


Very fair replies. I didn't mean to call out Google + fans of Google in particular, but rather "Bigco"s and fans thereof in general.

Out of all of them I guess I'm more disappointed in Apple because they have cultivated this aura of superior UX (so that emphasis on UX should extend to when people have problems).. but then again it's largely just an aura.


That's pretty funny and makes sense. I guess I shouldn't have expected anything more from Google. Thanks for the clarification.


> On Google's side, why even bother replying at all if that's all you're going to do?

Oh, it's just so they can claim to their advertisers that they do support.

Remember: if you're not paying for the product, you are the product! (https://en.wikipedia.org/wiki/Television_Delivers_People)


>Remember: if you're not paying for the product, you are the product!

This cliche isn't true: if you pay, you're a more valuable mark. You're always a product.


Even better is this comment by another support team member:

> I'm chiming in to ensure you've got the answer you're looking for. Feel free to let us know if you have more questions about this.

Totally void of any helpful information or even remotely understanding of the issue. Of course at the time the comment was posted, no useful answer had been given by any support team member.

But to be fair though, the support team did follow up a few month later:

> Thanks all for your patience on this post, and sorry for the confusion. I originally pinned a response by @knewland397 as a helpful workaround for some folks on the thread, but I understand that it didn’t answer the whole question. Happy to shed some light on the situation here!

> Prompts like this are intended to be easier than entering a verification code to log in, and you can receive them from not only the Youtube app, but the Gmail app, Google Photos app, and more. To learn more about prompts and how they help keep your account safe, stop by our Help Center [1].

> To answer your question of why your Nest Community account is impacted, our community uses the same Google Account authentication as the rest of Google services.

> For future reference, our friends over at the Google Account Help Community are best equipped to help you with these types of questions. This forum is meant to host discussion about apps and accounts as they relate to Google Home and Nest.

The help center [1] indeed documents the apps (under the "iPhone and iPad" tab):

> Gmail App, YouTube App YouTube, Google App, Fotos App Fotos, AdWords App or Smart Lock App.

[1]: https://support.google.com/accounts/answer/7026266


Where is Bard?

Oh it's still waiting for its Google Authentication Numbers.


Re: “it’s doesn’t fucking work”.

I don’t know if it’s just me, but it seems like for the last couple years the products from the FAANG companies have been rotting on the vine. It seems like all the people that made these have moved on and have a b-team barely making them work.


Google's TOTP is not as good as it could be being HMAC-SHA1 of a symmetric secret and Unix epoch. WebAuthn with a hardware device is less prone to losing and compromising secrets.

I use all 2FAs allowed.

Tangent on passwords. What the world needs is a path to automated, interoperable secret management in 3-4 RFCs:

User-operable, standardized password change REST API that:

0. Sends a session token/nonce

1. Describe the password policy declaratively and precisely, to be validated client-side with boilerplate client code

2. Offer a list of supported PBKDFs and their required and allowed parameter values

3. Includes both client- and server-side PBKDF hashing with minimum values for a given risk type AND adjusted with the "inflationary" Moore's Law costs of tech resources (CPU, GPU, RAM, ASIC, FPGA, QC) over time

---> This would then permit a password manager app to automatically change every password perhaps every day. I'm thinking the future should be like this but use user certificates as a primary AA mechanism and passwords as a break-glass-backup.


A hardware device = SOL if it breaks. Few things warrant that much risk for a bit more security.


GitHub has a similar problem, where the GitHub mobile app can’t be disabled as an 2FA factor. They implemented an option to make other factors as the “default” without the ability to completely disable mobile, and then falsely closed the discussion [1].

If such insecure factor can’t be disabled, what’s the point in setting up TOTP and / or hardware keys?

[1]: https://github.com/orgs/community/discussions/10861


The point is to offload security faults onto the customers so tickets can be ignored.


Never encountered that. Is this because I got lucky in an A/B test or because I have Advanced Protection turned on and only use FIDO keys?


Out of interest what is the added value of using the Youtube app over visiting youtube on a webbrowser?


The YouTube mobile website is intentionally crippled. For example, the video refuses to play in a video popout, even though the same browser feature works for me on other mobile websites and on desktop YouTube. Personally I just avoid browsing it on mobile as a result, but I could see someone being convinced to install the app.


On iOS, installing vinegar sorts this. You get video pop outs and no ads to boot. It’s much better that the app and seems to give longer battery life (hardware acceleration?)


Downloading videos for offline watching. For example during flights without a wifi.


why not use youtube-dl?


It breaks integration with the YouTube app, and it's a bit of a maintenance keeping up with the latest version, whether to use youtube-dl or yt-dlp or another fork, etc.


Why use Netflix or Disney+ when you can go to The Pirate Bay?


If you did that, you wouldn't get the ads that the official app shows.


A way better experience. YouTube web is slow and clunky.


I paid $1.99 for Vinegar and on my iPad (and Mac) I get ad blocking, videos playing in the background, etc. It can be a little clunky because autoplay of the next video doesn't seem to work and there are times I'd like to use a music playlist. It's probably my fault but a quick glance at settings didn't resolve it.

https://apps.apple.com/us/app/vinegar-tube-cleaner/id1591303...


I use the web one exclusively. Other than the video pop out feature missing and once in a while scrolling bugs on shorts, it actually works perfectly fine.

I refuse to use the YouTube app because they disabled playing in the background or with the screen locked . They Want your eyeballs on the screen for the ads. It so blatant.


If I get sent to the web version I open in app immediately since its such a better experience for me.

They allow background play and screen-off play. You just need to subscribe to Premium.


On iOS the YouTube website only supports video resolutions up to 720p.


If you are not paying for it, you are not the customer, but the product.


We are products either way.


One of the potential solutions might be to just treat youtube as a separate service i.e. create a separate account for YouTube with 2fa disabled.

It’s not ideal since you need to deal with two accounts but that’s what password managers are for.


Is there a way to opt out of this? If I installed Authenticator on my Android phone, would it immediately and gratuitously sync everything to my account? Can I log out and stay logged out on the app so that it never syncs?

If someone uses Chrome's password manager and Authenticator's TOTP, this seems to make account takeovers an exceptionally juicy prize. Capture a Google account and you've captured credentials and all necessary factors in one fell swoop. Well done, bravo.

I mean, account takeover already means game over because you can read/send email, but the whole idea of device-based TOTP is to isolate it from anything with an attack surface.


Storing it in the google cloud doesn't satisfy me. I just simply want the codes under my control. The current authenticator did finally allow export to qr code, but google still makes it stupendously difficult to just get a simple text export to a file.

It's not been a problem for me though as I've just always saved the otpauth code from the start.


I save the qrcodes in an encrypted folder than I can quickly import into a yubikey with:

    for i in *.png; do uri=`zbarimg -q --raw "$i"` && ykman oath accounts uri --touch --password "MYYUBIPASS" "$uri"; done


And it only took them 12 years to do it. Authy had already implemented syncing to different devices for a long while.


Does that mean one can use adb to backup Google Authenticator's data as well? Last time I tried, the app data was explicitly marked as excluded in backups. I started saving the secrets somewhere else because otherwise, I wouldn't be able to have _any_ backup.


Quite interesting to see that Google Accounts, known for locking users out i.e AI auto-banning without recourse, might become a major gatekeeper of other accounts as well.


Indeed. I find it extra concerning because their "risk based" system which can simply decide you're locked out -- even when you know your login! -- just because it doesn't recognize your IP or cookies, offers no guaranteed from-scratch recovery unless you have set up the glaring security hole that is SMS. I have an extra throwaway Google account (thankfully for nothing important) whose password I never forgot, but which I simply cannot log into ever again because I didn't set up any 2FA or recovery email, and Google just decided it didn't like the look of me one time.


This only helps to get out of that gatekeeping, i.e if you loose your phone now, you're done. This gives you a chance. If they locked you out from your account, you are back to square 1.

You can still export TOTPs to other phone directly. You can still make sure you store TOTP secrets on multiple devices/password manager.


Too late, Google, I already switched to Yubikey. I kind of like that my TOTP keys are a separate entity from my phone.


Yup, I'd rather pay Bitwarden a nominal fee and be able to authenticate everywhere, than deal with the incredible amount of unnecessary friction google has imposed since forever. Never going back.


If only that was more broadly supported.


Where is it missing support?

edit: I want to reiterate that these are still TOTP codes and not WebAuth/FIDO2.


Yesterday was trying to pay with PayPal (protected by hardware key/yubikey) via Android and it said: Supported on desktop only...

And another thing: https://www.paypal-community.com/t5/Managing-Account/Why-am-...


Right, this still has to do with WebAuthn/FIDO2. PayPal can not tell if I am using Google Authenticator or if I am using Yubikey TOTP.

I would absolutely love if more services supported WebAuthn/FIDO2, of course, but Yubikey TOTP is supported everywhere Google Authenticator is.


Oh I thought you meant those usb devices that need to be set up, like google titan and similar.


Ah, no, these can connect to a PC over USB and to a smart phone over USB or NFC to generate a 6 digit TOTP code, just like Google Authenticator does.

They can also do more sophisticated things, but that's not what I was referring to here. Those sophisticated and more secure things are supported by Google, Facebook, Dropbox, Github, etc, but not by most banks. Banks are so slow with this stuff and still do SMS-based 2FA which is absurd to me.


If Google ever decides to kick you out of your account, Authenticator data will be gone. Google has done this on several occasions in the past.

I would still prefer independent app for password manager and another for TOTP with backup enabled for all.


I cannot rely on Google. Too many times have I shifted to something by Google, to have them stop supporting it or completely shutting it down.

I use Keepass/Keepass2Android for 2FA wherever possible.


> To try the new Authenticator with Google Account synchronization, simply update the app and follow the prompts.

Not seeing anything new on Android and it's fully updated.


If anyone is looking for good alternatives on Android - Aegis and Authenticator Pro are both good opensource apps, available on F-Droid/Play and also allow easy backup to a cloud (or storage) of choice.


Thumbs up for Aegis, I've been using it for years and the backup & import/export has saved my ass several times now.


If any PMs at Google are reading this for this product please, please, please, for the love of god let me export my Google Authenticator TOTPs back and forth from other managers like Bitwarden or 1password etc. I know it's against your interest but it's in the interest of the end user.[1]

[1] yes I know there are github projects that make this doable but it's super involved whereas it doesn't need to be.


This is great, although Google decided there was malware on my iPhone. False positive? After following all the steps it asked, now when logging in to any google service, google throws an error making it impossible to log in to any google service on the phone. I haven’t done a factory reset as I don’t want to loose the google auth tokens. Catch 22.


I'm also on 1Password. No idea why I would use Google Authenticator. "Hey we have Google Password Manager" - that's great, so I can be locked into your platform while you take another 13 years to implement a basic feature? No thanks? I'd rather pay a company that cares about my experience, thanks.


Nice to see it catching up. It feels like competitors (MS authenticator, 1P, the iOS thing...) have had it for ages.


Pro tip: Aegis works offline and can export and import to file.


How awful that they don't add "backup options" but just "backup to their cloud".

How nice it is for all 3 letters agencies and google employees that they have your passwords and your otp all in their cloud. In clear. All that is needed for having the keys to all your other kingdoms.


If you are concerned with lockout and want offline, interoperable backups of your 2auth codes I strongly recommend Raivo. It can’t import from google authenticator directly, but it’s possible to extract the secrets with some docker script, and then enter them manually into Raivo.


So I'm curious what happened for them to do a complete 180 in belief as to the security implications of syncing tokens off the phone?

Did the holdouts on the relevant team not make it through the layoff rounds or something?


Of particular importance is the related article and HN thread about this:

Article: "Google Authenticator cloud sync: Google can see the secrets, even while stored" - https://defcon.social/@mysk/110262313275622023

HN thread: https://news.ycombinator.com/item?id=35708869


Too little too late. Moved to BitWarden with a VaultWarden server.


Only took them 13 years, and you can likely get locked out of that too if you loose access to your Google account. Anyone know if this includes any form of export?


Tangential complaint on google account sign ins.

If I remove an account from an app / device, I expect it to be gone. But they clearly shadow it.

I have three google accounts (work, work and personal). And when I log into my personal account, which I have removed from the gmail app. It still uses that app as it’s “2FA”, and then reactivates the account.

1) if I remove the account, actually do it!!!

2) if I’m not logged into any apps, then use a 2FA method I DO have active (google auth app)


To be honest i wouldnt trust google with any accounts anymore. If you somehow get your account locked or banned, for whatever reason, youre screwed forever.


Lol I think I lost the only 2FA I had stored in Google Auth. It was for a RuneScape account I had for a decade plus, that I had long ago deleted the Gmail for. I had moved everything to another app and that was the only thing remained in Google Auth. It somehow survived transferring phones, too.

I wonder how I’m gonna access that account now? Every time I’ve tried to change the email, I’ve been unsuccessful.


It is not clear to me if this will be by default and applied to everyone in the next update, or if I have to setup something.


Once the app is updated, you will be asked at the next app start. You can either choose a Google account to sync your TOTP secrets to, or you can continue without a Google account, in which case your secrets won't be synced.


Thanks for the very informative comment.


A certain webhost requires me to Authenticator for 2FA, and I did so. I also configured my iPhone to delete unused apps. Authenticator was unused, and got deleted, so naturally, I had to open a support ticket with the webhost to remove 2FA to regain access to my webhost account. I hope this feature will maintain my setup if the app gets deleted.


TOTP seed migrations are a real pain. Its good to see Google offering a solution to that problem.

I've moved to using the pass otp extension[0] which gives me secure storage of the totp seeds without being tied to a single device.

[0]: https://github.com/tadfisher/pass-otp


OMG, aftet so many years Google was able to hear users! Before this update I had to use two phones synching them manually.


so... the new feature is you can turn your 2FA into a 1FA google login...

if you think this is a good idea, i highly recommend you add a second 2FA device to the account you're worried about instead of... centralizing your "have" factor into a "know" factor.


If you are on the Apple ecosystem, I highly recommend OTP Auth [0]. Very friendly UI with encrypted cloud backup where you control the key.

[0] https://cooperrs.de/otpauth.html


Could you compare and contrast to Authy, which also offers that functionality?


Last I tried Authy I think it wanted me to create an account and give my phone number, so I noped out.


Haha, I just transferred them to a new device last week!

I will say that the previous migration path was super simple as well. The old device generates a number of QR codes that the new device scans, in sequence.


This would have been so useful three or four weeks ago. Good to have for the future I guess. Alas.

Google is pretty on top of things in terms of service updates on products that have core adoption / pmf.


Good move . for too long usability suffered .

most of these security protocols fail to scale . what happens when you have 30 tokens and you get a new device ?

many vendors are still requiring a phone call.

security without usability is just cosplay


I find it curious that they're continuing to develop it; when I found that Authenticator wasn't a 2FA option for my google account I figured it had been abandoned.


Two days later: Gmail spam detection auto deletes user's Google account and all of their synchronised keys. User looses their entire digital identity.


Another request -- let me archive them (instead of only delete).


True, or be able to keep them in folders. Imagine trying to manage your TOTPs if you, say, are a freelancer who does work for 25 different clients.


I recently had a broken phone replaced and had depended on a backup to have my TOTP keys on my new phone. It was not a part of the phone backup. :(


Same. Someone needs to make all this both secure and usable. For now, I'll even take "this is going to ruin your day but at least there's a standard and consistent way to deal with this" as usable, maybe we don't want anything easier than that for security reasons.


How about they support the algorithm parameter in the TOTP spec, rather than silently ignoring it and hard-coding hmacSha1?


Years ago, this might have mattered. But I have moved on. Now an authy user, and not sure why that should change.


I’ve been using Authy because it supports syncing to the cloud (encrypted with a key that you control).

Glad Google finally has this.


There are alternatives like aegis. People should just turn their backs on google auth all together.


Microsoft Authenticator has had backup for ages. Uses iCloud on iOS and pre-encrypts the info.


Well, not yet - just installed it and... there's nothing.


Too late. Switched to Authy the first time I got a new phone.


Why did it take so long? 2FA has been around for quite some time now. Was there a push back at Google? Or, just neglect?


In case anyone sees this, someone found this:

https://defcon.social/@mysk/110262313275622023

TL;DR don't use it as there is no encryption.


... and noscript/basic (x)html browsers ?

mmmmh....


Is this the same way Google Podcasts works, where I "have to" have "web, location, and usage history tracking" enabled to subscribe to a podcast? lol




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: