Where Are Your Passwords? Password Storage, Managers & 2FA

Information Technology IT Learning - Q&A
1

Password Security – Storage, Password Managers & TOTP

Living topic: This information may be updated as applications, features, prices and security practices change. The individual recommendations may evolve, but the core principles should remain relevant: use unique credentials, store them securely, enable additional authentication where possible, and maintain a recovery plan.

This topic expands on the earlier discussion:

2024 – General Account Security – Passwords & 2FA

That topic contains additional information about two-factor authentication, password managers and my later testing of Aegis Authenticator.

The related blog article can also be found here:

2FA & General Account Security

Some information in those earlier posts may eventually need updating as the applications and available features change. This topic will focus more specifically on passwords, password storage, password managers and applications that can generate TOTP authentication codes.

Further posts will cover subjects such as:

  • Password-manager backups

  • Authenticator backups

  • Recovery codes

  • Losing or replacing a phone

  • Losing a master password

  • Emergency access

  • Business password management

  • Passkeys and hardware security keys

  • Testing your recovery process

This first post is the main guide.

TLDR

  • Do not use the same password for multiple accounts.

  • Do not use predictable variations such as P@55W0rd_Facebook and P@55W0rd_Twitter.

  • Long, unique passwords are more useful than predictable character substitutions.

  • Do not keep important passwords in an unsecured Notepad, Word, Excel or phone-notes file.

  • A physical password book is not automatically unsafe, but it can be lost, stolen, damaged or found beside the device it unlocks.

  • Browser password managers are suitable for many ordinary users and are much better than password reuse.

  • Dedicated password managers provide greater flexibility across browsers, platforms and, in some cases, desktop applications.

  • Not every password manager generates TOTP authentication codes.

  • Protecting a password vault with MFA and generating MFA codes for other accounts are two different features.

  • Free, subscription, lifetime-payment, cloud-hosted, local-first and self-hosted options are available.

  • The best solution is not necessarily the most expensive or technical one. It is the one you understand, maintain, back up and actually use.

  • Everything normally appears fine without proper security—right up until something goes wrong.

Users and Security Have Not Evolved at the Same Rate

The online world has changed considerably, but many users’ security habits have remained largely the same.

Data breaches, phishing, credential theft, malware and social engineering are no longer unusual events. Despite that, many people still use passwords such as:

  • Password01

  • Changemenow

  • P@55W0rd

  • A pet’s name

  • A child’s name

  • Their username

  • Their username followed by a number

  • Their telephone number

  • Their date of birth

  • Their business name

Some create one basic password and add the service name:

  • P@55W0rd_Facebook

  • P@55W0rd_Twitter

  • P@55W0rd_Gmail

This may appear to give every account a different password, but the pattern is predictable. Once one password is exposed, the others are not particularly difficult to work out.

Replacing a with @, s with 5, i with 1, or o with 0 does not automatically create a strong password. These substitutions have been used for decades and are already accounted for by password-cracking tools.

Modern guidance places greater importance on:

  • Length

  • Uniqueness

  • Unpredictability

  • Avoiding known compromised passwords

  • Not reusing credentials

A long, randomly generated password does not need to be remembered by the user when it is stored in a properly protected password manager.

You should ideally remember only the strong master password used to unlock the manager.

Where Are Your Passwords Stored?

Choosing better passwords is only part of the solution. You also need somewhere safe and reliable to keep them.

Some people still write passwords in a notebook or diary. Others store them in:

  • Notepad

  • Microsoft Word

  • Microsoft Excel

  • Phone notes

  • Email drafts

  • WhatsApp messages

  • Cloud-storage folders

  • Files conveniently named Passwords.txt or Passwords.xlsx

These storage methods are not all equally risky.

Physical password books

A physical password book cannot be remotely extracted by malware. A notebook stored securely at home may be safer than using the same password for every account.

However, the book can still be:

  • Lost

  • Stolen

  • Damaged by water

  • Destroyed by fire

  • Accidentally discarded

  • Read by someone else

  • Left behind during travel

There is also an obvious problem when the password book is carried in the same bag as the phone or laptop it unlocks. Someone who steals the bag may receive both the device and its passwords.

A physical book is therefore not automatically insecure, but its physical security and recovery plan must be considered.

Unprotected electronic files

Plaintext files introduce a different set of risks.

Anyone who gains access to the computer may be able to open, copy or photograph the information. Malware may search local storage for credentials. Cloud-synchronization software may upload the file to other devices. The file may also unintentionally appear in backups, shared folders or email attachments.

Naming the file Passwords.xlsx does not improve the situation.

Recent versions of Microsoft Word and Excel can encrypt documents with a password, but they still were not designed specifically for credential management. They generally do not provide the same password generation, login matching, TOTP generation, breach warnings, browser integration, secure sharing or organizational features as a proper password manager.

A second copy is also not automatically a proper backup.

Three unprotected copies of a password spreadsheet on three USB drives are still three unprotected copies.

What Does a Password Manager Do?

A password manager stores credentials inside an encrypted vault or database.

Depending on the application, it may also:

  • Generate long and random passwords

  • Store usernames and passwords

  • Fill website login forms

  • Fill supported mobile applications

  • Fill traditional desktop applications

  • Store credit-card details

  • Store identities and addresses

  • Store secure notes

  • Store software licence information

  • Detect reused passwords

  • Warn about exposed credentials

  • Generate TOTP authentication codes

  • Store passkeys

  • Synchronize between devices

  • Share credentials securely

  • Provide emergency access

  • Maintain password history

You do not need every available feature.

An ordinary user may only need secure password generation, synchronization and autofill. A technical user may want a locally managed database, custom fields, browser integration, TOTP generation and private LAN-only synchronization.

A business may require central administration, shared vaults, access control, employee offboarding and emergency-access procedures.

There is no single solution that is ideal for everyone.

Browser Password Managers

Applications such as Google Chrome, Microsoft Edge, Firefox and Safari include password-management features.

For many ordinary users, these are perfectly reasonable starting points.

If the realistic choice is between:

  1. Reusing Password01 everywhere, or

  2. Allowing the browser to generate and save a unique password,

the browser password manager is the considerably better option.

Google Password Manager

Google Password Manager can:

  • Generate and store passwords

  • Store passkeys

  • Synchronize through a Google account

  • Fill websites in Chrome

  • Fill supported Android applications

  • Check for some compromised credentials

Its functionality extends beyond websites on Android and supported mobile platforms. However, on a Windows desktop it remains strongly connected to Chrome and web-based logins.

It is not intended to fill arbitrary traditional Windows applications such as:

  • Older accounting programs

  • Pharmacy-management systems

  • Desktop trading applications

  • Specialist business software

  • Locally installed administrative tools

Google Password Manager is also not a general-purpose TOTP authenticator. Google provides Google Authenticator separately for that purpose.

Browser managers are not useless or automatically insecure. Their main limitation is that they may not cover everything a user needs outside the browser or its associated ecosystem.

Dedicated Password Managers

A dedicated password manager normally provides broader browser, device and platform support.

Depending on the product, it may also support:

  • Windows application logins

  • Secure notes

  • Credit cards

  • Identities

  • TOTP generation

  • Local synchronization

  • Self-hosting

  • Emergency access

  • Password sharing

  • Family or business vaults

Some are free. Some require subscriptions. Some offer lifetime licences. Others allow users to manage the encrypted database themselves.

The correct choice depends on what you use and how much responsibility you are willing to accept.

Online, Local-First and Self-Hosted Options

These terms are often mixed together, particularly outside technical discussions.

Vendor-hosted

The password-manager provider operates the synchronization service. Your encrypted vault is synchronized through its infrastructure.

This is normally the easiest arrangement for ordinary users.

Cloud-synchronized database

An encrypted password database is stored in a service such as:

  • Google Drive

  • Microsoft OneDrive

  • Dropbox

  • Nextcloud

The cloud provider stores the encrypted file, while the password-manager application opens and manages its contents.

Locally synchronized

The encrypted database is synchronized privately between devices using tools such as:

  • Syncthing

  • Resilio Sync

  • A network-attached storage device

  • A local server

  • Other LAN or Wi-Fi synchronization tools

The database does not necessarily need to leave the user’s local network.

Local-only

The database remains on one device or is moved manually between trusted devices.

This provides greater local control but places more responsibility on the user to maintain backups.

Self-hosted service

The user or business operates the password-manager server on its own:

  • VPS

  • Virtual machine

  • Physical server

  • Private cloud

  • Local infrastructure

Bitwarden is an example of a password-management service that can be self-hosted.

For KeePassXC, I will generally use the terms local-first or self-managed. It does not require a password-management server, although its encrypted database can be synchronized using whatever method the user chooses.

Avoiding a subscription does not necessarily mean giving up synchronization.

Password Managers and TOTP

This is where the terminology becomes confusing.

When someone says that a password manager “supports 2FA,” that can mean two different things.

1. MFA protects the password manager

The password manager requires an additional code, security key or approval before allowing access to the vault.

This protects the password manager itself.

2. The password manager generates TOTP codes

The password manager stores the TOTP secret for another website and generates the rotating six-digit authentication code.

This allows the password manager to function as both:

  • The password vault

  • The authenticator for supported accounts

These are two separate capabilities.

A product may support MFA for its own vault without generating TOTP codes for other websites.

Should Passwords and TOTP Codes Be Kept Together?

There are two reasonable positions.

Keeping them together

Storing the password and TOTP information in the same password manager is convenient.

The manager may:

  • Fill the username

  • Fill the password

  • Generate the TOTP code

  • Copy or fill the code automatically

This is still considerably better than using no MFA at all. It protects against password reuse, basic credential theft, many database breaches and numerous automated attacks.

Keeping them separate

The traditional purpose of a second factor is to require something separate from the password.

When the password and TOTP secret are stored in the same vault, anyone who gains complete access to that unlocked vault may obtain both.

A separate authenticator preserves greater separation.

For especially important accounts, such as:

  • Primary email

  • Password-manager accounts

  • Financial services

  • Business administration

  • Server management

  • Cloud infrastructure

  • Domain administration

it may be preferable to keep the TOTP code in a separate authenticator or use a phishing-resistant method such as a passkey or hardware security key.

There is no need to treat this as an all-or-nothing decision.

Some accounts can use integrated TOTP for convenience, while more sensitive accounts remain in a separate authenticator.

Password-Manager Options

The products below are not the only available password managers. They are included because they represent several different approaches and payment models.

Prices and features can change, so check the official pages before purchasing or migrating.

Google Password Manager

Official website

Suitable for:

  • Ordinary Chrome users

  • Android users

  • Users who primarily access websites

  • Users who currently reuse passwords

  • Users who want something already built in

Advantages:

  • Free

  • Integrated with Chrome and Android

  • Password generation

  • Password synchronization

  • Passkey support

  • Website and supported mobile-app autofill

  • No additional application required for basic use

Limitations:

  • Strongly tied to the Google ecosystem

  • Limited use with traditional Windows desktop applications

  • Not a general TOTP generator

  • Fewer advanced organizational and sharing options than dedicated managers

For many ordinary users, Google Password Manager is enough. It is certainly better than memorizing and reusing one weak password.

KeePassXC

Official website
Downloads
Documentation
User Guide

Suitable for:

  • Technical users

  • Privacy-focused users

  • Users who want local control

  • Users avoiding recurring subscriptions

  • Users who want to choose their own synchronization method

Advantages:

  • Free

  • Open source

  • Local-first

  • Encrypted KDBX database

  • Browser integration

  • Password generation

  • TOTP generation

  • Custom fields and secure notes

  • Auto-Type for many desktop applications

  • User-controlled synchronization

  • No mandatory vendor account

The database can be:

  • Stored locally

  • Copied manually

  • Stored in encrypted cloud storage

  • Synchronized using Syncthing

  • Synchronized using Resilio Sync

  • Synchronized through a NAS or local server

KeePassXC itself is available for Windows, Linux and macOS. Compatible KeePass applications are required to open the same database on Android or iOS.

Possible mobile applications include:

  • KeePassDX

  • KeePass2Android

  • Strongbox

  • KeePassium

Limitations:

  • More technical setup

  • The user is responsible for synchronization and backups

  • Mobile use requires a compatible third-party application

  • Auto-Type may require configuration

  • Card storage is possible through fields and notes, but it is not as polished as dedicated card and identity forms in some commercial products

KeePassXC is my main recommendation for someone who wants a free, flexible and privacy-focused solution and is prepared to manage it properly.

Bitwarden

Official website
Password-manager plans
Bitwarden Authenticator
Integrated Authenticator
Self-hosting documentation

Suitable for:

  • Users wanting a dedicated cross-platform manager

  • Users wanting a useful free tier

  • Users wanting a reasonably priced paid option

  • Individuals, families and businesses

  • Technical users interested in self-hosting

Advantages:

  • Useful free password-manager tier

  • Works across major browsers and platforms

  • Password and passkey storage

  • Card and identity storage

  • Secure notes

  • Password generation

  • Vendor-hosted synchronization

  • Self-hosting available

  • Family and business options

  • Separate Bitwarden Authenticator application

Bitwarden currently has two different authenticator arrangements:

  1. Bitwarden Authenticator is a separate mobile application that can generate TOTP codes.

  2. Integrated TOTP generation inside Bitwarden Password Manager is a paid feature.

This distinction is important when comparing the free and paid options.

Bitwarden is one of the easiest general recommendations for someone who wants more flexibility than a browser manager without paying a high recurring cost.

Self-hosting is available, but operating a password-management server also creates maintenance, update, backup and security responsibilities.

RoboForm

Official website
Personal plans
User manual
Windows application logins
RoboForm TOTP Authenticator

RoboForm was one of the earliest password managers to achieve widespread commercial use and has been developed since around 2000.

Suitable for:

  • Ordinary users

  • Users wanting convenience

  • Users with many online forms

  • Users who store identities and card information

  • Users who need Windows application login support

  • Users who want integrated TOTP generation

Advantages:

  • Strong website autofill

  • Identity and address filling

  • Card storage

  • Password generation

  • Cross-platform synchronization

  • TOTP generation

  • Windows application logins

  • Secure sharing

  • Emergency-access options

  • Family and business plans

RoboForm is likely to be one of my first recommendations for an ordinary user who wants a polished solution and does not want to manage databases, synchronization tools or local infrastructure.

It is particularly relevant when the user must enter credentials into both websites and traditional Windows applications.

The main consideration is that full cross-device use and advanced functionality are generally subscription-oriented.

Sticky Password

Official website
Features
Lifetime licence
Local Wi-Fi synchronization
Protecting the vault with 2FA

Suitable for:

  • Users who prefer a one-time purchase

  • Users who want local synchronization

  • Users who want card and identity filling

  • Users who want desktop-application support

  • Users who do not want to depend entirely on cloud synchronization

Advantages:

  • Subscription and lifetime-payment options

  • Cloud synchronization

  • Local Wi-Fi synchronization

  • Local-only operation

  • Password generation

  • Card storage

  • Form filling

  • Application login support

  • Portable Windows version

  • MFA protection for the Sticky Password vault

Sticky Password gives users more synchronization choices than many ordinary cloud-based managers. The encrypted database can be synchronized through the provider, over the local network, or kept only on selected devices.

I have a lifetime licence and used Sticky Password previously.

At the time of writing, I have not found official confirmation that Sticky Password can generate third-party TOTP codes for other websites. Its documented two-factor authentication feature protects access to the Sticky Password vault itself.

That distinction may be important for users who specifically want their password manager to generate authentication codes.

Norton Password Manager

Official website

Suitable for:

  • Users already familiar with Norton

  • Users wanting a free basic password manager

  • Users primarily managing websites

  • Users wanting password and card autofill

Advantages:

  • Available as a free standalone password manager

  • Also included with Norton products

  • Password generation

  • Password synchronization

  • Website autofill

  • Card storage

  • Encrypted online vault

  • Familiar brand for many non-technical users

Limitations:

  • Cloud-oriented

  • Limited traditional Windows application support

  • No established integrated third-party TOTP generator

  • Less flexible than KeePassXC, Bitwarden or RoboForm for advanced use

I would consider Norton Password Manager a valid basic option, particularly for someone already comfortable with Norton. It would not necessarily be my first recommendation for a technical or privacy-focused user.

Authenticator Applications

A password manager and an authenticator do not have to be the same application.

For ordinary users, Duo Mobile, Authy, Google Authenticator, Microsoft Authenticator or whichever reputable application they already understand may be sufficient.

The important questions are:

  • Can the authenticator be backed up?

  • Is the backup encrypted?

  • Can accounts be exported?

  • Can accounts be restored to a replacement phone?

  • Does the user know the backup password?

  • Are recovery codes stored somewhere safe?

  • What happens if the phone is lost today?

Aegis Authenticator

Official website
My earlier Aegis review and screenshots

Aegis is currently my preferred Android authenticator.

Advantages include:

  • Encrypted vault

  • Password or biometric protection

  • Encrypted exports

  • Automatic backup support

  • Import from several other authenticators

  • Flexible organization and display options

  • Individual-account sharing through QR codes

  • Local control

  • No mandatory authenticator-provider account

Aegis is Android-only.

I personally use both Aegis Authenticator and KeePassXC.

Some TOTP entries are kept specifically in Aegis. Others are duplicated in KeePassXC where desktop access, easier transfer or additional recovery options may be useful.

Duplicating a TOTP secret improves availability, but it also means that every copy must be protected. This should be a deliberate choice rather than something done without understanding the consequences.

Authy

Official website
Authy Desktop end-of-life notice

Authy remains a familiar option for many users and provides encrypted mobile synchronization and backup.

However, Authy’s desktop applications for Windows, Linux and macOS reached end of life on March 19, 2024.

It should now be considered primarily a mobile authenticator.

Users must also remember and securely store the password used to encrypt their Authy backups. Authy cannot simply reveal that password if it is forgotten.

Duo Mobile

Official website
Third-party TOTP accounts
Duo Restore

Duo Mobile is widely associated with business, school and organizational authentication, but it can also generate standard TOTP codes for personal third-party accounts.

It may be a reasonable choice for someone who already uses Duo through work or another organization.

Backup and recovery must be configured beforehand. Third-party accounts cannot simply be exported from Duo, and Duo Support cannot reconstruct them without an appropriate backup or reprovisioning process.

Recommendations by User Type

The ordinary browser-based user

Start with Google Password Manager or another reputable manager already built into the browser or device.

The immediate goal should be to stop password reuse and begin generating unique credentials.

The ordinary user wanting a dedicated manager

Consider Bitwarden or RoboForm.

Bitwarden offers a strong free starting point and reasonably priced upgrades. RoboForm offers excellent convenience, form filling and Windows application support.

The privacy-focused or technical user

Consider KeePassXC.

You control the encrypted database, storage location, synchronization system and backup process.

The user who wants a one-time payment

Consider Sticky Password.

It offers a lifetime licence and several synchronization choices, including local Wi-Fi synchronization. Be aware of the apparent lack of integrated third-party TOTP generation.

The Android user wanting a separate authenticator

Consider Aegis Authenticator.

It provides strong local control, encrypted exports and flexible backup options.

The user who needs Windows application logins

Consider RoboForm or Sticky Password.

KeePassXC Auto-Type may also work, but it requires more setup and may not be as straightforward for an ordinary user.

The business user

Use a centrally managed business password system wherever possible.

Business credentials should not depend entirely on one employee’s personal password vault, personal email account or personal phone.

The organization should consider:

  • Credential ownership

  • Access control

  • Secure sharing

  • Employee departures

  • Emergency access

  • Shared service accounts

  • Recovery information

  • Backup responsibility

  • Administrative logging

  • MFA requirements

Business password management will be covered separately.

Security Still Requires User Responsibility

A password manager improves security, but it does not remove personal responsibility.

A secure vault can still be undermined by:

  • A weak master password

  • An unlocked computer

  • Malware

  • Unprotected exports

  • Missing backups

  • Poorly stored recovery codes

  • Sharing the master password

  • Ignoring security warnings

  • Approving unexpected authentication requests

  • Failing to update devices and applications

Companies and service providers also have a responsibility to secure their infrastructure. However, users remain responsible for how they create, store, share, back up and recover their own credentials.

Bad actors (malicious persons) have evolved.

The tools used to steal accounts have evolved.

The amount of personal and business information stored online has increased.

Users need to evolve as well.

Yes, unique passwords, password managers, MFA, recovery codes and encrypted backups can be inconvenient.

Everything normally appears fine without them—right up until something goes wrong.

That is usually when the words “if only…” appear.

Official Links

Password managers

Authenticators

Synchronization tools

Additional reading

2

Password Security – Backups, Recovery Codes & Lost Access

Living topic: This post may be updated as applications, features and recovery methods change. Images and screenshots will likely be added when time permits. The core principles should remain the same: maintain independent backups, understand how recovery works, and test everything before an emergency.

This follows the main guide on password storage, password managers and TOTP authentication.

The first guide focused on keeping unauthorized persons out of your accounts. This post deals with the other side of security:

How does the rightful owner get back in when something goes wrong?

TLDR — What Not to Do

  • Do not keep only one copy of your password database or authenticator vault.

  • Do not assume synchronization is the same as backup.

  • Do not leave password-manager or authenticator exports unencrypted.

  • Do not store recovery codes only inside the account or device they are supposed to recover.

  • Do not take screenshots of recovery codes without considering automatic cloud photo backups.

  • Do not use recovery codes as a routine substitute for your authenticator.

  • Do not store the only password for an encrypted backup inside that same backup.

  • Do not rely entirely on devices remaining signed in.

  • Do not erase an old device until the replacement has been fully tested.

  • Do not give someone unrestricted access to your entire vault merely because they may need to help you recover it.

  • Do not wait for an emergency before testing whether your recovery process works.

  • Do not assume the password-manager provider can retrieve your master password.

Good security keeps unauthorized people out. Good recovery ensures the rightful owner can still get back in.

This Can Affect Anyone

Losing access is not only a problem for inexperienced users.

It can happen because of:

  • A forgotten password

  • A lost or stolen phone

  • A failed storage drive

  • A damaged device

  • Accidental deletion

  • Database corruption

  • A factory reset

  • A cloud account being locked

  • An authenticator not being transferred before a device is erased

  • A forgotten backup password

  • Illness, death or incapacity

  • A business employee leaving without transferring credentials

Older persons may be especially vulnerable.

They may have difficulty remembering several passwords, understanding changing recovery procedures, navigating a replacement device or identifying which recovery information belongs to which account.

However, younger and technically capable users also lose access—usually because they assumed they would remember everything or believed that a signed-in device would always remain available.

Forgetting one ordinary account password may be an inconvenience.

Forgetting the master password to a vault containing hundreds of accounts may result in the complete loss of access to the vault.

Should the Provider Be Able to Recover Your Vault?

A reputable encrypted password manager should not be able to simply look up your master password or independently unlock and read your vault.

Many password managers use what is described as a zero-knowledge design. The provider stores encrypted information but does not possess the master password needed to decrypt it.

Personally, I would be concerned about any password-manager provider that could simply retrieve my master password or unlock my encrypted vault on request.

If the provider can access everything whenever it wants, someone else may eventually find a way to do the same.

However, that does not mean all forms of account recovery are bad.

Some providers offer recovery systems that must be configured or authorized beforehand, including:

  • Recovery phrases

  • Recovery files

  • Emergency kits

  • Trusted signed-in devices

  • Emergency contacts

  • Organization-managed account recovery

  • Administrator-assisted recovery for enrolled business users

The important distinction is that the provider should not secretly possess unrestricted access to the vault.

Recovery should depend on something that the user configured, saved, authorized or enrolled in beforehand.

For example, Bitwarden states that it cannot retrieve or reset the master password for an ordinary individual account. However, qualifying business organizations can configure administrator-assisted account recovery for enrolled members.

Proton offers several recovery methods, including recovery phrases, recovery files, trusted-device recovery and contact-assisted data recovery. With contact-assisted recovery, selected contacts can help verify a recovery request without gaining access to the user’s account or encrypted information.

Official references:

Greater Control Means Greater Responsibility

Self-managed and local-first applications provide users with greater control, but they also require active management.

KeePass and KeePassXC do not automatically take responsibility for:

  • Creating your backups

  • Keeping historical versions

  • Moving the database between devices

  • Protecting key files

  • Checking whether the backup is usable

  • Ensuring recent changes were included

  • Ensuring the master password is still known

  • Preventing synchronization conflicts

The encrypted database may be extremely secure, but that does not help if the only copy is lost, corrupted or stored on a failed device.

A manually copied KeePass database can be an excellent backup, but only when someone actually copies, protects and tests it.

This is not a fault with KeePassXC. It is part of the tradeoff involved in controlling your own database.

Greater control usually means greater responsibility.

Some self-managed applications can automate parts of the process.

Aegis Authenticator, for example, can create automatic backups of its encrypted vault to a location selected by the user. It can also retain multiple versions, depending on how it is configured.

Those files can then be copied or synchronized elsewhere using tools such as:

  • Syncthing

  • Resilio Sync

  • A local server

  • A NAS

  • An encrypted cloud-storage account

  • A normal backup application

Aegis distinguishes between:

  • Exports, which are created manually

  • Backups, which are created automatically

Both can use the same encrypted vault format.

Official reference:

Aegis Authenticator FAQ

Synchronization Is Not Necessarily Backup

Synchronization and backup are related, but they are not the same thing.

Synchronization attempts to keep the same current information on several devices.

A backup preserves a recoverable copy from an earlier point in time.

Consider a KeePass database synchronized between:

  • A desktop

  • A laptop

  • A server

  • A phone

  • Cloud storage

That arrangement provides several available copies.

However, if the database becomes corrupted, accidentally deleted or incorrectly modified, the bad change may synchronize to every connected device.

You may end up with five identical copies of the same problem.

A proper backup system should ideally retain previous versions so that you can return to a known working copy.

The same applies to authenticator vaults.

If an account is accidentally deleted from the authenticator and that deletion is immediately synchronized everywhere, a historical backup may be the only easy way to recover it.

Multiple current copies improve availability. Historical copies provide recovery.

Password-Manager and Authenticator Backups

Password-manager and authenticator backups serve similar purposes, but the recovery procedures may be different.

For password managers

You should know:

  • Where the vault is stored

  • Whether it is automatically synchronized

  • Whether previous versions are retained

  • Whether exported files are encrypted

  • Whether a separate key file is required

  • Whether the export contains attachments and custom fields

  • Whether the backup can be opened on another device

  • Whether recent entries are included

For authenticators

You should know:

  • Whether the application supports encrypted exports

  • Whether backups are automatic or manual

  • Whether a separate backup password is required

  • Whether entries can be imported onto another device

  • Whether individual entries can be transferred by QR code

  • Whether the application depends on a provider account

  • Whether business-managed accounts must be reactivated by an administrator

A screenshot of an authenticator screen is not the same as a properly protected authenticator backup.

A screenshot may not contain the information needed to recreate the TOTP entry. Even when it contains the original QR code, it creates another highly sensitive copy that must be protected.

Be Careful With Screenshots

Many users take screenshots of:

  • Recovery codes

  • TOTP setup QR codes

  • Passwords

  • Account recovery information

  • Backup phrases

  • Security questions

The intention may be to keep the information somewhere convenient.

However, phones frequently upload photographs and screenshots automatically to services such as:

  • Amazon Photos

  • Google Photos

  • Apple iCloud Photos

  • Microsoft OneDrive

  • Other gallery or cloud-backup services

Amazon Photos, for example, can automatically upload selected device folders or the entire camera roll.

A screenshot that the user believed existed only on the phone may quietly become a cloud-stored copy.

If the cloud photo account is compromised, the attacker may gain access to the recovery codes or QR codes stored in the gallery.

This is not theoretical. It can and does happen.

Do not assume that a screenshot remains only on the device where it was taken.

If a screenshot must be used temporarily:

  1. Move the information into its proper secure location.

  2. Delete the screenshot from the device.

  3. Check whether it was uploaded to a cloud-photo service.

  4. Delete the cloud copy.

  5. Empty the deleted-items or trash folder where appropriate.

Official reference:

Amazon Photos – Activate Auto-Save on Android

Recovery Codes Are Emergency Reserves

Many services provide recovery or backup codes when MFA is enabled.

Some services display them only once.

Others may allow the codes to be displayed, downloaded or regenerated later.

Do not rely on being able to retrieve them again after losing access.

Recovery codes should be:

  • Saved when first displayed

  • Clearly labelled

  • Stored securely

  • Kept independently from the authenticator

  • Protected from casual access

  • Replaced when exposed

  • Regenerated where appropriate after use

Do not store the only copy inside the account that the codes are supposed to recover.

For example, recovery codes for an email account should not exist only inside that same email account.

Similarly, do not leave the only copy on the phone containing the authenticator.

Many services provide a set of one-time codes. Once one is used, it cannot be used again. Other services may provide one recovery code that changes after use.

The exact implementation varies, but the principle remains the same:

Treat recovery codes as emergency reserves, not as convenient replacements for opening the authenticator.

Do not use a recovery code merely because you do not have immediate access to your normal authenticator.

When a recovery code must be used:

  1. Restore normal access to the authenticator.

  2. Review the account’s security settings.

  3. Confirm that the missing device has been removed where necessary.

  4. Download or generate a new set of codes if the service supports it.

  5. Replace the securely stored copy.

The Master Password Problem

A strong master password should not be easy for someone else to guess.

It must also be something the rightful owner can remember or recover.

That is where passphrases may help.

A passphrase uses several words or a sentence rather than one short password.

For example:

MyBirthDayIsDecember01

This is long, but it is based on information that may be publicly known or easy to discover.

I met my wife in NYC

This may be easier to remember, but photographs, anniversaries, social-media posts or conversations could reveal the information.

I call my husband Mellow in private

This may be less obvious if it is genuinely private, but natural sentences and personal facts are still less random than a password generated by a password manager.

A famous quote may also be memorable, but attackers have access to books, song lyrics, movie dialogue, famous speeches and common sayings.

A public profile phrase is also a poor choice.

For example, “Always busy learning” would not be a suitable master passphrase for someone who uses that phrase publicly.

A better approach is to combine unrelated words into something long but memorable:

Mellow repairs seven purple radios before sunrise

Do not use that exact example as a password. It is only intended to demonstrate the concept.

A good master passphrase should be:

  • Long

  • Unique

  • Memorable

  • Not published

  • Not based on obvious personal information

  • Not reused anywhere else

NIST currently recommends passwords of at least 15 characters when used as a single authentication factor and advises allowing long passphrases rather than depending on forced combinations of uppercase letters, lowercase letters, numbers and symbols.

Official reference:

NIST – How Do I Create a Good Password?

The master passphrase is the one password worth spending time learning.

Avoid Circular Recovery

A recovery system fails when the information needed to restore it is trapped inside the system that has been lost.

Examples include:

  • A KeePass key file stored only on the failed computer

  • The password for an encrypted backup stored only inside that backup

  • Cloud-storage credentials stored only in the database located in that cloud account

  • MFA recovery codes stored only on the lost phone

  • An authenticator backup password stored only inside the authenticator-related account

  • A recovery phrase stored only inside the encrypted account it is meant to recover

This creates a chicken-and-egg problem.

You need the account to retrieve the information, but you need the information to access the account.

At least one recovery method must remain independently accessible.

My Own Near-Lockout Experience

This issue is not merely theoretical for me.

One encrypted cloud service I use periodically requires full reauthentication using both the account password and 2FA.

I keep the account signed in on several personal devices as well as my server. Because the authentication cycles are staggered, the chance of every device requesting reauthentication at exactly the same time is relatively low.

However, low probability is not the same as impossible.

At one point, I came close to being locked out.

Fortunately, my 2FA information was also stored in Aegis Authenticator. I was able to authenticate normally without depending on one of the other devices remaining signed in.

That became an unplanned recovery test.

It confirmed that the independent authenticator copy worked when I needed it.

Keeping several devices signed in can provide additional resilience, but it is not a complete recovery plan. Sessions may expire, applications may be updated, devices may be reset, browser data may be cleared, or a security event may invalidate several sessions together.

A better arrangement combines:

  • More than one signed-in device

  • An independent authenticator

  • Securely stored recovery information

  • A tested backup

Trusted Devices Are Helpful, but Not Enough

Some encrypted services can use a trusted signed-in device to assist with data recovery.

That can be extremely useful.

However, relying entirely on a trusted device creates several risks:

  • The device may fail.

  • It may be lost or stolen.

  • The browser storage may be cleared.

  • The user may accidentally sign out.

  • An application update may require reauthentication.

  • A security event may revoke existing sessions.

  • Several devices may reach their reauthentication period at similar times.

Trusted devices should therefore be treated as one recovery method—not the only recovery method.

Where available, configure more than one independent option, such as:

  • A recovery phrase

  • A recovery file

  • A recovery email

  • A recovery phone number

  • A trusted signed-in device

  • An emergency contact

  • Offline recovery codes

Where Should the Master Password Be Kept?

This is one of the most difficult parts of recovery planning.

The master password protects the secure vault, but the user may still need a way to recover it.

Possible options include:

  • A sealed envelope in a secure safe

  • A safety-deposit box

  • A protected emergency document

  • A trusted spouse or family member

  • A trusted executor or attorney

  • A password manager’s emergency-access feature

  • A company-controlled break-glass process

For many ordinary users, a sealed recovery document held in one secure location—or by one carefully selected person—may be more realistic than a complicated recovery system they do not understand or maintain.

However, care is still required.

Being related to someone does not automatically mean that person should have unrestricted access to:

  • Email

  • Financial information

  • Banking credentials

  • Business accounts

  • Private communications

  • An entire password vault

There have been many situations where access intended only for assistance, death or incapacity was misunderstood or misused.

The post does not need to assume that family members are untrustworthy. The safer principle is:

Someone may be trusted to help with recovery without being given unrestricted day-to-day access to everything.

Possible arrangements include:

  • The person knows where a sealed recovery document is stored but does not hold it.

  • Emergency access includes a waiting period.

  • A recovery contact can verify a request without accessing the vault.

  • Financial and general account-recovery information are handled separately.

  • A professional executor or attorney is used for especially sensitive matters.

  • Access is granted only after defined circumstances occur.

Access to a password vault is also not necessarily the same as legal authority to manage a bank account, business or estate.

For older persons, assistance should be limited to what is genuinely required. Convenience should not automatically grant another person permanent access to every account.

No recovery arrangement is entirely risk-free.

The objective is to choose a risk that is understood and manageable instead of leaving recovery entirely to chance.

If the trusted person changes, a relationship ends, a sealed document is opened, or compromise is suspected, the master password and recovery information should be replaced.

Keep Versioned Backups

Do not allow every backup to be immediately overwritten by the newest copy.

Historical versions can protect against:

  • Database corruption

  • Accidental deletion

  • Incorrect edits

  • Synchronization conflicts

  • Ransomware

  • Discovering a problem days or weeks later

For a KeePass database, manually created copies could be named by date:

Passwords_2026-08-01.kdbx
Passwords_2026-08-08.kdbx
Passwords_2026-08-15.kdbx

A backup system, NAS or cloud provider may already retain historical versions automatically.

Aegis can also maintain several dated automatic backups when configured appropriately.

The naming method is not the important part.

The goal is to ensure that a damaged or incomplete current copy does not immediately replace every known working version.

Where Should Backups Be Stored?

There is no single correct storage location for everyone.

Options include:

  • An encrypted USB drive

  • An encrypted external drive

  • A second computer

  • A NAS

  • A local server

  • Encrypted cloud storage

  • A safety-deposit box

  • A secure physical safe

  • A trusted off-site location

  • A protected printed recovery sheet

A practical arrangement may include:

  1. One current working copy

  2. One local encrypted backup

  3. One separate or off-site encrypted backup

The copies should not all share the same failure risk.

For example, a password database and its only backup should not both be stored on the same laptop.

Similarly, keeping both copies in the same house may not protect against fire, flooding or theft.

Test Recovery Before You Need It

Most people do not test their recovery process.

They create a backup, see that a file exists and assume everything is fine.

However, the file may be:

  • Corrupted

  • Outdated

  • Empty

  • Missing recent entries

  • Protected by a forgotten password

  • Dependent on a missing key file

  • Stored in a location that is no longer accessible

Recovery should be tested:

  • After the system is first configured

  • After changing the master password

  • After changing the backup location

  • After moving to a new authenticator

  • After replacing a phone or computer

  • After major account-security changes

  • At least once per year

Testing does not require destroying the working setup.

You can:

  • Open a copy of the password database.

  • Confirm that the master password works.

  • Confirm that any required key file is available.

  • Check that recent entries are present.

  • Import an authenticator backup onto a spare or isolated device.

  • Confirm that recovery codes are readable.

  • Confirm that the backup location is still accessible.

  • Test one or two non-critical accounts.

The best time to test an emergency procedure is when there is no emergency.

Nobody wants to test recovery.

That is still better than discovering during an emergency that the backup is unusable.

Replacing or Upgrading a Device

When replacing a phone, computer or tablet, do not immediately erase the old device.

Use the following general process:

  1. Create a fresh encrypted backup.

  2. Install the password manager on the new device.

  3. Install or restore the authenticator.

  4. Import or synchronize the necessary information.

  5. Test several password-manager entries.

  6. Test several MFA-protected accounts.

  7. Confirm that current TOTP codes work.

  8. Confirm that recovery codes are still available.

  9. Confirm that the new device is registered with important accounts.

  10. Only then erase, reset, sell or trade in the old device.

The old device is temporarily one of the best recovery tools available.

Do not destroy that safety net before confirming that the replacement works.

Lost or Stolen Devices

Lost and stolen devices require a different response.

Modern Android and Apple devices generally provide options to locate, secure and remotely erase a lost device when the feature was enabled beforehand.

Remote wiping may require the device to reconnect to the internet before the command can complete.

Before remotely erasing the device:

  1. Attempt to locate or lock it.

  2. Confirm that another usable copy of the vault exists.

  3. Confirm access to the password manager.

  4. Confirm access to the authenticator or recovery codes.

  5. Confirm access to the account controlling remote-device management.

  6. Remotely erase the device when necessary.

  7. Revoke important account sessions.

  8. Remove the device from trusted-device lists where appropriate.

  9. Change credentials if unauthorized access is suspected.

For Apple devices, do not casually remove a stolen device from Find My after erasing it. Removing it from Find My may also remove Activation Lock and make the device easier for a thief to resell.

Official references:

Remote wiping is useful, but it is not a substitute for backups.

Once your only copy is no longer trapped on the lost device, remote wiping becomes a much safer decision.

Business Recovery

Businesses should decide their own governance, access and recovery policies.

However, they should strongly consider using a centrally managed password platform instead of allowing critical credentials to remain solely inside:

  • One employee’s personal password vault

  • One employee’s email account

  • One employee’s phone

  • An unsecured spreadsheet

  • A notebook known only to one person

A centrally managed business product can help with:

  • Ownership of credentials

  • Shared access

  • Employee departures

  • Emergency access

  • Administrative recovery

  • Access removal

  • MFA enforcement

  • Audit records

  • Business continuity

Critical services should not become permanently inaccessible because one employee leaves, becomes unavailable or forgets a password.

The detailed procedures will vary by business and will be covered separately.

Final Thoughts

Security is intended to prevent unauthorized access.

Recovery is intended to preserve authorized access.

A system that does only one of those jobs is incomplete.

Everything normally works until it does not.

After that, the thoughts are usually:

  • “If only I had made a backup.”

  • “If only I had saved the recovery codes.”

  • “If only I had transferred the authenticator.”

  • “If only I remembered the master password.”

  • “If only I had tested it first.”

Recovery planning is what determines whether a problem remains an inconvenience or becomes permanent loss.

Do not wait for the emergency to discover whether your plan works.