Backup codes, keys, and seed phrases are important if you lose access to multifactor authentication (MFA) methods or are otherwise completely locked out of your accounts.

There are many methods to store backup codes, keys, and seed phrases. Some methods may be better for certain situations and/or users than others.

Different solutions have differing pros and cons - it's important to weigh these when deciding how to store backup codes and seed phrases.

Importance of backup codes, keys, seed phrases

Strong(er) MFA methods, such as Time-based One Time Codes (TOTP) place the onus of account recovery almost squarely on the users shoulders; usually recovery is performed using backup codes or seed phrases only the user should have access to. This is not as scary as it sounds and should not be an excuse to use weaker MFA methods like email or text message (SMS).

Always be sure to use strong MFA methods, like TOTP or FIDO2 (hardware keys).

These backup codes are typically given after the user established a strong(er) MFA method for an account, such as TOTP. The time between this and when a backup code might be needed could be long - as such, it is important to safely and immutably store these codes.

While loss of access to MFA apps may seem wildly unlikely, some common scenarios could indeed make these more likely - and highlight the importance of keeping backup codes and seed phrases - such as:

• Change of smartphone
• Loss/theft of MFA device (such as a smartphone)
• Awry authenticator app changes/lost codes/lost secrets/etc

With seed phrases and keys, failure to safeguard these could result in a permanent loss of data or assets. Seed phrases are commonly associated with cryptocurrency wallets and blockchain-based applications, such as private messenger Session. Seed phrases can function as backup codes in practice; they are frequently used for transferring data between devices, without starting a "fresh" wallet or account.

1. Writing down codes

More conventional advice urges users to write down backup codes. This is usually a quick method that requires little effort besides coughing up pen and paper - which most people have on hand at their desks/workspaces at just about any moment.

While usually good enough for both security and contingencies where the backup codes are actually needed, users should use care when writing down codes. At the bare bones, users will want to make sure the codes are transcribed correctly, legible, and stored in a safe-ish location.

Transcription

In this case, transcription of the code is writing it down on paper. If you write the code down wrong, then it will do you absolutely zero good in the case where you might need it.

To be sure the code or seed phrase is transcribed correctly, it is good practice to test them as if you were using your written transcription to recover an account – a “table-top” exercise, if you will. In your tests, you’ll want to simulate:

• Not having access to your MFA method
• Not having any other form of the backup code/seed phrase other than the written-down version
• Possibly not having your password or another method of MFA configured on the account

Note: Some codes can only be used once.

If you choose to write down backup codes, then you’ll want to ensure they’re legible and resistant to fading. General advice says to avoid writing down codes in pencil, which is prone to fading compared to using a pen or sharpie marker.

For best legibility, users should take their time in actually writing down the codes. Be aware that L can be easily mistaken for a lowercase I or the number 1. The letter O can be mistaken for the number 0. To alleviate these common transcription errors, users may want to make sure there is a clearly difference between letters, numbers, and symbols (if applicable.)

You should also transcribe the code exactly as you see it – it may be case sensitive! If you accidentally record a lowercase g where it should have been uppercase, then it may spell problems for you later on when you go to use the code.

Safe storage location

For physical mediums, the storage location of the medium is perhaps the biggest factor in its security and integrity; the paper on which you write down your codes should be kept in a safe location.

When considering a safe physical location, at minimum users should ensure the storage location is one where they have primary access and control. Users should also be aware of who, if anyone, has direct access to this storage location.

In households with live-in family members and roommates, it’s possible for snooping and/or accidental destruction/throwing away of notebooks or papers that contain backup codes or seed phrases; so, generally, it’s best to pick a storage place that limits these plausible scenarios.

2. Print out codes

Many services will encourage users to print out backup codes/keys and seed phrases.

The main issue here: Do you have a printer? (I know I don’t.) For this reason alone, other suggestions in this post for storing backup codes - including writing down codes - may be a more fitting idea for many users.

If a user does not have a printer, there do exist printing services - such as those offered at an office supply store.

However, there could be “operational security” (OpSec) issues with using a third-party printing service; users are typically asked to email their document to be printed to the printer’s queue. But who also has access to the document in the queue? Are there any retention periods for the emailed document(s)? Answers to these questions would depend on the printing service's privacy policy.

3. Upload codes to encrypted cloud providers

For ready-access to backup codes in a situation where using one is needed, users could use a trusted cloud storage provider to store these codes. A cloud storage provider would provide seamless access to the codes, which should fit just about any situation where quick access to the codes is needed.

Users should ensure (at least, to the best of their ability) the cloud provider uses zero-knowledge encryption to store files. Many cloud storage providers still have direct access to file metadata, such as file type and size.

Many cloud storage providers (and third-party service providers doing business for the cloud provider) retain the keys to decrypt your files without access to your account - also, your files are not encrypted by default prior to upload to the server.

If using a zero-knowledge encrypted cloud provider like Proton Drive or Skiff Drive is not possible, then users should definitely encrypt the files (especially backup codes) prior to upload to the storage provider's server(s)!

However, a major downside is if you lose access to your cloud provider account, and the code is stored in that account, then you’ve effectively loss access to the codes themselves.

A possible workaround is to keep a physical copy - whether printed out or written down - of the code to the cloud storage account somewhere safe, which takes us back to the points in the first section.

4. Store on a “cold” device

Two methods to encrypt: encrypt the codes and/or encrypt the device. Or both, for maximum security in the event the cold device is lost or stolen or otherwise compromised.

At minimum, users should encrypt the drive - this helps mitigates compounding negative effects if it is lost or stolen. With an unencrypted drive, as long as a user has possession of it they can view its contents; by encrypting the drive, the person with possession would need to also know/have the decryption key (password) to view the contents of the drive.

Encrypting storage devices

Most operating systems, including most Linux distributions can encrypt drives without third-party software:

• Encrypting USB drives on Windows
• Encrypting USB drives on macOS
• Encrypting USB drives on most Linux distributions

Many Linux distributions , such as Linux Mint, have a built-in graphical user interface (GUI) for encrypting drives. If not a GUI, then the utility most likely exists within the distribution itself and would be made available via the command line.

Users should research whether their chosen distribution offers something similar before downloading additional software/utilities; a good place to check is in your particular distribution’s documentation pages.

It helps to follow best practices for establish strong passwords when choosing a password (decryption key), which include (but are not limited to):

• Use 20 characters or more
• Avoid using common dictionary words
• Avoid using commonly known or easy to find information like spouse's names or pet's names
• Never reuse a password
• Avoid known compromised passwords

Users should also consider using passphrases in place of more traditional passwords; in most cases, length beats complexity but using both together generates the "best" passwords, which are exceedingly hard to guess or crack even via automated means.

Encrypting codes/files

Alternatively or alongside device encryption, users can use an encryption utility, like Picocrypt, to encrypt something like a compressed .zip archive of the backup codes.

Picocrypt is lightweight and easy to use; it's primary purpose is to encrypt files - which makes it a perfect utility for someone looking to encrypt something like a .txt file of all their backup codes and seed phrases.

A possible method for storing codes would be to:

1. Create a .txt file containing all the codes, separated and labeled clearly for each service.
2. Compress this file into a .zip file.
3. Use Picocrypt to encrypt the newly created .zip file
4. Store the password/key to the newly encrypted file some place safe.

Picocrypt could be used to encrypt files prior to upload to any cloud provider as well.

Key management and device storage

Whether you choose to encrypt the file(s) containing your backup codes or encrypting the entire storage device, you will have to keep up with at least one decryption key (password).

Keep in mind, that with encrypting both you will have to keep up with two encryption keys to have access to your codes; these could be stored on a completely physical medium like a notebook kept in a safe and secure location (reference the “Writing down codes” section of this post)

Similar to writing down or printing out the codes, since the cold device is something physical, you would need to carve out a safe place to put it.

Ideally, you would cap the drive to minimize chances of the build malfunctioning and/or prematurely wearing and then put it in a container, like a personal lockbox or safe; this storage container should, again, be stored somewhere where you have access and control.

While convenient and tempting for some users, it is not wise to store the encryption key on the same device holding the USB drives.

Avoid storing the password/decryption key on a device used regularly; your regularly used devices are more than likely connected to the internet and there always exists a possibility you could fall become infected with malware or suffer something like data loss. If you store the key on regularly used devices, you are risking losing it all together in the event your data becomes compromised or erased.

A solid place to store the password/decryption key for the encrypted device holding your backup codes or seed phrases is using a physical medium - such as printing or writing down the password and storing it in a safe location. Be sure to test the printed out/written down key works to actually decrypt your encrypted files!

Avoid The Hack’s recommendation

Use multiple methods, or at least considering a main method and then a failsafe method - nothing is 100% foolproof.

For example, users can use a fully-encrypted USB drive to store their codes. The drive itself and the keys keys (or password) for its decryption could be stored in a physical document lock box.

Final thoughts

Managing and storing backup codes is a overall easy. However, users should put some thought into how they store their backup codes for strong(er) MFA methods especially.

Users should not let the management of backup codes stop them from using more secure methods of MFA, establishing their own custodial wallets independent of cryptocurrency exchanges, or avoiding using more secure and private applications where possible.

Backup code, key, and seed phrase management is simple once a process has been established; the legwork is getting the process going successfully. Afterwards, it is merely "maintenance" and additions to the already existing process.

Whatever method(s) you choose to store your backup codes or seed phrases, remember it is far better to have some type of system versus none at all - after all you may need these codes to recover locked out accounts in the future!

Acknowledgments

Thank you to user defr0ke for the idea to make this a separate post!

Stay safe out there!