After using TOTP like Google Authenticator since around 2013, I now think the friction needed is just too great. Especially for banks which log you out after 15 minutes or so of idleness. Google doesn't do that.
Not to mention Google Authenticator deliberately prevents these stored tokens to be backed up and transferred to a different device, which makes upgrading devices troublesome.
I wish everyone would start using Yubikeys. WebAuthn is now widely supported by browsers.
Why not use an open TOTP app like AndOTP. I use it all the time for sites that claim to require Google Authenticator, it works, and its easy to backup the secrets as plain text or encrypted with a password. I keep it current on my primary phone and a cheap offline backup, in addition to backing up the encrypted secrets file.
I use Authy on iPhone and Mac. I am looking for an OSS replacement but would not want to setup everything from scratch after I change device reinstall the app like Google Authenticator.
I've wanted to get off Google Authenticator for awhile now, mostly because of the backup-restore problem, also a general trend of limiting my involvement with the company.
Bitwarden does a decent job of storing and syncing TOTP codes. Make sure you always use a long password with Bitwarden though, to avoid a known and unpatched issue with their password-based key derivation.
People recommend Authy. As far as I can tell they rely on cloud sync/backup like any other app in that space.
Isn’t google authenticator not using this on purpose? Central account and sync is googles thing and yet they deem it too insecure. Completely understandable
So how can using a central service that adds yet another attack vector be of value?
What I would love to have is a paper export.
Every time you add a new account to google authenticator you can print it as QR code for later reimport.
Yes many services already provide this for you via recovery codes but having it on a per service basis directly from authenticator is probably much easier to use and not less secure
That sounds good but put them in Authy. That lets you have multiple devices whereas Google limits you to one device.
It's great that people use can use one app for both factors but it seems less secure than two apps.
For example, use Authy for TOTP and LastPass for long passwords. That's two things that have to be compromised. And both of them allow you to have multiple devices (for example iPhone and iPad).
Its great functionality but it reduces your security. Say someone somehow figures out your 1Password password and security key - if you store your OTPs in Authy, your passwords are useless (well, less useful anyway). If you store your OTPs in 1Password, they have the keys to the kingdom.
This is technically true, but the most likely scenarios that result in the discovery of your secret key (128bits of entropy) + master password (?? additional bits) involve things like a device compromise. If your machine is compromised, you’re probably already exposed to things like session cookie stealing. At that point your attack surface is already blown wide open.
The biggest thing 2FA protects against is credential stuffing. If you’re using a password manager and have high entropy site-unique passwords, the additional entropy by TOTP is mostly moot anyway.
Passwords - protect against unauthorized access of my service accounts, and 1Password - can be compromised via logging or breaches or just plain peeping
Secret key - acts as 2FA for my 1Password and thus protects my master password from unauthorized use - can be compromised if someone steals the physical paper on which it's stored
TOTP - protect against unauthorized use of my service accounts - can be compromised if someone compromises my mobile phone or phone number. Highly unlikely someone would spend that kind of effort and €€€ on me though
All in all its a pretty nicely tiered system. If someone gets my master password, they still need the secret key. If a burglar steals my secret key, they don't have my master password. If someone somehow compromises both of those, they still don't have access to my TOTPs and thus can't login into any of my 'cricital' accounts (basically e-mail, hosting providers, finance, etc. etc.)
Now imagine you have an malicious spouse or housemate or whatever: they could easily learn your master password by peeping over your shoulder, piecing it together bit by bit (ha). They have a lot of opportunity to search for your secret key as well. If you put your TOTPs on 1Password, you're boned. But if you have them in an authenticator app, even having access to your password manager means jack because they can't login without your TOTPs.
I know one of the big faux pas is to talk about your security but most of this stuff can be deducted pretty easily so I don't feel too exposed.
Wow that’s awesome! I had no idea 1Password had this functionality so thanks for sharing. I just had a rough time after upgrading my phone dealing with Google Authenticator since I hadn’t realized my Auth info would not migrate along with the rest of my data...
> Not to mention Google Authenticator deliberately prevents these stored tokens to be backed up and transferred to a different device, which makes upgrading devices troublesome.
It doesn't offer export in the app UI. It's not doing anything to prevent you from backing up the tokens yourself; they're stored in the clear in the sqlite database for the app.
>Not to mention Google Authenticator deliberately prevents these stored tokens to be backed up and transferred to a different device, which makes upgrading devices troublesome.
If that were possible then you would face the same problems that reused SMS numbers suffer from.
That is not true. Banks in the EU seem to vary a lot, as the definition of “strong” is not defined (plus many banks have not introduced it yet). Biometric is definitely not required. I use hw tokens but at least one of my banks is trying to move to weaker auth.
I didn't say biometric is required, I said it's normal to have 2fa with friction, an hardware token is just as much friction as TOTP or biometric.
I am surprised your bank is moving to a weaker auth, what does that mean?
I have 3 bank accounts in 2 countries and they all switched to biometric because it's just a simpler experience then the hardware token or "mobile token" they used before.
What absolutely confuses me is.. aren't TOTP authenticators like the cheapest 2FA option to begin with?? No need to have some fancy SMS Enterprise account with a Telecom or pay okta or duo or entrust a bunch of money. It's FREE, all you have to do is implement the server side which is very straightforward.
A cost of implementing TOTP is ID verification at the time the user needs replacement credentials, eg when they lose the phone that had their TOTP secret. With SMS, this cost is offset to the mobile carrier, though as discussed here, carriers have their own vulnerabilities.
A further cost is that they usually require the user to install and set up an app, contrary to SMS.
OTP using an app has a very low adoption rate. You'll be surprised that even on crypto exchange 90% of the users don't have access to any kind of 2FA let alone Apps. Only less than .1% of the users have an app installed. It's not convenient
I wonder how that looks like for bank apps? Banks could (and I’m sure they have) offer their own TOTP client, perhaps a bit more integrated. I’m sure that would be easier and offer a better experience than downing some random. "Google Authenticator" app.
Yes, that works well. My bank has integrated this functionality this functionality into their mobile app, allowing one to use it to login on a computer. When large amounts are to be transferred, the bank-supplied 2FA device is still needed though (which can be annoying, but seems sensible).
This scheme also works really well with payments from your computer. Just use the bank app to scan a qr-code on checkout, verify the payment details on your phone, touch a button, and you're done.
I'd guess that a majority of the bank's clients are using this method. This is in the Netherlands, by the way.
> aren't TOTP authenticators like the cheapest 2FA option to begin with??
They are precisely equivalent to asking for two passwords on login instead of one password. "Something you know" and "something else you know". So pretty much, yeah. SMS may not be especially secure, but it is at least an actual second factor.
My banking app requires a pin (or fingerprint) to read data, and a password to make transactions.
The website requires a temporary code, generated by a card reader and my card. It works like a 2FA code, as I need to _have_ my card and to _know_ its pin.
My brain isn't working right now... Can you tell me why something like google authenticator could not be executed as a website? Does it have to be an app?
Just wondering if there could be an easier non installed version that was always available.
But how do you protect access to the website - with a username and password? Or do people now need to remember another code like "JBSWY3DPEHPK3PXP" to set up the authenticator everytime they visit?
Mobile apps were one way to solve this although the hardware U2F tokens like Yubikey provide another authentication factor in a usable way (and more secure than TOTP because you can't be phished to enter them on the wrong site).
That's right, in fact if people remember that secret then it's not a "second factor" it's just another part of their password. A "factor" in the context of authentication means one of the various ways that can be used to verify someone's identity: "something you know" (password), "something you have" (non-duplicatable object, eg a SIM card or OTP token containing a secret that cannot be easily guessed or extracted), or "something you are" (biometrics).
> in fact if people remember that secret then it's not a "second factor" it's just another part of their password.
This is more generous than it should be. Your TOTP secret is just another part of your password regardless of whether you personally remember it or not; what matters is that, if I would like to be you, I only need to know the secret.
TOTP has a secret which is basically the seed of the calculation. The security basically comes from that secret being only on the phone you have and not being copyable. Moving it to the server removes that proximity. At least thats how i see it, but you could do it very easily server side if you wanted with equivalent security loss.
Having the secret only exist on a single phone is the most secure, but keeping a backup of the secret for recovery if you lose the phone only lowers security a negligible amount if you are careful about it.
If it is an account you set up from home, probably the simplest thing to do is print the setup page before you scan the QR code for the secret. Even better, print the page, and then scan that QR code from the printout. Then store the printout where you keep other important papers (e.g., mine would go in my fire proof safe).
Another possibility is to scan the code on two devices. I scan on both my iPhone and my iPad. Nearly all realistic scenarios that involve me losing both of those at near the same time also involve me dying.
People chasing perfect security by only putting their TOTP codes in one place seems like perfect being the enemy of good. Back up you codes people! Put them in an encrypted file and back that file up in a bunch of places.
Encrypting a file is a bit arcane, but not difficult:
Do you have one encrypted file with all the codes, or do you have one file per code?
I prefer one file per code. When I get a new code, I make a directory named after the account the code is for, save a screenshot of the QR code in there, save a text file with the text version of of the code and any one-time recovery codes the site provided. I then make a .zip for .tgz from that directory, encrypt that, and save a copy in the cloud and locally. The local copy is in a location that is included in offsite backups.
If you use one file per code, I'd recommend using a public key system for the encryption. That way you don't have to enter any secrets to encrypt a new code. You only enter anything secret when decrypting.
This has a few advantages.
1. Less chance of accidentally exposing the key.
2. If like most people you use the same key for all the files, no chance of unknowingly mistyping the key resulting in a file that you cannot decrypt later.
3. If you need to recover a code, you only need to decrypt that code.
If as you suggest you wrap this in shell scripts, you can address #2 there. Have a reference file encrypted with your symmetric key. For encryption, the script can ask for your key and verify it was typed correctly by using it to decrypt the reference file.
Also worth considering is using an encrypted disk image. I believe that all major desktop operating systems provide reasonably easy ways to create, mount, and dismount such volumes. Whether you use one file per code or all codes in one file, the file or files can live on an encrypted volume that you only mount when you are saving a new code or recovering an old code.
The advantage of that is that there is no need to use any arcane commands or install any extra software.
Having a simple encrypted file means you can stuff it on an online backup though. The point is to have the keys stashed in several places so the loss of any one or two devices doesn't lock you out of your life.
I prefer keeping it as simple as possible since the consequences of screwing it up are a whole lot of hassle and possibly being locked out of some accounts forever. One downside is when you add or change a code you have to update all of your backups. A second script that syncs all of the backup files is also helpful to have.
I could see Apple offering 2FA as a core feature, at least on iOS.
In fact, Apple should redesign Keychain into a user friendly, 1Password-lite product with 2FA built-in (1Password offers this too) or as a separate app that works with Keychain.
iCloud Keychain is already a better-than-1Password 1Password-lite and 2FA itself for your Apple id is built into iOS and macOS. I think the limiting thing there is desktop Safari - you don't really notice the full integration unless you're using Safari on macOS as well.
Yes, super annoying. Now I can no longer get into my Apple Developer account without walking to my development mac I use to run xcode builds (for a react native app), since for some bizarre reason the only 2FA they support is their own which requires Apple hardware.
It's bad enough their development toolchain requires you to buy their hardware, now to log into their websites you also have to buy their expensive hardware.
It depends. If your iMessage account is tied to an Apple ID used on multiple devices with 2FA enabled then the code is sent to one of those other devices to validate the login on the new device. So if you are fully in the Apple ecosystem and have 2FA enabled then I believe it would be secure. I know I get alerts on my other devices any time I have had to re-add my phone number to an Apple ID. It tells me my phone number is now being used on another device. So at the very least you would probably be notified.
iMessage is only tied to an Apple ID for the e-mail part (where they can send iMessage to your e-mail). The phone number part is independent of that and you can take it over provided you prove ownership of the phone number (by inserting the SIM into an iPhone, it'll send an invisible SMS to Apple and back and that then activates iMessage on that number on that new device).
I think there’s an SMS sent without any visual indication and without asking for explicit permission (or I missed it if there was a tiny text warning). I noticed it when I saw an SMS, in my bill, sent to a Singapore number which, as an international SMS, was changeable (SMS is mostly free here).
