Password Changes and Encrypted Data Recovery

Understand the difference between changing a known password, resetting sign-in, and recovering encrypted financial values.

A password reset can restore access to your PopaDex sign-in without restoring the key needed to read encrypted financial values. Before resetting, save your encryption recovery code and preserve any device session that can still read your data.

Changing a password you know

The password-change flow verifies the existing data-encryption key and protects that same key with the new password. Rails commits authentication and the replacement wrapper atomically under revision checks. Financial records are not rewritten. For enrolled version 1 accounts, the client submits independent derived authentication credentials and public metadata; the entered password and financial wrapping key remain client-side. Browser and isolated physical iPhone tests verified unchanged historical ciphertext after password changes.

If you have already attempted a change, check that your existing account names, balances and history are still readable. If an encryption error appears, retain your recovery code and contact support with the error text, without sending either password.

Resetting a forgotten password

Start from the forgotten-password option on the sign-in screen and follow the account-recovery instructions. If your account has encrypted financial data, the flow may also request its encryption recovery code.

When recovery succeeds, the browser is intended to recover the existing data-encryption key and submit a newly wrapped copy for use with your new password. Sign-in success alone does not establish that this key update succeeded.

The recovery pairing and rewrapping defects found on 6 October have been fixed for new setup and verified recovery paths. Historical recovery wrappers created from zeroed bytes remain invalid: deployment cannot restore an unknown original key. Keep the original vault credential or a device that still decrypts your data, and regenerate recovery material while that key is accessible. After recovery, check that your previous financial values and history display correctly. Do not clear a working device or reinitialise a vault to repair inaccessible historical ciphertext.

Resetting without an encryption recovery code

A Devise login-reset token or a separate account sign-in recovery code authorises authentication recovery. Neither is the financial recovery secret or an input to DEK derivation. The application can reset your sign-in password without receiving a recovered encryption key. It warns that you may lose access to previously encrypted data.

This does not automatically delete every stored record, and it does not prove permanent loss in every case: an existing working key, a known old password or usable recovery material may still matter. However, the new sign-in password alone cannot unlock a key that remains protected by the old password.

Accounts without initialized browser encryption do not have this particular key-recovery requirement. Other sign-in checks still apply.

Privacy of the recovery process

Enrolled version 1 accounts submit a locally derived authentication credential, not the entered password. Legacy accounts continue their password route until explicit migration, including one final successful legacy login. Encryption recovery keys are generated and displayed entirely on the client; Rails receives only wrapped-key material and derivation metadata. Account sign-in backup codes and reset tokens remain separate server-handled authentication features. This does not make email, billing, financial metadata or every other personal field end-to-end encrypted.

For details, read how encryption works and recovery-code management. Never send your password or recovery code to support.

Was this article helpful?

Last updated: October 08, 2026

Questions? Contact Support