Authy corrupted my 2FA backup and all I got was this lousy blogpost(cmb.weblog.lol)
cmb.weblog.lol
Authy corrupted my 2FA backup and all I got was this lousy blogpost
https://cmb.weblog.lol/2025/05/authy-corrupted-my-2fa-backup-and-all-i-got-was-this-lousy-blogpost
13 comments
Authy did this with me years ago, too, destroyed my tokens, I had different lists of tokens on different devices, too - that's why I kept an old phone as it had some of my accounts in there. Do not touch that steamy pile even with a 10-foot pole! It's unfortunately that some providers recognized by your phone number that you have Authy and for you to use it!
I use KeePass as main TOTP app but migrated from Authy to Aegis (open source, great app) years ago which I use as sort of secondary backup, which also allows you to create backups and import/export data. I sync those off my phone using Syncthing. There is absolutely zero reason to use Authy for standard TOTP these days.
It's pretty obvious that you should be backing up the actual TOTP secrets not relying on an app to manage it. I use 2FAS Auth which allows export. The other alternative is to use multiple devices for each 2FA account (the original intent?)
Just got off Authy. They've done everything to trap customers into their broken platform, primarily by never allowing the user to export their tokens, either to file, or to another MFA application.
They also stopped supporting their desktop app, forcing users back onto a single point of failure: the mobile app.
If Twilio isn't going to support Authy in good faith, they should stop holding their remaining users hostage.
They also stopped supporting their desktop app, forcing users back onto a single point of failure: the mobile app.
If Twilio isn't going to support Authy in good faith, they should stop holding their remaining users hostage.
I should have been smarter and thought about looking at export sooner, it wasn't until I had this issue that I dug in and realized how bad it was.
Most 2FA apps don't allow export for security reasons. I usually just re-generate all my TOTP keys manually. It's terribly painful, but I used to do it with every phone upgrade.
"Security reasons" is pretty insane, considering how easy it is to lose access to a good number of accounts if any 2FA app breaks from a bad update.
Google Authenticator has done this before too, way back in 2013: https://news.ycombinator.com/item?id=6325760
Google Authenticator has done this before too, way back in 2013: https://news.ycombinator.com/item?id=6325760
Typically the way these codes are compromised is when they are stored in a non-HSM location like Google drive or transferred somehow. Then again, if you are just trying to keep people out of your Facebook account it's not a big deal. But if you are trying to keep people from financial accounts I wouldn't recommend transferring TOTP keys. Instead using a backup method like a printed out one time use sheet would be better.
Unfortunately most such websites use KBA or Text based authentication as a backup for TOTP so you may as well just stick it in Google drive.
Unfortunately most such websites use KBA or Text based authentication as a backup for TOTP so you may as well just stick it in Google drive.
It sucks Yubikey (or other hardware based auth) isn't more prevalent in the financial/banking world. It helps mitigate a lot of types of attacks:
- No tokens to exfiltrate off a computer
- Avoids keylogger style attacks
- More durable than cell phones
That said, for people that have high amounts of money in certain accounts (> 1m), it might also present physical dangers (e.g. kidnapping, home invasion) for thieves attempting to get access to the hardware key.
- No tokens to exfiltrate off a computer
- Avoids keylogger style attacks
- More durable than cell phones
That said, for people that have high amounts of money in certain accounts (> 1m), it might also present physical dangers (e.g. kidnapping, home invasion) for thieves attempting to get access to the hardware key.
The rubber hose attack is always the most reliable and most dangerous method of breaching high value targets like this.
https://xkcd.com/538/
https://xkcd.com/538/
It is indeed the very epitome of sanity, if you simply consider that the codes are secrets, and this entire practice is derived from having hardware dongles with secure enclaves, where secrets go in but never come out. It is the utmost in security when this one-way relationship is observed.
The ability to export secrets is an unfortunate compromise which vendors make for consumer markets. The MFA apps were not designed for exportability. If you own any Yubikeys you will know this. The whole idea is that this factor is "something you have", in other words, possession of the item containing your secret. An exported secret is no longer a secret, no longer something you have; it's just another password you're shuffling around.
The reason that you don't lose access to accounts when losing your MFA apps is that you took down the emergency backup codes and you committed them to paper, or some other durable medium, in a place where they can easily be accessed during a crisis. You did this scrupulously with each MFA activation, didn't you? Didn't you?
The ability to export secrets is an unfortunate compromise which vendors make for consumer markets. The MFA apps were not designed for exportability. If you own any Yubikeys you will know this. The whole idea is that this factor is "something you have", in other words, possession of the item containing your secret. An exported secret is no longer a secret, no longer something you have; it's just another password you're shuffling around.
The reason that you don't lose access to accounts when losing your MFA apps is that you took down the emergency backup codes and you committed them to paper, or some other durable medium, in a place where they can easily be accessed during a crisis. You did this scrupulously with each MFA activation, didn't you? Didn't you?
In an ideal world, I'd just use Yubikeys for everything. The problem is that it's not universally supported (or only supports a limited number of keys), so now I have a hodgepodge of 2FA app or Yubikeys or, even worse, phone/email 2FA.
The great thing about Yubikeys is that I can associate backup keys for accounts (when they are supported), so if I lose one key, I can deactivate the lost key and use a backup key in its place.
With heavily locked-down 2FA apps, I have to hope I can do a full recovery on a new device, or go through the recovery code process, or start all over again w/ new 2FA codes. If I'm lucky, the app allowed me to have it installed onto a backup device.
It's way more complicated that just swapping in a new Yubikey.
The great thing about Yubikeys is that I can associate backup keys for accounts (when they are supported), so if I lose one key, I can deactivate the lost key and use a backup key in its place.
With heavily locked-down 2FA apps, I have to hope I can do a full recovery on a new device, or go through the recovery code process, or start all over again w/ new 2FA codes. If I'm lucky, the app allowed me to have it installed onto a backup device.
It's way more complicated that just swapping in a new Yubikey.
> The reason that you don't lose access to accounts when losing your MFA apps is that you took down the emergency backup codes and you committed them to paper, or some other durable medium, in a place where they can easily be accessed during a crisis. You did this scrupulously with each MFA activation, didn't you? Didn't you?
Not all TOTP implementations, especially indie PHP websites, are robust enough to have implemented backup codes.
Not all TOTP implementations, especially indie PHP websites, are robust enough to have implemented backup codes.
Well, that's pretty sad, but surely, in every case, there is some procedure that's delineated for account recovery when something goes wrong?
I have been dismayed at some supposedly professional implementations, such as when I telephoned Wal-Mart to ask what can be done if I lost my phone (SMS is their only 2FA) and they said that they were prohibited from changing anything in account settings or profiles, and the best idea was to create a new account. (That is crazy -- if you shop at a marketplace like that, they've stored all your receipts, your membership, a potentially years-long trail of paperwork that you may need for taxes, or reimbursement, or refunds later on!)
Even worse, I had a bad time with the United States Postal Service. If I recall correctly, I'd lost access to the registered email address, and I was requesting to change it to something within my control, and they said "no can do", and they told me that my only recourse would be to create a new account, so that's what I did. Interestingly, USPS offers 2FA via either email or SMS, and their SMS gateway service is frequently out of order, so I always use email when logging in there.
Once, around 2021, I contacted GitLab to inform them that their account recovery process was a backdoor to circumvent MFA. They denied any such problem. I suggest that any account recovery implementation be just as secure as the front door to sign in, but also not impossible, because why do you want loyal customers to lose their accounts completely?
I have been dismayed at some supposedly professional implementations, such as when I telephoned Wal-Mart to ask what can be done if I lost my phone (SMS is their only 2FA) and they said that they were prohibited from changing anything in account settings or profiles, and the best idea was to create a new account. (That is crazy -- if you shop at a marketplace like that, they've stored all your receipts, your membership, a potentially years-long trail of paperwork that you may need for taxes, or reimbursement, or refunds later on!)
Even worse, I had a bad time with the United States Postal Service. If I recall correctly, I'd lost access to the registered email address, and I was requesting to change it to something within my control, and they said "no can do", and they told me that my only recourse would be to create a new account, so that's what I did. Interestingly, USPS offers 2FA via either email or SMS, and their SMS gateway service is frequently out of order, so I always use email when logging in there.
Once, around 2021, I contacted GitLab to inform them that their account recovery process was a backdoor to circumvent MFA. They denied any such problem. I suggest that any account recovery implementation be just as secure as the front door to sign in, but also not impossible, because why do you want loyal customers to lose their accounts completely?
It's only a security issue if you don't secure the cloud storage that's used for backups.
Google Authenticator and some other 2FA apps allow the user to export their tokens to other apps so you don't need to redo TOTP on every website.
The most secure method is to only have tokens on the 2FA device and to avoid using TOTP backup/restore altogether (or manually copy the tokens on a secondary 2FA device). It's a tradeoff between security vs. convenience.
Google Authenticator and some other 2FA apps allow the user to export their tokens to other apps so you don't need to redo TOTP on every website.
The most secure method is to only have tokens on the 2FA device and to avoid using TOTP backup/restore altogether (or manually copy the tokens on a secondary 2FA device). It's a tradeoff between security vs. convenience.
I think Microsoft Authenticator is the smartest right now because it's a "two-cloud" solution partly out of necessity, but also that seems a trustworthy architecture more generally. Since almost no one's phone runs Windows anymore, the raw app data backups "naturally" go to either iCloud or Google Drive. Then Microsoft keeps other (HSM) decryption keys in OneDrive. The threat model requires compromises of two clouds, so Microsoft Authenticator can be way more generous on how often and easily it backs up. It's an interesting point in the security vs. convenience tradeoff.
Yeah, the iron triangle of security, convenience, and privacy rears it's ugly head again.
Tarsnap should partner with Apple and Google to offer a per-app minimal important data backup API/service to offer revisioned backups (not just replication) of critical data. This is something Tarsnap could offer app developers as an SDK at first, but then gather momentum to be integrated into mobile/dekstop OSes.
Google Authenticator did this to me once before, way back in 2013 [1].
After that, it was vaults that were easily exportable and backed up all the way (like most password managers).
[1] https://news.ycombinator.com/item?id=6325760
After that, it was vaults that were easily exportable and backed up all the way (like most password managers).
[1] https://news.ycombinator.com/item?id=6325760
I switched to Ente Auth back when Twilio screwed ppl over by eliminating the desktop application. Literally everything about Ente Auth has a better experience than Authy ever was, even before the incident.
Highly recommended by a highly satisfied user.
Highly recommended by a highly satisfied user.
I am so glad I stopped using Authy and (painfully via the desktop extension and some hacking to get my TOTP keys) migrated to Aegis. I eventually moved from Aegis to keeping everything in Bitwarden + self-hosted Vaultwarden.
If not for a backup on the very old, insecure phone, Authy would cut me off from my codes.
They refuse to start the app on GrapheneOS literally because they cannot be arsed, offloading the claim of security of the handset to Google (which says an old handset not patched in the last 8 years is secure, but the most recent, best patched OS is not).
When the shit hit the fan Authy even removed the way to export the seeds from the desktop version of the app. Big FU to customers.
Never again.
They refuse to start the app on GrapheneOS literally because they cannot be arsed, offloading the claim of security of the handset to Google (which says an old handset not patched in the last 8 years is secure, but the most recent, best patched OS is not).
When the shit hit the fan Authy even removed the way to export the seeds from the desktop version of the app. Big FU to customers.
Never again.
I thought we all moved to Bitwarden a decade ago?
buried lede IMO
> Authy was sold to Twillo in 2015
> Authy was sold to Twillo in 2015
tl;dr
> Much to my surprise, when checking the App Store page, I saw that an update to the app had been approved by Apple only 14 minutes prior. I downloaded the update, tapped upon one of the previously "locked" items, and entered my backup password. Boom, the previously locked 2FA codes were now unlocked and restored, ready for use.
> Much to my surprise, when checking the App Store page, I saw that an update to the app had been approved by Apple only 14 minutes prior. I downloaded the update, tapped upon one of the previously "locked" items, and entered my backup password. Boom, the previously locked 2FA codes were now unlocked and restored, ready for use.
I think you missed that part where they subsequently tried to gaslight the user again and told him to do the thing he explained in the ticket he can't.
Or what is the purpose of your comment? :)
Or what is the purpose of your comment? :)
[deleted]