Quite a while ago I wrote about how I back up my multi-factor authentication (MFA) seeds so that it’s easy for me to restore them onto a new phone if my old phone breaks or is lost. A lot has changed in the MFA landscape since then, and my current practice and recommendations have changed along with it, so I think it’s time to refresh my advice. This time around I’m going to expand the scope of the article so it’s about a bit more than just how to do backups.
What is MFA and why is it important?
Feel free to skip this section if you already know the answers to those questions. 😉
Some definitions:
- authentication — the process of proving your identity, in this context to a computer system
- factor — something you know (e.g., a password), something you have (e.g., a smartphone or security key), or something you are (e.g., your face, your fingerprint) which you demonstrate your possession of to help prove your identity
- single-factor authentication — an authentication workflow in which you are required to demonstrate possession of just one factor to sufficiently prove your identity
- multi-factor authentication — an authentication workflow in which you are required to demonstrate possession of more than one factor of different types to sufficiently prove your identity
For many more reasons than we can get into here, single-factor authentication isn’t secure enough for most websites. Any networked computer application which has even the slightest value to the people who use it should require multi-factor authentication.
A lot of web app providers split the difference: they support multi-factor authentication, but they don’t require it. You should be enabling multi-factor authentication on every web app you use that supports it, even if it is optional. Look for it in your site account settings or preferences; it’s often listed in a separate “security” section.
The first factor in most multi-factor authentication workflows is a password. You should be using a password manager to generate and store long, random, unique passwords for different web apps. The only password(s) you should be typing from memory are the one to log into your computer and the password for your password manager itself. And your password manager should be secured with multi-factor authentication!
Read on to find out more about the second factors you can use in addition to your password. But first…
What are passkeys, and should you use them?
A passkey is a blob of cryptographic data that allows you to prove your identity to a website. When you log into a site that supports passkeys without using one, something like this happens (speaking very broadly):
- The site asks the device you’re logging in from, “Hey, do you have the ability to store and use passkeys?”
- If the device tells the browser, “Yeah, mate, I sure do,” then the browser asks you, the user, if you want to create a passkey.
- If you say yes, then the site does the necessary cryptographic negotiation with the device to generate the passkey, and it is saved to your device.
- The next time you go to log into the site, your saved passkey is used to authenticate, and you don’t have to enter a password.
If you’re paying attention, then at this point you should be thinking to yourself, “Now hold on, bucko, I thought we were supposed to be using multi-factor authentication! If I can log into a site with a passkey without my password, isn’t that just a single factor and therefore not secure enough?”
There are two reasons why the answer to that question is no:
- Single-factor authentication is usually insufficiently secure because the single factor is usually a password, and passwords are insufficiently insecure. Passkeys are orders of magnitude more secure than passwords.
- Devices which are capable of storing passkeys are supposed to be designed to require you to authenticate to the device (e.g., with a fingerprint sensor, facial recognition, swiping a pattern, or entering a PIN) before the device coughs up the passkey to authenticate to the site. The authentication to the device is the second factor!
So, should you use passkeys? That comes down to whether you find them convenient, as long as you follow the cardinal rule. I personally do not use them, because I find a combination of my hardware security key (YubiKey) and the 2FAS app more convenient than passkeys, and because I don’t entirely trust passkeys because they have a vendor lock-in problem.
Passkeys are considered phishing-resistant, meaning that because of the way they work, it is extraordinarily difficult for an attacker to execute a successful man-in-the-middle (MITM) or phishing attack against a website account protected with a passkey.
What should you use for MFA if not passkeys?
Here are your other choices for MFA, in decreasing order of preference based on a combination of security and convenience.
Hardware security keys
If you can handle having a security key such as a YubiKey with you all the time and not leaving it plugged into your work computer when you go home or vice versa, then a WebAuthn security key is the most secure mass-market choice for MFA, for websites which support them.
When your security key is plugged in, logging into a site where you’ve configured it is as simple as using your password manager to auto-fill your username and password, then tapping your security key briefly when you’re prompted to do so.
Some people solve the don’t-forget-it problem by putting the key on their key-chain (it’s hard to drive away when your keys are dangling from your computer!) or wearing it on a chain around their neck. I personally do the latter, and I also use my “remember-the-yubikey” daemon to alert me if I walk away from my computer when my key is plugged in.
Hardware security keys are also phishing-resistant.
Push-based authenticator apps
When you log into a site you’ve configured to use push-based MFA, a notification from the app on your phone pops up and asks you to review and approve the login. In the more secure version of this, the site you’re trying to log into also displays a code which you are required to enter into the app to confirm the login (this is meant to combat “MFA fatigue” attacks).
Push-based authenticator apps include Duo Mobile, Okta Verify, Authy, and Microsoft Authenticator. Just to make things confusing, these apps usually also support the older, time-based authenticators, so if you use the same app for both you end up with a mixture of push-based and time-based authenticators in the same app. I don’t recommend this both because it is confusing and because 2FAS is more convenient.
Because different sites support different types of push-based authenticator apps, if you use a lot of sites you will probably end up with multiple apps of this type on your phone. For example, because of the various sites I use, I have Duo Mobile, Microsoft Authenticator, and Okta Verify.
Push-based authenticators are vulnerable to MITM attacks: if an attacker can trick you into entering your credentials into a site impersonating a real site while they are connected to the real site, they can trick the site into sending you the push-based authentication prompt, log in as you, and gain your access to the site. Push-based authenticators are partially protective against phishing attacks that aren’t MITMs. MFA fatigue attacks are still an issue, but much less so when you are required to enter a code from the site into the app as described above.
Time-based authenticator apps
With time-based MFA, the site you are configuring MFA for displays a secret “seed” as a QR code for you to scan with an app such as Google Authenticator, or a string of characters encoding the seed for you to type by hand if you can’t scan the QR code or you want to copy and paste it into your password manager. The most common time-based MFA algorithm, which is pretty much universal nowadays, is called Time-based One-Time Password, a.k.a. TOTP.
TOTP is vulnerable to MITM and MFA fatigue phishing attacks.
Bespoke authenticator apps
Some sites embed MFA functionality into their functional apps. For example:
- When you log into LinkedIn from an unrecognized device, if you have the LinkedIn app on your phone then you may be asked to verify the login through a push notification sent to the app.
- I am a USAA banking customer, and the USAA banking app has an MFA code generator built into it. Whenever I log into the USA website, it asks me to enter the code from the banking app on my phone
The security of bespoke MFA mechanisms maps to the mechanisms described above in an obvious way. For example, LinkedIn’s is push-based without a code entry requirement, and USAA’s is time-based.
Recovery keys
Many sites allow you to download a set of “recovery keys,” each of which is a string of characters which can be entered upon login as your second authentication factor (after your password). Each of these keys can only be used once, so you have to keep the list somewhere and delete or cross off each one as you use it, and then generate more of them immediately after logging in with the last one.
Generally speaking, recovery keys are meant as a backup for when your primary MFA mechanism is inaccessible.
Some sites require you to generate and save recovery keys after setting up some other MFA mechanism.
Recovery keys are vulnerable to both MITM and phishing attacks. They should only be used as a last resort, and you should make sure to store recovery keys securely.
SMS and email only if you have absolutely no other choice
You absolutely should not use text or email messages for MFA unless the site offers no other options. They are better than no MFA at all.
Texts are insecure as MFA because it is easy for an attacker to reroute your text messages to them.
Email is insecure as MFA because it puts all your eggs in one basket: generally speaking the way you reset a lost password is through a link sent to your email, so if an attacker breaks into your email they can gain access to all the sites where you’ve used email as your MFA.
Your account security is only as strong as your weakest MFA link
If you have two different types of MFA configured for one of your accounts, then you should assume that an attacker will figure that out and go after the less secure one. This means it’s incredibly asinine when, for example, a website requires you to set up SMS MFA as a backup immediately after you’ve created a passkey or set up security key MFA. Alas, this is absolutely not theoretical.
If you want to set up backup MFA on a site and you are required to choose, e.g., SMS, email, or recovery keys, you’re better off choosing recovery keys and storing them securely rather than using SMS or email MFA.
Protect yourself from MITM and phishing attacks
The best way to protect yourself against man-in-the-middle and phishing attacks is to only use phishing-resistant MFA. However, many sites don’t support passkeys or hardware security keys, so this isn’t always an option.
Absent phishing-resistant MFA, the other way you protect yourself is a rule you should be following anyway: never click on a link you are not 100% certain came from a legitimate source. Instead, either use the link that you saved in your password manager when you saved the site’s password there; or type the URL of the site into your search bar by hand (“amazon.com”, “usaa.com”, etc.); or save a bookmark the first time you use the site so you can reuse that bookmark later; or go back to an old email from the site which you know is legitimate (e.g., your registration confirmation email, a confirmation email for an order you know you placed, etc.) and click the link there.
If you can’t do any of the above, then you may find yourself resorting to doing a web search for the name of the company to try to find a link to the site. There be dragons here! Attackers use various techniques to trick search engines into putting malicious links at the top of the search results when you search for sites they want to break into, so you have to be extremely careful about what you click on in search results. Avoid links that are marked as ads or “sponsored”; it’s actually easier for hackers to game the ads than the non-sponsored search results.
When should you configure a secondary MFA mechanism for a site?
Many sites that support MFA allow you to configure multiple MFA mechanisms. The easiest way to explain when you should do that is with a flowchart:
The cardinal rule: always have a backup
Your ability to log into any particular site should never be linked exclusively to a single vendor or device. For example:
- Are you exporting and securely storing the contents of your password manager on a regular basis?
- If you use a hardware security key for MFA, do you have a secondary MFA mechanism configured that you can use if the key is lost, broken, or stolen?
- If you use an authenticator app for MFA, do you have the seeds in that app backed up somehow so that you won’t lose them forever if your phone is lost, broken, or stolen?
- If you’ve created a passkey for a site, do you have a way other than the passkey to log in? Note that this applies regardless of whether the passkey is backed up. The backup is still bound to a specific vendor, because nothing that supports creating passkeys currently allows you to export them and import them into a device from a different vendor.
What strategies and tools should you use for MFA backups?
You should be regularly backing up:
- the entire contents of your password manager;
- your passkeys;
- your TOTP seeds (if you’re not storing them in your password manager);
- your recovery keys; and
- your push-based authenticator configurations.
Backing up your password manager data
Consult the documentation for your password manager to find out how to export a backup. Most password managers allow you to export your data.
Once you’ve exported the data, how can you keep it safe? You have two options: you can store it on an non-networked external storage device (e.g., a thumb drive) that you keep at home in a drawer when you’re not saving something onto it or restoring something from it; or you can store it on your network-connected computer or in a protected cloud storage drive as long as it is protected with strong encryption. Personally, I use GnuPG to encrypt my password manager backups before storing them on the family file-server in my basement.
Backing up your passkeys
If you’re saving your passkeys on your smartphone, it’s almost certainly backing them up into the cloud for you automatically. If it’s not, there’s probably no way for you to back them up, which is why, as I mention above, you should always have another way to log into any site where you’ve configured a passkey.
If you’re saving your passkeys in your password manager, then your password manager export may include passkeys (e.g. Bitwarden’s JSON backup format does), or it may not (e.g., LastPass). If your password manager falls into the latter category, then again, this is why you should always have another way to log into etc.
Backing up your TOTP seeds
If you decide to store your TOTP seeds in your password manager then make sure that they are included in its backup export. If they’re not, maybe reconsider that decision (or your choice of password managers)?
Another option is to use a TOTP app that backs up your seeds into the cloud so that you can restore them from there if you switch to a new phone. Many of the apps, including Duo Mobile, Google Authenticator, and 2FAS, support this now; none of them did back in 2017 when I wrote my first version of this article. Information security purists will cry foul and tell you that this isn’t secure and you shouldn’t do it. They’re mostly wrong, but this article is already long enough so I am relegating my explanation of why to a footnote.1
And then there’s the solution that I use: every time I add a new TOTP seed to my app, rather than scanning the QR code displayed by the website directly, I take a screenshot of the QR code, open the image file and scan the image into the app to confirm that it works, give the screenshot file an informative name (e.g., “google-2fa.png”), and then store it as described above for password manager backups. Then, if I ever need to restore all of my TOTP seeds to a new devices, I can bulk decrypt all of the screenshots, open them all in an image viewer, and rapidly scan them all back into the app. (Note that I back up TOTP seeds this way in addition to also configuring 2FAS to back up my seeds into the cloud; the 2FAS cloud backup is for convenience, while the screenshot backups are to protect against vendor lock-in.)
Backing up your recovery keys
When you generate recovery keys for a site, save them as a text file with an informative name (e.g., “google-recovery-keys.txt”) and then store the file as described above for password manager backups.
Backing up push-based authenticator configurations
You usually need to rely on the app to do this for you. Look in your settings within the app or consult its documentation.
Should you store TOTP seeds in your password manager?
Many password managers nowadays essentially have a TOTP authenticator app built into the password manager. You can store the TOTP seed for a site in the password manager alongside your username and password for the site. Then when you are logging into the site, you can easily generate the current TOTP code directly in your password manager and paste it in when prompted for it. Some password managers are even so smart about this that they generate the current TOTP code and copy it into your clipboard immediately after auto-filling the username and password, so you can paste it from there directly into the text field without having to take any further action.
This is Really! Convenient! It is also a security problem, which is why I don’t recommend you do it.2 The problem is that, just as for email MFA, you’re putting all your eggs in one basket: if someone manages to compromise your password manager, then they have access to not only your usernames and passwords, but also all of the TOTP seeds stored alongside them, so they have everything they need to break into all of those sites as you.
Granted, someone breaking into your password manager vault is not actually the threat model we are most concerned about when it comes to web application security, so the risk here isn’t that high. And if there were no other ways to reduce the inconvenience of using TOTP, then I might say sure, go ahead, this is an acceptable trade-off of much increased convenience with only a minor in risk. But there is another way to reduce the inconvenience of TOTP—using 2FAS—so that is what I recommend people do instead.
Using 2FAS to make TOTP easier
2FAS is a TOTP authenticator app for your phone which comes with a huge convenience feature which as far as I know none of the other apps support: it automatically transmits TOTP codes directly from your phone into your browser on demand. Here’s how this works:
- You install the 2FAS app on your phone and scan your TOTP seeds into it just like any other authenticator app.
- You install the 2FAS browser extension in each browser where you want to use this feature.
- The browser extension creates a key-pair and displays a QR code with the public half of the key in it, for you to scan into the phone app to link the app to that specific browser. The private half of the key stays securely stored within the browser.
- When you are prompted for a TOTP code you right-click on the field and select the menu command to send a request for the code to 2FAS on your phone. The request is encrypted with the browser’s private key so the app can confirm that it’s legitimate.
- The 2FAS app on your phone prompts you to confirm that you want to send the TOTP code back to the browser. If you say yes, it encrypts the current TOTP code using the browser’s public key and sends it back.
- The browser receives it, decrypts it using the saved private key, and types it automatically into the text field (sometimes the automatic typing doesn’t work and you have to paste it with ctrl-V).
Since the communication described above is end-to-end encrypted, which means that the folks who run the 2FAS servers can’t read any of the communications going back and forth between the browser and the app.
The 2FAS app supports backing up TOTP seeds into the cloud with encryption.
This is a great app about which I have only one, cosmetic complaint.
1Here’s Why you shouldn’t worry about backing up your TOTP seeds into the cloud. If your cloud account is secured properly, with a strong, random password and MFA, the odds of a hacker breaking into your account and stealing your MFA seeds are extremely low. On top of that for the MFA codes to do them any good they would also need to break into your password manager or guess your passwords (which of course they can’t do because you’re using long, unique, random passwords for all your sites, right?). Furthermore, many of the apps which support cloud backup (including 2FAS) require you to enter a backup password (which you should generate and store in your password manager!) and use it to encrypt the data. Backing up your seeds into the cloud isn’t zero-risk, but if you’re doing the other stuff right, the risk is extremely small and is certainly outweighed by the benefit.
2There is one circumstance in which you should store a TOTP seed in your password manager, and that is when the password manager entry is being shared among multiple people who all need to be able to log into a shared account. In this case it’s hard to set up secure MFA available to all the people who need access to the account, so setting up TOTP MFA and storing the seed in the password manager is a good trade-off of convenience vs. risk.
