changing password should not log out all your devices (and destroy your e2e history)

[ara4n]

which apparently it does as it logs out all your clients

[richvdh]

any suggestions for how to fix this welcome

[ara4n]

special-case logout caused by password reset not to destroy e2e keys? password reset should not be used to kick out lost/stolen devices - that should be explicitly done by the lost/stolen device API surely...

[richvdh]

Those sentences seem to be opposing suggestions?

special-case logout caused by password reset not to destroy e2e keys?

For one, that would require a way to tell the difference, and for two, I worry that keeping e2e keys around on logged-out clients would be surprising to the user and a leak waiting to happen.

password reset should not be used to kick out lost/stolen devices - that should be explicitly done by the lost/stolen device API surely...

Yes, one option would be to not invalidate access tokens on password reset, and instead get users to manage their access tokens via the device API: but that isn't really an e2e thing. (It doesn't seem to be specced, so I guess it's just a synapse thing).

[ara4n]

yup, they were two different suggestions.

let's just make password-reset not log out all your devices, and instead direct the user to use the devices UI to decide which devices to remove (warning them there that it will nuke the e2e history on those devices). And yes, it has nothing to do with with e2e.

In the short term, please can we just very loudly warn that it will destroy your e2e history.

[madduck]

I see two points here:

1. Resetting the password should not log out users, but probably inject a password prompt into the existing session to prompt for the new password on all devices, which then gets updated.
2. The e2e keys must not depend on the password itself, but on an underlying per-device secret key. On password change, this secret key gets decrypted with the old password and encrypted anew with the new password. e2e won't be affected.

[madduck]

Note that this also applies to changing the password!

[lhunath]

Does element-hq/element-meta#647 obsolete this?

[richvdh]

Not really. The fix to element-hq/element-meta#647 would require the user to validate the new devices. In this case it's better not to invalidate the existing devices, to avoid that step.

[Mikaela]

I think #2872 (log out other sessions) is related here or people might find this instead of it.

[CySlider]

Just happened to me.
Lost all my history and do not see a way to get it back :-( (Is there?)

Was still logged on with two PCs when wanting to install it on my new phone. Forgot the password.
So I set an e-mail (which I still could do without old password? Why not letting me change the password then in the first place directly without asking the old password?) changed my password. And boom - all devices logged out, all history lost.

Very bad experience.

[lhunath]

IMO, without a central place that stores history, it's critical that clients keep backups in such a way that they can be restored later on, once the account is accessible again. Which is certainly a challenge, because you wouldn't want those logs accessible by anyone else.

[MurzNN]

We can implement separate action "Logout on all devices" and add checkbox "Also do logout on all devices" to "Change password" dialog.

[hrj]

If I try to change my password now, the message prompts me to export E2E keys and then reimport them after re-login.

But I have my keys backed up on the server already. Is restoring from backup the same as export + import of E2E keys? In other words, as far as E2E keys are concerned, do I have to treat password change differently than a logout + login?

[z3ntu]

@hrj I've just tried - and the result is, that you have to manually restore the key from the settings but after that I can read my encrypted chats again. But it seems that the "verification of other peoples devices" have been lost.

[matthijskooijman]

I've just tried - and the result is, that you have to manually restore the key from the settings but after that I can read my encrypted chats again.

So you're saying that the recently introduced "Key backup" feature does not help to preserve keys on a password change? Any comment on what prevents this from working? The key backup has a separate password / "recovery key", so that could be unaffected by the password change. Or does a password change clear the server-side backups?

[jryans]

Key backup does preserve keys even across password change. If you are using server-side key backup, you can restore from backup after both log out / log in (which creates a new device) and also after password change.

If it's not working that way for you, please file a separate issue so we can investigate.

[jryans]

If I try to change my password now, the message prompts me to export E2E keys and then reimport them after re-login.

This part about the message prompting you to export is simply a bug and very confusing. #9432 is tracking fixing this.

[matthijskooijman]

Ok, great. I think my observations match your explanation (but I'm not actually using E2E right now, so can't completely confirm). Thanks for pointing at the other issue, since that is indeed the issue I was working towards :-)

[turt2live]

Soft logout is now a thing that exists in riot (develop) - we should consider at the spec level invoking a soft logout when the user changes their password (maybe with an explicit flag for "yes, actually delete everything")

[ara4n]

We now also have matrix-org/matrix-spec-proposals#2457 as an API explicitly for prompting whether to log out all other devices or not, which should be hooked up.

[schildbach]

What is the workaround for this? Can I edit the password via SQL on the Postgres database?

[kylrth]

Yeah none of my users want to change their passwords (including me) because we don't want to have the chance of losing chat history if we lose E2E keys or don't export/import them properly. Commenting to bump this issue

[tradaonline]

This issue really important for people to use, please keep searching for solution.

[BrenBarn]

This really needs to be resolved. Changing a password is a completely normal and everyday operation that should not be this disruptive.

It is an embarrassment to Matrix that this extremely basic operation is so cumbersome. I don't understand how this can still be unresolved after more than five years.

[hughns]

There is a proposed implementation of this for Element Web in matrix-org/matrix-react-sdk#8259