Aborting passphrase reset (at password confirmation) can lead to multiple backup pointers

[giomfo]

Steps to reproduce the issue

• Configure client well-known with { "io.element.e2ee": { "secure_backup_required": true, "secure_backup_setup_methods": ["passphrase"] } }
• Create an account and set up key backup
• Log out
• Log in again
• When asked for „Verify this device“, click „Reset all“
• Click „Proceed with reset“
• Click „Continue“
• Enter security passphrase + 2nd time for validation
• Copy the security key
• Click „Continue“
• You should now see the password prompt (this would be the case if the grace period server side is 0, or you wait for the end of the configured grace period)
• Dismiss with „X“
• Log out
• Log in again
• Verify the device with the passphrase

Expected behaviour:

• The old passphrase should work
• Only asked for the passphrase a single time

Actual behaviour:

• User has to enter old and new passphrase

---

It is possible to skip the last step of the passphrase reset. which is the confirmation via the login password.

It can be skipped via backgroundclick or clicking the x or just refreshing the page.

The problem with that behaviour is that in the step before (confirming the passphrase by typing it for the second time) there is already a new key backup created.

If you now skip the password input it leads to weird behaviour both in the active web client as well as the other sessions that are currently active.

When logging in again you will be prompted twice for the passphrase ( the old one and the new one ).

This can be only fixed by resetting the passphrase again and finish the process fully with the login password.

On Android I don’t see this behaviour and suspect that the process is done only after typing in the password.

The whole process should be either done after the password input or the password input should be left out of the process.

Operating system

No response

Browser information

No response

URL for webapp

No response

Application version

No response

Homeserver

No response

Will you send logs?

No

[giomfo]

We should be able to set the cross-signing keys (which is the part that requires entering your password) before you set the SSSS key and backup. So, it would go something like: 1) prompt for new passphrase, 2) create and set new cross-signing keys (which will prompt for account password), 3) set up new SSSS using passphrase from 1), 4) save private cross-signing keys to SSSS, 5) create new key backup, 6) save key backup key to SSSS

We will work on this proposed solution

[weeman1337]

There was a partial fix for this: It is no longer required to enter the password directly after login.

This issue is still valid if a „reset all“ is done from security settings at any later time.

[richvdh]

As @weeman1337 notes, the original STR no longer produce this problem. The following STR are still problematic:

• Open Security & Privacy settings
• Under "Cross-signing", click "Reset"
• Click "Clear cross-signing keys"
• Click "Reset all"
• Click "Reset"
• Choose "Enter a security phase", click "continue", enter a phrase, click "continue", confirm, click "continue"
  OR: Choose "Generate a Security Key", click "continue", copy the generated key
• Click "continue"
• Click "X", or the background, or refresh
• Attempt to log in again
• Click "Verify with Security Key or Phrase"
• Enter new key
• Click "continue"

Expected: new device is verified
Actual: back to the "Verify this device" screen.

The problem with that behaviour is that in the step before (confirming the passphrase by typing it for the second time) there is already a new key backup created.

I don't think that's correct. Rather, the problem is that a new cross-signing key has been created, and stored in 4S, but the public key has not been successfully published.

The logs contain:

 SetupEncryptionStore.usePassphrase: error Error: The public key of the imported private key doesn't match to the public key that was uploaded to the server
    node_modules 8269.js:10227
    __wbg_adapter_65 index.js:261
    real index.js:203

[richvdh]

It is, in fact, a duplicate of #13338