How does Google Authenticator work?(prezu.ca)
prezu.ca
How does Google Authenticator work?
https://prezu.ca/post/2021-07-30-totp-1/
164 comments
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?
> 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?
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.
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.
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.
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.
It sounds really secure but it really is not.
Google Authenticator has a feature to allow export of all saved codes into one QR code for re-import into Google Authenticator running on another device. I printed a copy of my export QR code for use in case my device is lost or stolen.
Thanks! I hadn't seen that feature. Just checked it out. It shows multiple QR codes (in my case 2 QR codes which contain 11 TOTPs total) that you can scan from another device running Google Authenticator to transfer to codes. I guess I can screenshot those QR goes to back up (scary)
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.
The worst is when separate apps & companies roll their own authenticator app.
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.
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.
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.
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.
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.
>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.
Given the protocol/algorithm, it shouldn't expire.
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.
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.
That doesn't make much sense to me. If the app has the state necessary to generate TOTP codes, why couldn't it transfer that state to a different device? How could it be dependent on the service?
This isn't the case.
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.
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.
> 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.)
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.)
> 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.
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.
> 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/AAAAK7un8RUcSLd5H1MpO4...
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...
Are you sure this actually works?
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.
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.
Exact same experience. The app backs up into icloud and gets restored on backup restore just fine. But no 2FA codes are present after restoring, so I had to enter them manually.
Settings->User->iCloud->Manage Storage->Backups.
> 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”.
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”.
It isn’t “the same cloud” that you were talking about, it is iCloud.
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 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.
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.
Microsoft Authenticator is more than just TOTP, which is why it wants a Microsoft account. It also supports push approvals.
I'm a little surprised Google hasn't don't this but I guess they have give gmail. Sign into google and it will ask me to approve on my gmail app.
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! :(
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! :(
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.
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.
Have you seen users? I have to convince users not to install random crap.
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.
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.
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?).
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.
A password with more than 200 bits of entropy seems reasonable.
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.
Yeah but a key without a second factor (something you know) is still better than a key. Just make sure your password isn't brute forceable.
Firstly, while that's technically correct according to the CISSP, it's obviously not actually correct. Two different things I have can absolutely be two factors as long as they are not susceptible to the same method of compromise. 1+1=2.
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.
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.
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.
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.
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/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.
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.
WebAuthn is great. Put it to work recently in a new control system and it sure is a nice feeling to deploy with zero need for passwords.
I had a quick look on wikipedia about how webauthn works, looks like you use a hardware (USB?) device to sign something with the PIN you enter.
What happens if you lose that device, or if it fails?
What happens if you lose that device, or if it fails?
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]
1Password had a blog post [1] addressing this concern. Essentially you still have the benefit of one-timeness, but not second factor, and need to compare that to what your security needs are.
[1] https://blog.1password.com/totp-for-1password-users/
[1] https://blog.1password.com/totp-for-1password-users/
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.
I use LastPass for password sync and Authy for 2FA. Feels a bit safer having them seperate.
Google Authenticator allows you to sync passwords between devices these days. Fairly recent(ish) and long overdue update.
Isn't it just one time export which by function of TOTP is synced and not an actual sync like in 1Password? i.e. Only the accounts which were available when you exported would be there in another device.
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/
[0] https://f-droid.org/en/packages/org.shadowice.flocke.andotp/
Mine is aegis.. it's on f droid, completely open source, let's you backup your secrets so changing phones isn't a pita
Seconding Aegis, it's great.
andOTP does all of that too and was out before Aegis. What does it have over andOTP?
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).
FWIW, iOS 15 lets you put a TOTP secret right into the saved password entry on your phone, and it will autofill the code just like it autofills your password.
Will I be able to export? When I moved to iOS, AndOTP saved me because I could copy paste all personal keys from AndOTP to MS authenticator. This will probably lock me in…
On iOS each password item in Settings.app has a "Share" button that lets you AirDrop to another device. I don't see another way to export from iOS.
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.
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.
given Apple's new spying stance I'm not sure I want to allow the to store my passwords
May not make a difference if you don’t take Apple at their word but iCloud Keychain is among the services/data encrypted end-to-end[1] and there’s no exception mentioned for iCloud backup (like there is for Messages).
[1]: https://support.apple.com/en-us/HT202303
[1]: https://support.apple.com/en-us/HT202303
There is Tofu. It doesn't export, but it does back up to iCloud, fwiw.
https://www.tofuauth.com/
https://www.tofuauth.com/
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
https://apps.apple.com/us/app/raivo-otp/id1459042137
https://github.com/raivo-otp/ios-application
To add something about this app, I know that people understand “open source” to mean different things. In the case of Raivo, the app is a “source available” one. It’s not FOSS.
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...
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...
You're 100% right. Raivo is source-available, but not free (libre) or open source. I found it through a forum post and neglected to check the license.
My favorite is Android Token because it's only 67 kb and it has everything including qrcode scanning :) check it on fdroid
Unfortunately, Stripe does this currently: https://i.judge.sh/youthful/Derpy/chrome_TIDNqlcRvI.png
You can use oathtool if you'd like to "do it yourself". I usually just keep (encrypted with Pass) my secret keys for Authenticators, and execute a one line alias:
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.
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.
If you're using pass already you could use their OTP plugin:
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`:
https://github.com/skx/pass
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`:
https://github.com/skx/pass
Great tip thanks!
at one point i used a python script to provide a totp response to google when using youtube-dl (before logging in became broken and had to switch to cookies)
import onetimepass as otp
my_secret = ''
my_token = otp.get_totp(my_secret)
print my_tokenIt's really easy to integrate into websites as well. I did so a few years ago. The TOTP algorithm is just a few lines of code. I adapted this implementation https://github.com/j256/two-factor-auth at the time. There are similar libraries available for lots of languages.
You 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.
You 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.
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.
Raivo OTP for iOS does something similar where it displays the previous code (greyed out) too after it has expired. Convenient for when the time runs out while you enter the code, as others mentions there is often some leeway on the token expiry time.
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.
I’ve never had an Android device that keeps its clock in sync, for example, so they had to address this.
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.
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.
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
Servers generally have no problem accepting an expired code, if the code is only expired for a few seconds.
[deleted]
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.
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.
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.
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."
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."
Try it. They'll still work if the server side is implemented properly. The server will be lenient on the timestamps.
[deleted]
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.
This could be a stupid question, why not just use the first few characters from the hash of the secret and the timestamp?
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).
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).
> 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).
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.
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.
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.
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.
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.
It's pretty easy to extract! zbarimg -q -raw <png> will do it.
http://manpages.ubuntu.com/manpages/bionic/man1/zbarimg.1.ht...
http://manpages.ubuntu.com/manpages/bionic/man1/zbarimg.1.ht...
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.
oathtool -w1 --base32 --totp $secret
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.)
> 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.)
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.
Also, no one should be using raw HMAC to do password checking. At the very least use something like PBKDF2.
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
Sometimes the character restrictions are due to overly aggressive web application firewalls.
Setting a reasonable limit closes off a potential DoS vector. That's why our security team had us add a limit. (Sure, in practice rate limiting should also be in place, defense in depth.)
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)
[0] https://authy.com/download/ (scroll down to see Desktop version for download)
Interesting! I didn't know that. Pretty handy for corporate stuff - keep the 2FA on the work computer.
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.
You can also roll your own with https://github.com/pyauth/pyotp
> roll your own
Libraries for a couple of other languages:
https://crates.io/search?q=4226
https://pkg.go.dev/search?q=4226
Libraries for a couple of other languages:
https://crates.io/search?q=4226
https://pkg.go.dev/search?q=4226
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))True, I also type this in from memory whenever I need a quick TOTP calculation.
I can recommend oathtool (in combination with GPG) on the CLI: https://www.nongnu.org/oath-toolkit/oathtool.1.html
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.
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.
What about this link? Seems pretty straightforward to delete an account for me:
https://authy.com/account/delete/
https://authy.com/account/delete/
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.
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.
It means getting access to your 2FA codes on a new device is as straightforward as installing the app and signing in. Other commenters have mentioned authenticator apps that let you transfer the codes by initiating a backup or generating a QR code, but that won't work if the previous device is at the bottom of a lake.
> authenticator apps that let you transfer the codes by initiating a backup or generating a QR code, but that won't work if the previous device is at the bottom of a lake.
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?
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?
That depends on whether the backups are automatic and ongoing, or if they're the "scan this QR code to transfer to a new device" type. The former will be fine if the original device is lost, the latter will not be.
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".
Spelling it out usually works: "open A U T H Y".
Do you pronounce "authy" and "oathy" the same way? I'd expect "authy" to use whatever vowel you use for "caught", not the vowel of "au revoir".
I've tried a variety of pronunciations. Trying for "au" as in "caught" got me "healthy" and once it opened PCalc(?!).
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.
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.
Also, KeePassXC[0] (a password manager) has integrated TOTP, which is very handy.
[0] https://keepassxc.org/
[0] https://keepassxc.org/
Wow really? I never knew that, I've been using andOTP.
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...
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...
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.
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.
https://github.com/beemdevelopment/Aegis/issues/701
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.
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.
interesting, i migrated from authenticator, but did it 1 at a time. Check out andOTP, another great open source alternative, maybe it has these features.
I deleted my Authy account after the acquisition. The deletion process was a bit of a struggle for reasons I don't recall clearly.
I now use Aegis on phone and the otp plugin of pass on my Linux desktops (+ a ulauncher plugin).
I now use Aegis on phone and the otp plugin of pass on my Linux desktops (+ a ulauncher plugin).
There's also an TOTP pass extension.
https://github.com/tadfisher/pass-otp
Like others have mentioned, it unlike Authy this doesn't use your phone number as identity
https://github.com/tadfisher/pass-otp
Like others have mentioned, it unlike Authy this doesn't use your phone number as identity
Note that authy’s login (twilio login) uses sms-based 2fa itself, which is very vulnerable to sim-swap attacks. There is no way to disable sms 2fa on it.
To counter this I recommend disabling device sync in Authy, and only enabling it temporarily when you add a new device.
To counter this I recommend disabling device sync in Authy, and only enabling it temporarily when you add a new device.
For iOS users, I can really recommend Raivo OTP[0] a FOSS app that offers everything Authy does (backups included) with easy ways to migrate in- and out- of the app through an encrypted ZIP export of all your TOTP keys.
[0] https://github.com/raivo-otp/ios-application
[0] https://github.com/raivo-otp/ios-application
The mandatory requirement of a phone number to even set this up (with SMS as the verification method) doesn’t suit me. I use other TOTP apps that don’t ask for a phone number or email address or anything else.
Authy once deleted local credentials during an app update. I had to restore with my backup keys.. only I lost my backup keys so I had to go the long way to circumvent my 2fa. They didn’t seem very sorry about it either.
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.
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.
> 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.
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.
I'm trying to parse your second sentence, and I think I somewhat agree in a technical sense, but I think it would be fairer to say, Duo forces a second factor on you, whereas Google gives you the option; and in the long run it's better to not babysit people through a "lie."
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?
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?
Oh heck, found the answer, apparently so? Cool.
https://github.com/puddly/android-otp-extractor
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
Rather than the system of anyone that knows my card number can charge whatever amount they like for however long they want
[deleted]
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.
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”.
How does this article not link to the specs, aka the RFCs?
# python3 -m pip install pyotp
SECRET='JBSWY3DPEHPK3PXP' python3 -c "import pyotp; print(pyotp.TOTP('${SECRET}').now())"I built this to generate OTP codes via CLI
https://github.com/edify42/otp-codegen
https://github.com/edify42/otp-codegen
Does the password strategy really just truncate passwords over 64 characters? I don't use them often but since text passwords typically have low number of significant bits per character I have always assumed that the input string was hashed to a fixed length password that would increase in quality until the randomness of the text approached random bytes. My current secure passphrase is a paragraph that I have memorized from a book, about 250 characters, but I only type it a couple of times per month. Disappointing if 190 or so characters of this typing is indeed wasted effort and that at least 8 bytes or more (1-3 bits per character) of entropy is wasted per password because text doesn't use all 8 bits.
> How does Google Authenticator work?
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.
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.
A non techy friend of mine had some bad issues in that she had it on an iPhone, switched to a new iPhone copying everything over via icloud as one usually does and then finding Google Auth didn't copy the auth codes over or warn you that it won't, and hence was locked out of various accounts.
There’s also a tool that converts Symantec VIP Access tokens to standard TOTP tokens:
https://github.com/dlenski/python-vipaccess
https://github.com/dlenski/python-vipaccess
Not a big fan of a Google Authentcator myself, and didnt want to stay with Authy as well, thus I started working on my own authenticator, which is web-ased: https://www.daito.io/
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.
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.
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.