Use case: leaked backup file

[jeffgca]

NB: Feature requests will only be considered if they solve a pain

Summary

We need to account consider a design for the use case of a user's backup file being leaked but they still retain access to their original email account.

Problem

The user's backup key is somehow obtained by a third party. The third party cannot complete a restore process because they do not have access to the user's email account, but they can cause some mischief by triggering a lot of emails in our system.

There are two sub-scenarios for a leaked backup file:

1. if the user also still has the backup file, we can validate the user completely and initiate a key rotation process so that the attacker cannot attempt to gain access going forward.
2. if the user does not have a backup file, we can only provide the Account Reset option?

Questions:

1. if we rotate to a new key for the user, is there a path for the attacker to somehow gain access to the correct blobs stored in ipfs that could be decrypted with the user's leaked revovery code?

[matheus23]

if the user also still has the backup file, we can validate the user completely and initiate a key rotation process so that the attacker cannot attempt to gain access going forward.

A thing to note here: At the moment it's possible to secure a backup any time you're logged in. So even if they lost access to their backup file, but have access to their account & email, they'll be able to create one again.