Extension: Counterintuitive backup/restore flows using "backup code"

[adon-at-work]

Backup flow

• Go to settings.html
• Click "Sign up with another email address" with email "a", get KeyA
• Click "Sign up with another email address" with email "b", get KeyB
• Click "Show backup code", save it somewhere
• Click "Trash" to delete all keys of "a" and "b"

Restore flow

• Go to settings.html
• Click "Restore from backup code"
• Put "a" in the email field, enter the backup code, and Click Restore
• Keyring panel shows multiple keys, KeyA and KeyB both associated with "a"

I'm aware that backup code is actually the encoded version of eccSeed and eccCount, which forms the basis to generate the private/public key pairs. And the same seed is being used across multiple "Sign-up".

Problems:

• How can one restore the respective key of "a" or "b"? Counterintuitive to explain "backup code" to users? One-to-one mapping of seed to every sign-up would be better.
• In case an attacker stole the backup code. The user reacts by clicking "Sign-up" to generate a new key. But by mutating eccCount, the attacker can get his new keys.

Proposed Solution:

• Let eccSeed be refreshed every time one clicks "Sign-up". Always eccCount = 0. Do not keep them in keyRing/localStorage.
• Show "backup code" only once after "Sign-up", with sufficient warning it's a one-time dialog.
• Hide "Show backup code" in settings.html

Thoughts? :)

c.c. @maditya

[sirdarckcat]

@rcchan wdyt?

[sirdarckcat]

cleaning up old bugs, please reopen if you would like to see this fixed

[rcchan]

Problem 1:
The original plan was to have emails restored based on key ids associated on the key server.

Problem 2:
If an attacker stole the backup code, the user should start over without restoring keys since any existing/restored keys are compromised. Starting over from scratch will generate a new ECC seed which produces new, independent keys.

[rcchan]

This may not be ideal if we're considering the user experience where a backup code is compromised but the keys themselves were not. In this scenario, the user would be forced to revoke the old keys even though those were not stolen.

Generating a new ECC seed each time and not keeping it in localStorage doesn't provide much benefit. At that point, you have a 1:1 correlation of seeds to keys. You may as well be backing up the secret part of the keys. Since the secrets still need to be stored, if localStorage is compromised, there is no point in protecting the one time use ECC seed used to generate the key.