[HN Gopher] How does Google Authenticator work?
___________________________________________________________________
How does Google Authenticator work?
Author : ecliptik
Score : 114 points
Date : 2021-08-27 05:38 UTC (17 hours ago)
(HTM) web link (prezu.ca)
(TXT) w3m dump (prezu.ca)
| Donckele wrote:
| This could be a stupid question, why not just use the first few
| characters from the hash of the secret and the timestamp?
| duskwuff wrote:
| That's pretty close to what they're doing, with some small
| changes (using HMAC, measuring the time in 30-second intervals,
| and generating a numeric code).
| Jtsummers wrote:
| One of the requirements for HOTP (which TOTP is based on) was
| that the code should be numeric for phone entry or similarly
| constrained entry mechanisms.
|
| > R4 - The value displayed on the token MUST be easily read and
| entered by the user: This requires the HOTP value to be of
| reasonable length. The HOTP value must be at least a 6-digit
| value. It is also desirable that the HOTP value be 'numeric
| only' so that it can be easily entered on restricted devices
| such as phones.
|
| See R4 at https://datatracker.ietf.org/doc/html/rfc4226 (split
| across pages 4 and 5).
| cbdumas wrote:
| With that scheme an attacker who gets access to a code (no
| matter how old) can then generate their own going forward. The
| hash function here means that even if someone obtains a code
| they can't generate other codes.
| TimWolla wrote:
| One reason might be that those characters would include
| letters. A digits-only code is much easier to type, e.g. using
| a restricted keypad, such as a phone.
| tshaddox wrote:
| Don't all hashes start out as numbers anyway, before they get
| encoded as alphanumeric strings?
| jjeaff wrote:
| That's basically what they do. Most apps like Google
| authenticator use totp rather than hotp. The t stands for time,
| the h is hmac. Except they also use an algorithm to convert
| those characters to digits only. It's all described under the
| totp section.
| zaphirplane wrote:
| I wonder why credit card issuers haven't gotten on that idea.
| Whenever I use my credit card I have to enter a onetime /time
| based amount based pin.
|
| Rather than the system of anyone that knows my card number can
| charge whatever amount they like for however long they want
| [deleted]
| loloquwowndueo wrote:
| There's even a program called oathtool which you can use to
| generate TOTP and HOTP (counter-based and much more prone to
| skew) codes. You just need the random seed that's generated when
| you create a device. I'm not sure how easy it is to extract from
| the qrcode that web services generate, though. Some identity
| providers will show the raw random seed.
| composer wrote:
| oathtool -w1 --base32 --totp $secret
|
| Add a space before the command depending on your shell. Some
| shells will keep your secret out of history logs.
| Jtsummers wrote:
| https://github.com/google/google-authenticator/wiki/Key-Uri-...
|
| That's the format that gets encoded into the QR code. If you
| can decode the QR code you can get the secret key easily.
| jmcphers wrote:
| It's pretty easy to extract! zbarimg -q -raw <png> will do it.
|
| http://manpages.ubuntu.com/manpages/bionic/man1/zbarimg.1.ht...
| hannob wrote:
| AFAIR there isn't much to "extract", you simply use any
| application that can decode the QR code and you get the key
| which is encoded as a sequence of letters and numbers.
| karmicthreat wrote:
| I like using Yubico Authenticator. I have a primary and backup
| Yubikey and I copy the TOTP secret to both. Its also nice that
| the secret is kept on the key rather than my phone.
| codegeek wrote:
| One really good TOTP app for desktops is Authy [0] from Twilio.
| Some people are not aware that it exists and you don't need an
| app on your phone for TOTP. Authy works from your desktop as
| well.
|
| [0] https://authy.com/download/ (scroll down to see Desktop
| version for download)
| commoner wrote:
| Hard no from me.
|
| I remember when Authy refused to delete my account, prior to
| their acquisition, despite promising to do so upon request in
| their terms of service. I wasn't the only one:
| https://news.ycombinator.com/item?id=9100525
|
| There are plenty of free and open source TOTP authenticators
| (that don't require you to provide your phone number), and I
| don't see a good reason to use Authy over them.
| thaumasiotes wrote:
| What's the concept behind having an Authy account? It
| converts a TOTP seed into a time-based TOTP code. No part of
| that suggests that you'd need an account.
| ncann wrote:
| What about this link? Seems pretty straightforward to delete
| an account for me:
|
| https://authy.com/account/delete/
| commoner wrote:
| Good to see that they added an account deletion page some
| time between their acquisition and now. However, that
| bridge has already been burned for me and I'll be sticking
| with Bitwarden (self-hosted using Vaultwarden) for TOTP.
| Bitwarden doesn't require my phone number.
| remuskaos wrote:
| There is also Aegis[1]. It's FOSS and available in F Droid and
| Play Store. Authy is pretty good, but doesn't support export of
| the secrets used for TOTP, whereas Aegis supports export to
| json and GPG encrypted json.
|
| I've been using Authy for a few years, but switched to Aegis
| about three years ago and couldn't be happier. Since Authy
| doesn't support direct export of the secrets, I've had to use a
| workaround [2].
|
| [1] https://getaegis.app/ [2]
| https://gist.github.com/JacobJohansen/5f688d45049be440b8ee87...
| saganus wrote:
| I was interested in using Aegis, but unfortunately I can't
| import my current keys from Google Authenticator.
|
| It's "supported" but only via accesing the Authenticator's
| files (or by havitng root access) which in my celphone is not
| possible (OnePlus Nord).
|
| Weirdly enough, Aegis does not support bulk importing keys
| from a QR code, which is how you can migrate from one
| Authenticator instance to another (e.g. to a new phone).
|
| And I am too lazy to go over each key, reset it and load it
| up again in Aegis.
|
| Hooefully they'll add this feature at some point in the
| future.
| sebazzz wrote:
| For those with a Yubikey, those people can use Yubikey
| Authenticator on both mobile and desktop.
| robertlagrant wrote:
| Interesting! I didn't know that. Pretty handy for corporate
| stuff - keep the 2FA on the work computer.
| banana_giraffe wrote:
| On the topic of TOTP apps, I like "OTP Auth" for iOS devices.
| It's fairly simple, and offers an Apple Watch client that works
| well.
| jumelles wrote:
| Seconded, OTP Auth is really nice. It also syncs via iCloud
| and you can export your info easily.
| 0x0 wrote:
| Yep, the Apple Watch app is a killer app!
| tzs wrote:
| Authy also works on Apple Watch. I've found it very difficult
| to get Siri to understand "open Authy". It usually ends up
| saying there is no app name "oathy".
|
| Spelling it out usually works: "open A U T H Y".
| thaumasiotes wrote:
| Do you pronounce "authy" and "oathy" the same way? I'd expect
| "authy" to use whatever vowel you use for "c _au_ ght", not
| the vowel of " _au_ revoir ".
| foxtacles wrote:
| I can recommend oathtool (in combination with GPG) on the CLI:
| https://www.nongnu.org/oath-toolkit/oathtool.1.html
| jcims wrote:
| You can also roll your own with https://github.com/pyauth/pyotp
| codetrotter wrote:
| > roll your own
|
| Libraries for a couple of other languages:
|
| https://crates.io/search?q=4226
|
| https://pkg.go.dev/search?q=4226
| tyingq wrote:
| It's almost overkill to bother with a library.
| #!/usr/bin/env python3 import time, hmac, base64,
| struct def totp(seed,curtime,period,len): k =
| base64.b32decode(seed) mac = hmac.new(k,
| struct.pack('>Q', int(curtime/period)), 'sha1').digest()
| offset=mac[-1] & 0x0f otp=struct.unpack('>L',
| mac[offset:offset+4])[0] & 0x7fffffff return
| str(otp)[-len:].zfill(len)
| myseed='KRUGS4ZANFZSAYJAOJQW4ZDPNUQHG5DS' # use gpg or
| similar to store print(totp(myseed,time.time(),60,6))
| conductor wrote:
| Also, KeePassXC[0] (a password manager) has integrated TOTP,
| which is very handy.
|
| [0] https://keepassxc.org/
| sureglymop wrote:
| Wow really? I never knew that, I've been using andOTP.
| Unklejoe wrote:
| Does Google itself support TOTP with Google Authenticator? When I
| try to enable 2FA, the only options seem to be a text, call,
| security key (I'm guessing this is FIDO?), and "get a
| notification on your device".
| seanwilson wrote:
| You know in Authy (Google Authenticator is similar here?) when
| there's only 10 seconds or so left to type in the current code so
| you wait for the next one to appear? Could it not show the next
| code instead if there wasn't much time left and the app you're
| authenticating with could accept the current or next code? Feels
| like an obvious annoyance that's fixable.
| JyB wrote:
| Try it. They'll still work if the server side is implemented
| properly. The server will be lenient on the timestamps.
| pmlamotte wrote:
| Showing two codes would definitely be a nice opt-in feature.
| Servers generally will compute codes within a sliding window to
| account for time sync discrepancies so there wouldn't be much
| harm. I could see how it may be confusing to some end users
| though.
| pgalvin wrote:
| This is mostly a non-issue - services usually accept the
| current, previous and next TOTP code to account for devices
| having a slightly incorrect clock.
|
| I've never had an Android device that keeps its clock in sync,
| for example, so they had to address this.
| b3morales wrote:
| The server sides are typically set up with some flexibility to
| account for the latency and avoid this UX issue. They will have
| a window to accept the previous/next code even after the new
| becomes active.
|
| To avoid replays, though, this should be reset once a code is
| accepted: only subsequent codes should be accepted afterwards.
|
| So when code N is the "correct" code, any of N-1, N, or N+1
| will be accepted. But if N is entered, only N+1 and onwards
| should be accepted for later attempts.
| anchpop wrote:
| I've thought about that too. It should always show two codes
| (the current one and the previous one), and websites should
| accept both. Then when you open the app, you can always start
| typing the most recent one and have at least the whole interval
| to type it in
| kccqzy wrote:
| Servers generally have no problem accepting an expired code, if
| the code is only expired for a few seconds.
| [deleted]
| ecesena wrote:
| Codes are typically valid for 3-5min even if the display only
| shows 1min. This is to avoid issues with time discrepancy on
| client/server, and doesn't really make a big difference in
| terms of security, feel free to try it out.
|
| So, to fix your issue, just use the current code even if it
| seems expired.
|
| As a side note, it's important to enforce that each code can
| only be used once. Authy (the server-side service) does that,
| but many "roll your own" TOTP solutions don't verify this.
| JyB wrote:
| Not sure how that's relevant to the parent.
| tialaramex wrote:
| A _good_ implementation of this protocol remembers that it saw
| this code and won 't let anybody re-use it. For example suppose
| I am standing behind Sarah as she logs in to her bank and I
| happen to already know that her "Favourite carebear" was
| "Birthday Bear" even though that's not displayed on screen, and
| I see she types 123 456 as the TOTP code.
|
| If I am very quick and try to also log in to her bank with
| "Birthday Bear" and 123 456 that _shouldn 't_ work even though
| that's still the "right" code for the next few seconds. The
| bank login should tell me that I need to wait and enter the
| next code. I can't see Sarah's next code because she's done and
| put her phone away.
|
| RFC 6238 says of this: "The verifier MUST NOT accept the second
| attempt of the OTP after the successful validation has been
| issued for the first OTP, which ensures one-time only use of an
| OTP."
| McTossOut wrote:
| Depends on the day
| jrm4 wrote:
| Good stuff. One pernicious "lie through technology" that is out
| there is that TOTP et al are something special that must be done
| through some sort of secret or proprietary app or worse, hardware
| key device.
|
| Nothing wrong with having these as an option -- but e.g. recently
| my workplace mandated using Duo (the 2FA thing, not google) for
| our 2FA stuff -- which doesn't let you keep your own generating
| keys. It's literally the _only_ 2FA thing I have that won 't let
| you do this, and its infuriating because I use oathtool for all
| the others.
|
| And this is at a university -- so effectively this means you must
| have a modern cell phone with a particular app or buy a dongle or
| you can't do school.
| thaumasiotes wrote:
| > One pernicious "lie through technology" that is out there is
| that TOTP et al are something special that must be done through
| some sort of secret or proprietary app or worse, hardware key
| device.
|
| It's a lie, but you only have a second factor if it's true.
| Your Duo is attempting to deliver what it promises, where
| Google Authenticator doesn't even make the attempt.
|
| You can extract the secret directly from the app, though, if
| you have the option to use it as an app.
| [deleted]
| sleavey wrote:
| I found this part interesting:
|
| > Notice that when the key is, say, 40 bytes long, it's padded
| with zeros to make it 64 bytes long. So the actual entropy of
| that key is equivalent to the 40-byte long key. But if the key is
| longer than 64 bytes, it's effectively being shortened to 20
| bytes. So its entropy is lower. If you want to maximize the
| complexity of the key, and you're the one choosing the key, go
| for something around, but never more than, 64 bytes.
|
| Perhaps that's why some sites have a maximum character limit for
| passwords. (Although I suspect many are just doing it wrong.)
| wyager wrote:
| There is no sound technical or security justification for
| having a maximum character limit, up to some obscenely long
| limit to prevent the user wasting server resources by
| submitting giant forms.
|
| Also, no one should be using raw HMAC to do password checking.
| At the very least use something like PBKDF2.
| trinovantes wrote:
| At this point, I just automatically assume any website that
| has a maximum character limit and weird character
| restrictions is storing the password in plaintext
| jaywalk wrote:
| Sometimes the character restrictions are due to overly
| aggressive web application firewalls.
| akerl_ wrote:
| This article is overall a nice breakdown of how TOTP/HOTP
| function. My only concern is that it seems to connect the
| "counter" (time in the case of TOTP) with salting. Salting of
| passwords is targeted towards a totally different problem. The
| HMAC functions here don't take a salt, they take a secret and
| what the RFC calls a "moving factor". It exists intentionally to
| allow the resulting calculation to change over time in
| unpredictable (to an attacker) ways.
| LeoPanthera wrote:
| Google Authenticator is an implementation of the catchily-named
| "Time-based One-Time Password" or TOTP.
|
| https://en.wikipedia.org/wiki/Time-based_One-Time_Password
|
| It is not the only one, any time a site asks you to add a "Google
| Authenticator" code you can use any TOTP app. 1Password has the
| functionality built in, for example.
| judge2020 wrote:
| Unfortunately, Stripe does this currently:
| https://i.judge.sh/youthful/Derpy/chrome_TIDNqlcRvI.png
| tshaddox wrote:
| I use 1Password for all of my MFA codes on the web. It's
| extremely convenient to have them synced across all my devices,
| but I can't help but think that having my passwords and my MFA
| private keys stored in the same place almost entirely defeats
| the purpose of multi-factor authentication.
| jeromegv wrote:
| If your passwords are leaked in a data leak, they still
| wouldn't get your 2FA. So I wouldn't say it _entirely_
| defeats the purpose of 2FA.
| tshaddox wrote:
| If they stored my password in plain text, I'm not sure I
| would trust their 2FA implementation to actually function
| as a second factor to protect my account. :) Seriously
| though, isn't this a little like saying that a website
| could have two passwords on each account so if they suffer
| a data leak that happens to leak only one of your
| passwords, that wouldn't be enough to access your account?
| [deleted]
| tialaramex wrote:
| Depending on the leak, the secret that drives TOTP could
| also be in the same database table (or a nearby one). This
| means anybody with that secret can trivially run the TOTP
| algorithm and get the correct six digit code for any time
| present or future.
|
| If you care about MFA that can survive leaks, you want
| WebAuthn. As with phishing this known problem was
| considered in the design of WebAuthn and so your WebAuthn
| credentials aren't designed to need to be secret.
|
| In fact here you go, here are WebAuthn credentials for a
| vanity system I own, copied out of its authentication
| database:
|
| ID: AXnUJ920FfJlRjZtocN+9Bc9IP6gvsBiWA3GfJxckh3nQ/KekQ6xB2b
| yfI2GM7IcGS2MpzxZs6IHmAxvgAcE/Mw= Public key: pQECAyYgASFYI
| Ff0iDSfNpYNA5Br9zXSIUH69BqyvFcgbqy6tWC8rsLwIlggCDqury9UOzI1
| DnOFyE3aYwaBLvP0NyNez98v0TcieKs=
|
| That's all the backend needs to check I'm really me, and
| yet it's also _completely useless_ to an attacker, they can
| 't even use it to compare across sites and "unmask" me.
| easton wrote:
| There is still a little bit of a point, as it guarantees the
| password came out of 1Password and wasn't from somewhere
| else. If someone screencapped your password out of 1Password,
| it wouldn't of use unless they could get into your vault
| somehow.
| kaladin-jasnah wrote:
| Have to chime in but my favourite authenticator is andOTP.
| Seems to be FOSS as well since it's on F-Droid[0] and I hear it
| has good support from migration from one phone/ROM to another.
|
| [0]
| https://f-droid.org/en/packages/org.shadowice.flocke.andotp/
| teekert wrote:
| AndOTP is really nice. It is the one thing I miss on iOS. On
| iOS there does not seem to be any totp apps that can just
| export their db as an encrypted file (or unencrypted if you
| so choose). So in Apple land I'm stuck with MS Authenticator,
| coincidentally my only app that needs iCloud (I really want
| it backed up).
| commoner wrote:
| Raivo is an iOS TOTP authenticator that is open source and
| supports exports. Hopefully, this is what you're looking
| for:
|
| https://apps.apple.com/us/app/raivo-otp/id1459042137
|
| https://github.com/raivo-otp/ios-application
| slim wrote:
| My favorite is Android Token because it's only 67 kb and it
| has everything including qrcode scanning :) check it on
| fdroid
| willis936 wrote:
| You can even convert TOTP from 2FA into 1.5ish FA by using a
| password manager that stores the TOTP secret and generates the
| TOTP key from it.
| Godel_unicode wrote:
| An adversary still has to get the manager DB and the key to
| unlock it (your password manager DB is encrypted with a key,
| right?).
| willis936 wrote:
| What's the point of using a key? That doesn't add a second
| factor of authentication. Something you have and something
| else you have is 1FA.
|
| A password with more than 200 bits of entropy seems
| reasonable.
| maxerickson wrote:
| They key doesn't particularly increase the security of
| the authentication, but it helps a bit if you lose
| control of the device the db is stored on.
| akerl_ wrote:
| The author seems to address this directly:
|
| > But here we're focusing on apps like Google Authenticator
| that use something called TOTP algorithm.
|
| > What we want to achieve is understand how apps like Google
| Authenticator (or any other TOTP app) are solving that?
| ocdtrekkie wrote:
| It's truly and deeply frustrating to me how many sites and
| services push "Google Authenticator" branding instead of
| specifying that it's TOTP or that literally any good 2FA app
| will work. It's almost to that "Google" = "search" level, but
| for a more niche aspect.
| ezekg wrote:
| I'm not sure why you're being down voted, but I agree. I've
| had several discussions where people think Authy is
| incompatible with sites that prompt for Google Authenticator,
| like it's some special more-secure TOTP app.
| loloquwowndueo wrote:
| Back in the day it was the best-known and most reliably
| available cross-platform (iOS, android) code generator - so
| many sites just assume it as a de facto standard. It also
| reduces support burden to tell people this is the officially
| supported code generator, that way you don't need to struggle
| understanding why a random app might be having trouble with
| codes.
|
| These days it's much less of an issue as there are many more
| clients - the IdP I manage now mentions authy, tofu and
| 1password as also supported.
| tinus_hn wrote:
| Also Google Authenticator does not allow you to include
| your codes in your backup, even when it's encrypted. So due
| to Google Authenticator, losing your 2fa codes is an
| expected problem and many companies allow you to reset it
| by simply calling them.
|
| It sounds really secure but it really is not.
| unclebucknasty wrote:
| It's about the perception of security and reducing friction.
| Everyone knows Google, so you don't have to convince users of
| the trustworthiness of a lesser-known brand or open source
| project within the sensitive context of increasing security.
| fraa-orolo wrote:
| Have you seen users? I have to convince users _not_ to
| install random crap.
| tialaramex wrote:
| Microsoft's stuff all wants you to install the Microsoft
| Authenticator which needs a Microsoft account for some reason
| and that (for me anyway) then immediately wanted me to setup
| 2FA, for which it required me to install the Microsoft
| Authenticator, which ... you can see how that goes.
|
| As I began to experience Deja vu on the first day of a new
| job I snapped out of it, removed the Microsoft Authenticator
| and told it nah, I'm OK actually, show me that QR code for
| "other authenticators" and never looked back.
| jaywalk wrote:
| Microsoft Authenticator is more than just TOTP, which is
| why it wants a Microsoft account. It also supports push
| approvals.
| animex wrote:
| In Fortune 1000 land, Microsoft Authenticator rules the land.
| I love it because most have implemented notification push-
| authentication with biometric verification. Some sites will
| use that in lieu of any password at all.
|
| The worst is when separate apps & companies roll their own
| authenticator app.
| maximum_stress wrote:
| As well it should. It's rare for me to defend Microsoft
| anything, but in this case I will. MS authenticator happily
| backs itself up to the cloud if you let it. Whether you
| consider that good or just another attack vector is up to
| you, but keep in mind if you switch phones, you'll be
| setting up TOTP again for every service in Google
| authenticator.
| filoleg wrote:
| For me personally, Microsoft Authenticator started ruling
| as well recently, after 5+ years with Google Authenticator.
| Why? I have already mentioned it in other comments before,
| and it is due to Google's insistence on not implementing
| recovery from backup.
|
| If i store my 2FA in google authenticator and something
| happens to my phone? I am in a world of serious pain. If i
| upgrade phones? I have to disable and re-enable 2FA on my
| new phone manually for every single service I use.
|
| Microsoft Authenticator solves both of those problems, as
| they have recently (less than a year ago iirc) added a
| "backup to cloud" feature. No more stressing about
| something happening to my phone, as long as i have my
| (single) primary recovery key stored on a piece of paper
| somewhere safe (as opposed to having a paper recovery key
| for every 2fa service i use).
|
| Prior to this, i was seriously considering getting a cheap
| backup phone to which i set up all the 2fa codes
| simultaneously with my main phone, then put that cheap
| phone in a bank cell/safe/etc., and then rely on it in case
| something happens to my main phone. That would still not
| solve the problem of manual transfer and disabling/re-
| enabling 2fa for every single service, but that would be
| much better than losing the device.
|
| Note: I know Authy exists and had this functionality of
| cloud syncing 2FA keys between logged in devices for years,
| but for some irrational reason i was sticking with the
| "simpler is better, and i somehow trust google more with
| this one", but luckily, I trust MSFT with my 2FA no less
| than i would google, perhaps even moreso. And the biometric
| 2FA for services that support it (so far, I've only seen it
| used with certain corporate MSFT services) are a nice
| cherry on top.
| isbvhodnvemrwvn wrote:
| Google Authenticator has added account transfer at some
| point in the recent couple years - you get a QR code that
| you can scan on another device to transfer stuff. It's
| not automated backup, but it makes migration to new
| devices easier.
| akersten wrote:
| Can I print that QR code and stuff it in a safe to scan 3
| years from now, or does it expire? It isn't clear from
| the export screen.
| unclebucknasty wrote:
| > _Can I print that QR code and stuff it in a safe to
| scan 3 years from now, or does it expire?_
|
| Given the protocol/algorithm, it shouldn't expire.
| remus wrote:
| I'm pretty sure the QR codes actually encode your secrets
| so if you want to print them out you're good to go.
| Obviously won't include any new ones you add in in the
| meantime though.
| filoleg wrote:
| This is only for Google-specific services that use 2FA
| (and it works with any authenticator apps, not just
| Google Authenticator, because this functionality is
| dependent on the service, not the app).
|
| So if I try to do this for my Google account 2FA (with
| Google Authenticator, Microsoft Authenticator, or
| literally any other authenticator app), it works. But it
| won't work for any of my other 2FA accounts, like MSFT,
| Discord, etc., no matter which authenticator app I use.
|
| To your defense, Google Authenticator added the option
| for restoring from local backup fairly recently, but only
| for Android. And even then, no ability to sync it with
| multiple devices.
| koolba wrote:
| > Microsoft Authenticator solves both of those problems,
| as they have recently (less than a year ago iirc) added a
| "backup to cloud" feature.
|
| Is this to the same cloud that Microsoft gives unfettered
| access to all its customer's Cosmos DB data?
|
| 2FA backups are fine but they need to be onto local,
| offline, disks. Automated cloud backups that can be
| decrypted at rest are no longer "something _only_ you
| have".
| filoleg wrote:
| It isn't "the same cloud" that you were talking about, it
| is iCloud.
| JumpCrisscross wrote:
| > _If i store my 2FA in google authenticator and
| something happens to my phone? I am in a world of serious
| pain_
|
| On iOS, you can back up Google Authenticator. It then
| restores with your 2FA codes intact. (I don't do this,
| because I feel it weakness 2FA's security and am decent
| about saving recovery codes. But everyone's tolerance for
| B.S. is different.)
| filoleg wrote:
| > On iOS, you can back up Google Authenticator. It then
| restores with your 2FA codes intact.
|
| Source needed. I just opened Google Authenticator on iOS,
| and it isn't an option. Googling confirmed that it isn't
| supported on iOS.
|
| If you try to restore the phone from the backup (whether
| iCloud or local backup), it will restore the app, but it
| will have no 2FA codes present.
| JumpCrisscross wrote:
| > _I just opened Google Authenticator on iOS, and it
| isn't an option_
|
| Why would it be an option in the app? Go to your phone's
| backup settings and select Google Authenticator. When I
| had this on, it worked. (It might have since changed.)
|
| Google being Google, there is zero reliable documentation
| on anything, but here's a community thing from a few
| years ago [1].
|
| [1] https://support.google.com/mail/forum/AAAAK7un8RUcSLd
| 5H1MpO4...
| pilsetnieks wrote:
| On the one hand, I agree but on the other, this is _the_ one
| case where you cannot take any chance of having your user
| install some random dodgy app that promises the same
| functionality.
___________________________________________________________________
(page generated 2021-08-27 23:00 UTC)