Skip to content
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 53 additions & 0 deletions proposals/2457-password-modification-invalidating-devices.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
# Invalidating devices during password modification

There are multiple use cases for why a user might want to modify their password:

* Adopting a password manager (to use a unique password or more secure password).
* Password rotation.
* Re-secure a compromised account.
* ... probably tons of others ...

These can be summarized into two groups:

1. "My account has been compromised and I need to re-secure it."
2. "I just want to change my password."

The [current Matrix specification](https://matrix.org/docs/spec/client_server/r0.6.0#post-matrix-client-r0-account-password)
does not provide a way to differentiate between these use cases. It gives no
guidance into what should happen to other sessions / devices when a password is
Comment thread
clokep marked this conversation as resolved.
Outdated
modified and leaves it up to the implementation.

It is reasonable for a client to want to specify this behavior to offer two
different workflows:

1. Modify a password and log all other devices out (for use when an account has
been compromised).
2. Modify a password and do not touch any session data (for use in a
non-malicious situations).

Alternately a client may default to whichever workflow is best for their users.

## Proposal

An optional field is added to the JSON body body of the [password reset endpoint](https://matrix.org/docs/spec/client_server/r0.6.0#post-matrix-client-r0-account-password)
Comment thread
clokep marked this conversation as resolved.
Outdated
called `logout_devices`. This is a boolean flag (defaulting to `true`) that
signals to whether other devices and sessions should be invalidated after
modifying the password.

## Potential issues

While Synapse defaults to the behavior of invalidating other devices and
sessions this may not be true of other implementations. Thus, a default of
Comment thread
clokep marked this conversation as resolved.
Outdated
`true` may not be backwards compatible. It might be more prudent to specify that
the behavior of not specifying the `logout_devices` flag is undefined.

## Alternatives

Provide a new endpoint in a future version that supports an additional field (as
above), using a new endpoint would avoid backwards compatibility issues.

## Security considerations

By defaulting to invalidating devices and sessions the security considerations
of this endpoint should remain intact. A client will need to be modified to
choose to keep other devices active.