How does Google Authenticator work?
prezu.ca
prezu.ca
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.
> 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?
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.
It sounds really secure but it really is not.
The worst is when separate apps & companies roll their own authenticator app.
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.
Given the protocol/algorithm, it shouldn't expire.
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.
I recently changed phones from Android to iOS and the export/import from Google Authenticator was fine for non-Google services.
Edit: I think there was a bug where it seemed to only export the tokens visible on the page, so I had to scroll and do it again for additional tokens. Maybe you are hitting that.
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”.
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.)
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.
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/AAAAK7un8RUcSLd5H1MpO4...
My understanding is that iCloud backup is specified by the user per app (can default to on). Going into my iPhone->Settings->Authenticator there are no iCloud settings and iPhone->Settings->iCloud shows lots of apps but Authenticator is not one of them.
I have iCloud backup on, have switched through at least 2 phones (as in 6+->10->11) where I have Google Authenticator on. The new phone never had any of the Authenticator codes after restoring yet all the other apps restored their data.
As I began to experience Déjà 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.
Not entirely sure I like these "authenticate on from another device". Just yesterday I mis-placed my phone. I wanted to sign into iCloud.com for use "find my phone" feature from my PC. It required me to use apple's authentication via a code sent to the phone, the exact thing I was looking for! :(
A password with more than 200 bits of entropy seems reasonable.
Secondly, many password vaults refer to the master password you use to unlock it as the key.
Thirdly, many security keys require a pin or similar to be used.
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/KekQ6xB2byfI2GM7IcGS2MpzxZs6IHmAxvgAcE/Mw= Public key: pQECAyYgASFYIFf0iDSfNpYNA5Br9zXSIUH69BqyvFcgbqy6tWC8rsLwIlggCDqury9UOzI1DnOFyE3aYwaBLvP0NyNez98v0TcieKs=
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.
What happens if you lose that device, or if it fails?
Keep passwords on browser, and MFA on phone.
If my browser / desktop got compromised, someone would still need my phone to access my accounts.
[0] https://f-droid.org/en/packages/org.shadowice.flocke.andotp/
The license [1] says:
> Modification, duplication or distribution of this Service (in source and binary forms) for any purpose is strictly prohibited.
[1]: https://github.com/raivo-otp/ios-application/blob/master/LIC...
Safari on macOS (at least in Monterey) offers a bulk export option, which can export all your passwords to an unencrypted CSV file. The information includes URL, username/email, password, and an "OTPAuth" column. For GitHub (the only account I've enabled native TOTP for while the feature is still in beta) the entry in that column looks like this:
> otpauth://totp/github.com:<username>?secret=<secret>&issuer=github.com&algorithm=SHA1&digits=6&period=30
So I'm not sure if that would be directly importable to another service, but at the very least you get the secret and so could transfer the data account-by-account if you had to.
oathtool -b --totp `pass show <X>`
... for <X> in github, gmail, blizzard, whatever ...
This way, you can have a backup in case your phone gets lost, and easily port between phones.
https://github.com/tadfisher/pass-otp
That gives you "pass otp github.com", etc. You can also export the QRcode, and do similar things.
I put together a simple distribution of pass with a couple of plugins I use, including otp, which is easy to setup - just clone beneath `/opt/pass`:
import onetimepass as otp
my_secret = ''
my_token = otp.get_totp(my_secret)
print my_tokenYou need a library like that and a way to convert an otp:// url into a QR code, for which there are many libaries as well. The rest is just implementing a sane UX around this. Storing the user's TOTP secret server side is a bit tricky. I suspect a plain text field in a database is quite common for this; which of course would be disastrous if that database were ever stolen. Secret stores don't scale for this as they tend to be designed for just a handful of secrets. We ended up encrypting these totp secrets using a key from our secret store.
[0] https://authy.com/download/ (scroll down to see Desktop version for download)
Libraries for a couple of other languages:
#!/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))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.
You've got a strange definition of "backup" if you think it won't work after the subject of the backup has been destroyed. What would be the point of a backup that stopped working whenever you needed it?
Spelling it out usually works: "open A U T H Y".
Pronouncing "au" like the "ou" in "ouch" seems to be about the best, but then it tends to mess up the other end, thinking I want "authi". Sometimes it even think "alfie". Somehow it even occasionally hears "elsewise" or "offline". I have no idea how it gets those.
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...
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.
Aegis does support importing from Google authenticator, it just doesn't make that very clear. You do it the same way you add any other code. The hard part for me was getting the QR code into scannable form. This issue explains one way, but you can also just take a picture of the phone with another device.
I now use Aegis on phone and the otp plugin of pass on my Linux desktops (+ a ulauncher plugin).
https://github.com/tadfisher/pass-otp
Like others have mentioned, it unlike Authy this doesn't use your phone number as identity
To counter this I recommend disabling device sync in Authy, and only enabling it temporarily when you add a new device.
> 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.)
Also, no one should be using raw HMAC to do password checking. At the very least use something like PBKDF2.
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.
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.
Last sentence? Serious question. Can you? I was just presuming that you can't; i.e. if I were to build a freedom-reducing proprietary solution like this, I'd keep the the key on my home servers and only deliver the 6 digit codes?
I’ve never had an Android device that keeps its clock in sync, for example, so they had to address this.
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.
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.
Codes are typically valid for 3-5min [...] just use the current code even if it seems expired
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."
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.
http://manpages.ubuntu.com/manpages/bionic/man1/zbarimg.1.ht...
oathtool -w1 --base32 --totp $secret
The main differentiator is that this a web-based authenticator, not an app-based one. The main goal being a fully separate service (thus full separation of concerns) from a password manager. It's not ready for prime time yet, but if you are interested to test it, please reach out.
Really poorly. Not only my experience, also the prevailing sentiment in app store reviews, where it has a sub-2.5 star rating.
Up until pretty recently you couldn't even back up your passcodes, so it was extremely risky to use it.
Use Authy, there is clearly a lot more effort put into that app.
Rather than the system of anyone that knows my card number can charge whatever amount they like for however long they want
# python3 -m pip install pyotp
SECRET='JBSWY3DPEHPK3PXP' python3 -c "import pyotp; print(pyotp.TOTP('${SECRET}').now())"> 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).