This may be a bit off-topic, but I am not familiar with the term “authenticator” and can’t find any definitions. Could someone please explain what an authenticator is, what it does, how it differs from a Password manager, and why I should trust Google and Microsoft, both of which have been complicating my internet access of late?
I don’t use Authy but my quick reaction to the Authy breach is rooted in my view that trust is very important with security and privacy services. The nature of the breach does not allow me to feel confident that I could trust Twilio-Authy to produce and operate a secure product and service.
This article from Wirecutter has a good primer on authenticators, despite the fact they still recommend Authy:
2 Likes
Thanks. That and some further digging explained authenticators ad exposed a potential issue - I don’t use a smartphone. I did find a web site that describes the use of desktop authenticators or security keys How to use two-factor authentication without a phone - gHacks Tech News That may take a while to figure out.
No matter how many users were affected, the breach only matters if you were saving your codes on their servers. If you didn’t sync anything (keeping them local to your devices) then a server breach won’t matter.
The term is pretty generic, but in this context, we’re talking about software that implements a time-based one-time password (TOTP) algorithm.
The idea is that instead of the server e-mailing (or texting or phoning) an authentication code to you (which can be intercepted), you keep a local device that generates codes on its own, without any communication with an external server.
The code generated is a function of a private key and the current time of day. When you set it up (typically as a 2FA), the remote server generates the key and sends it to you (typically by including it in a URL and encoding that URL as a QR code, which your authentication app can read). So as long as your device and the remote server have clocks that are close to synchronized, you’ll both see the same codes at the same time. So when you log in, the system will ask you to enter the code - which your authentcator app will show you.
The advantage of this over a password is that the code expires pretty quickly (typically in about 30 seconds), so if anybody intercepts your login communication, the code won’t be useful to them. (The algorithm used to generate codes involves cryptographic tech so it should be impossible to derive the key from a code or sequence of codes over time).
Of course, if someone gets that key, then they can replicate the entire sequence. This is good for legitimate management, because you can set up any number of devices (e.g. your Mac, your phone and your iPod) with the same keys. But it’s bad if a malicious person gets the key, because he can then generate the same codes. But he will still also need your password (which is why TOTP is best as a 2nd factor, not as a primary factor) to make use of it. And, of course, once a breach is known, you can log on to the service and have it generate a new key, which you can install on all your devices, but which the bad actor shouldn’t be able to get without yet another breach.
Most of the authenticator apps out there (Google, Authy, Microsoft, and others) all implement the IETF standard algorithm, generating 6-digit codes with 30s expirations.
But, of course, there’s no reason you couldn’t create variations (different expiration times, different key types, etc.). And (I’m pretty sure) that Apple does just that. When iCloud 2FA asks you to type in a 6-digit code generated by your trusted device, that code displayed by that device is not received from an Internet server. It is actually generated locally by the device. The only network communication is a command to tell your phone to show a code. Which you could also manually request at any time.
In iOS 17, this is Settings → Apple ID → Sign-in & Security → Two-Factor Authentication → Get Verification Code:
There are similar options on all other Apple OS products. So you can generate codes even when your trusted device has no Internet connectivity.
5 Likes
Thanks for the detailed explanation; it’s very helpful to understand how the process works so I can deal with it.
1 Like
As far as I can tell, you still can’t export accounts from Authy. In 1Password, you can see the secret key (at the end of the URL) in edit mode. The key is what you need to set up an account in a different app.
3 Likes
OK. I took the advice of the collective wisdom here and transferred all my 2FA accounts from Authy to MS Authenticator. It was much easier and smoother than I had feared. I chose MS over Google for two reasons: (1) does anyone really trust Google not to misuse data?, and, (2) Google has killed off so many products and services that I once relied on and I want to minimize that risk.
1 Like
I agree with both points about GOOG…but I regard MSFT as scoring about the same as GOOG there.
If I remember correctly–it’s been a few years–when I was choosing authenticators I chose GOOG over MSFT because (back then?) MSFT required an account signup and cloud storage for MS Authenticator. Having said that, if MS Authenticator is now a simple download from Apple App Store and start using immediately app, I definitely will give it another look.
1 Like
Both MS and Google authenticators are in the iOS app store. I have had the MS authenticator for several years because I needed an MS account in order to edit MS Office files on iPhone and iPad. I don’t know whether you can use it without an MS account. I do know that you can use the Google authenticator without a Google account because I do not have a Google account but have used the app.
1 Like
Microsoft, Google and Authy all implement the same TOTP algorithm, so all should be able to read the same QR codes you get from a server to set up the internal keys.
It’s the rest of the app that you have to decide if you trust it or not. Google Authenticator offers you the option to store your keys in your Google account, so they will automatically be synchronized to all your devices. I don’t do this because I don’t want to trust Google to keep them secure. And the Google app has an export facility that I can (and do) use to copy keys between a few different devices. But I’m not concerned about the app itself being malicious. Maybe I should be, but I’m not.
I don’t have experience using MS Authenticator or Authy, so I won’t comment on them.
1 Like
I use Verify, made by Ubiquiti. I know next to nothing about authenticator technology, and chose Verify because I have been very pleased with the technology and service in my Alien router, also from Ubiquiti. I figure Ubiquity is large enough to be financially stable and have resources to create solid technology, yet small enough to give good support and maintain their products well. If anyone knows of an issue I have missed, please inform me.
I am required to use Duo Mobile by work. It has been simple to use and I’ve not had any problems with it.
1 Like
Same here, Duo mobile. And I have added other authentications to it, like Amazon, Paypal and my domain registrar.
1 Like
I started with Google Authenticator, then moved to Authy since it could sync between devices, and finally switched to 1Password when it gained 2FA support. I also have Microsoft Authenticator because it is used by my employer for Outlook on iPhone.
I don’t plan to use passkeys.
1 Like
I’m curious. Why not?
1 Like
Two reasons: portability and risk of single point of failure.
I use 13 web browsers (in total) on 5 devices, plus all the apps that aren’t browser based. I expect to be able to sign in to any of them, anywhere. Currently I don’t think passkeys are that portable. And, I expect to be able to sign in without having my iPhone, or whatever devices the passkeys are on. I know that worst case, I have the password.
It’s the same reason that while iCloud password synching is nice, it doesn’t work when I’m using a device that isn’t mine or not Apple. So I don’t depend on it.
Maybe some day, but not now.
1 Like
I agree with you…they’re not common enough to make them worthwhile today…and probably not for years because it’s a chicken and egg problem…not many people use them because they’re not widely supported by web sites…and websites don’t support them because people by and large aren’t using them…just like Steve Gibson’s SQRL development. It will be a long time before passwords aren’t needed…and while passkeys are better than passwords they’re not orders of magnitude more secure, particularly if one uses long passwords and all 4 of the password food groups. They’re better…but not much to really be worthwhile, and the inertia of them not being ubiquitous and the better is the enemy of good enough idea makes them not very useful in 2023. 2033…maybe.
1 Like
I don’t view passkeys as an all-or-nothing proposition. As with 2FA, when a website or app begins offering passkey-based logins, especially for any company or organization dealing with sensitive information or transactions, I will update my login method.
I agree there is some hassle and inconvenience involved…but security and privacy practices will always change over time. Moving from 1FA to RSA SecurID physical tokens to authenticator apps to YubiKeys hasn’t always been smooth going but, unfortunately, has been imperative for many people.
1 Like
Are you using an older version of 1Password? The current version supports passkeys, so they’re just as portable as passwords if you’re using 1Password 8.
1 Like
In case any Authy users missed the news, Authy is switching to a mobile-only model, with the Authy desktop app being discontinued on March 19, 2024.
Twilio, the company that develops Authy, recently had announced that desktop support would remain until August, so this is a bit of a surprise.
1 Like