Old password with old vault backup can decrypt current vault

[GICodeWarrior]

Version

master

Source

GitHub

Vault encryption

Yes

Device

N/A

Android version

N/A

ROM

No response

Steps to reproduce

1. Create a new encrypted vault with a password
2. Add a vault entry called "BEFORE"
3. Setup vault backups and/or export encrypted vault
4. Change the vault password
5. Add a vault entry called "AFTER"
6. Backup/export the vault again
7. Use the old/original vault password to decrypt the master key on the first backup/export
8. Use that master key to decrypt the newer vault. Note that both "BEFORE" and "AFTER" are accessible without knowing the new password.

If a backup password is configured, either change the backup password instead of the vault password, or remove the backup password for this test.

What do you expect to happen?

An old vault and old password should not be sufficient to decrypt a newer or older version of the same vault that use a different password.

Changing the vault password should generate a new master key.

What happens instead?

An attacker with access to vault backups and an old vault password can decrypt newer and older versions of the same vault that use a different password.

Log

No response

[alexbakker]

This is inherent to how Aegis' vault format was designed. It's inspired by LUKS and thus has similar trade-offs.

Rotating the master key would not just require entering the new password. It would also require providing the credentials for all other slots that may be present, such as the separate backup password and biometrics (if configured).

Additionally, because of Aegis' offline nature, rotating the master key doesn't magically protect a user if their old password and backup were compromised. The attacker can still decrypt the old backup and extract the OTP secrets. The only real mitigation for a compromised vault is to generate new OTP secrets for every account.

I would not be against providing master key rotation as an option in the app, but we have to figure out how to present it. A regular user is not going to understand something like "Rotate master key", and any wording that implies it retroactively secures old backups would give a false sense of security.

[GICodeWarrior]

Thanks for that context.

My concern is that a careful user (e.g. who changes their vault password and rotates all tokens) is still vulnerable to this issue. When a user changes their password, I think it's natural for them to expect their old password will not decrypt their new tokens.

It seems reasonable to require the user to confirm each other vault password during vault password change. In practice, that would be zero or one additional password to type, right?

LUKS doesn't include a backups implementation. They left the issue for the backup implementor to address (for better or worse). Also, re-encrypting is generally much more expensive in LUKS use cases.

[AreYouLoco]

So in short: Password do not protect OTP keys just add complexity to access it.

And changing/rotating password should be named for what it does: adding password.

Definitely I would not expect such a mechanism to be honest.

With LUKS when you add new key/password you may/should delete the old one from the slots.

[alexbakker]

@GICodeWarrior

It seems reasonable to require the user to confirm each other vault password during vault password change. In practice, that would be zero or one additional password to type, right?

And potentially going through biometric authentication, if enabled.

This leads to another concern: Currently, a user only needs one of the credentials in order to be able to change their password. By rotating the master key, we'd require them to either provide them all, or to drop the ones they can't provide anymore. This would have to be explained to the user somehow.

Looking at how others tackle this, Bitwarden shows an "Also rotate my account's encryption key" checkbox when changing the password. Asking the user to make technical decisions like this is something I'd like to avoid.

It's tough to get this right from a UX perspective. I think the least confusing option I've come up with so far is something like a "Rekey" option in the encryption settings menu and a carefully worded prompt after the user changes their password, offering to "Rekey" with an explanation in which case they may want to do that.

[alexbakker]

@AreYouLoco

So in short: Password do not protect OTP keys just add complexity to access it.

That's not an accurate summary of what's being discussed here.

And changing/rotating password should be named for what it does: adding password.

No, because that's not what it does.

With LUKS when you add new key/password you may/should delete the old one from the slots.

Aegis already does this for you.

[GICodeWarrior]

I agree it will be difficult to communicate the tradeoff if rekey is optional.

From my perspective, supplying biometrics during a password change is near-trivial and doesn't need explanation.

For users who have no separate backup password, there is no other change (other than biometrics). I also expect this will be most users.

For users with a backup password, I think there are three main scenarios:

1. They have the password readily available (i.e. memorized or in a password store accessible on the phone). In this case, it is low friction to provide the password.
2. They have lost/forgotten the password. To support this case, some help text could be included asking the user to update the relevant password first if they no longer know it.
3. The password is inconvenient to access (i.e. stored offline in a separate location). The users in this case should (IMO) care the most about having the master key changed, and so it's appropriate to ask for that additional effort.

The most friction is in the least common and most important scenarios (has backup password, plus forgotten password or higher security expectations).