This doesn’t make it clear to know or straightforward to learn if I can use apps other than gAuthenticator for this account.
gAuthenticator had been my go-to 2FA app since it was introduced. I’ve had recurring problems with it and started using Authy a few months ago. Most of my issues and requirements from this earlier post are addressed well by Authy.
Authy lets me use tokens it syncs across multiple devices. I’ve got tokens available to me across two iOS devices and an Ubuntu desktop app. It throws up reasonable flags first time / long time I log into Authy from a new app or location. This is huge and has prompted me to enable 2FA on more services.
They’ve executed this so well, I’ll complain about one nit: The iOS app did a fine job associating service provider icons with my tokens. The Ubuntu app shows mostly generic service icons which doesn’t make clear enough the apps associated with tokens. I can edit these and explicitly associate my own icons and labels, but most default to my email address used for the service so first I have to sort out which is what (by having two Authy devices and matching tokens from Known account to the desktop app).
Moving to a new device always involves re-creating tokens and updating security preferences for each service.
By design, recovery codes are intended to be copied and stored locally. By execution, when and how recovery code availability is communicated to us is not consistent across services. By habit, we don’t always adhere to best security practices.
Lost, stolen, or broken devices are catastrophic without having ready access to current recovery codes.
Neither of these articles about backing up Google Authenticator have info about backing up your current account tokens
No token / account backups by design
There are no account backups in any of the apps by design.https://github.com/google/google-authenticator
A local app secured with a local password allowing me to backup and restore gAuth account tokens is far more secure for a larger user community than printing / storing recovery codes.
A remote service allowing me to backup and restore gAuth accounts / configurations is far more secure and useful to a larger user community than printing / storing recovery codes.
In gAuthenticator’s case, Google can already authenticate and authorize me. They have a deep body of information about me — web habits, places I’ve been, payment and bank info. A good backup and restore UX would give me a choice of also storing my 2FA info for Digital Ocean, AWS, and GitHub with them.
Adherence to best security practices
Good security encourages good habits and accounts for less-than-100% compliance with them. The current recovery code process encourages security exposures by design: Services encourage storing recovery codes safely. What % of folks store documents on cloud service drives and will do same with recovery codes so they can have ready access to them across all their devices? Others encourage taking screenshots of QR and Recovery codes. On mobile, what % of folks store screenshots to a cloud storage service automatically?
All of these expose vectors for breach. For some, people will do something like putting passwords on Post-Its stuck to monitors when IT makes them change passwords every 90 days, require use of upper case, lower case, numbers, and special characters, disallow use of previously-used passwords, and don’t allow spaces rendering pass phrases — which are easier to recall and harder to crack — impossible.