e2e keys are not removed when accounts are deactivated

[n3rdybyn47ur3]

I know that deleting users isn't possible at the moment, so we use the disable API to "delete" them. We have a very high staff fluctuation and our user name policy allows that usernames of retired staff members can be reused. Lets say "Bob Smith" retires and his Active Directory name smithb is removed (and disabled in Matrix, because deletion is impossible). Some weeks later "Bill Smith" joins the company and gets the Active Directory username smithb because its no longer present in the directory. During his first element login he authenticates with his Active Directory credentials (ma1sd) and gets asked to provide his security key (the one of the retired staff member I assume) instead of creating a new one because the old user object is still in the matrix database.

I see three possible solutions to this problem and would kindly ask to implement one of them in the future:

1. Make it possible to completely delete Users
2. Please add the security key to the list of deleted profile values (room memberships, 3pids,...)
3. Change the matrix UID to something ramdom when disabeling a user

Another solution would be to use randomly created UIDs when the authentication happens via 3pid (ma1sd, saml,..). Our staff members will never use or need to remember their actual Matrix Name because of the conected identity provider.

With kind regards

[ptman]

https://github.com/matrix-org/synapse/blob/master/docs/admin_api/user_admin_api.rst#deactivate-account it is in some cases possible to erase the user.

[erikjohnston]

It's worth noting here that there is a fairly large assumption in matrix that a user ID won't get re-used. Even if the user account is completely wiped from the database they may still retain permissions in federated rooms, for example. I'd strongly encourage people to not re-use accounts wherever possible.

However, correctly deleting associated encryption data and meta-data is probably something that we should be doing anyway. I think that involves deleting things from e2e_* database tables.

https://github.com/matrix-org/synapse/blob/master/docs/admin_api/user_admin_api.rst#deactivate-account it is in some cases possible to erase the user.

That is more for GDPR erasure, which causes new users to not be able to see the deleted user's messages. It doesn't really effect much in this case

[reivilibre]

(Without much knowledge of every level of SSO in Synapse), I'd suggest this might be something that needs configuring or implementing in ma1sd.

Your LDAP/AD server may already have a unique ID, separate from the user name, stored for every user. (If not, it may be possible to add one?)

Could you then configure ma1sd to base the matrix user ID off of that unique ID rather than the login name?
(NB if it's numeric, you may need to prefix it with a letter, I believe.)

Hopefully this might point you in the right direction?

As Erik mentioned, re-using matrix IDs is ill-advised, and changing them to a random one after-the-fact probably won't fly because events in rooms may still refer to them (and are signed so can't be modified, especially not if you're federating!).

[n3rdybyn47ur3]

Thanks for the input. I think we have to create a new unique ID because all our IDs are numbers.

[reivilibre]

Thanks for the input. I think we have to create a new unique ID because all our IDs are numbers.

There may be a way to tell ma1sd (or is this a Synapse config option?) to prepend the ID with 'u' or a character of your choice (I vaguely remember people talking about templates for SSO usernames in Synapse… look for something to do with usernames and username_template: "{{ this_kind_of_stuff }}" which could be replaced with username_template: "u{{ this_kind_of_stuff }}" for example (I don't know what the field would be called).

[richvdh]

folks please can we use this issue to track the outstanding issue that security-sensitive data is not deleted when a user is deactivated, and take the discussion of how to set up LDAP integration correctly elsewhere?

Here is the outstanding work:

However, correctly deleting associated encryption data and meta-data is probably something that we should be doing anyway. I think that involves deleting things from e2e_* database tables.

[clokep]

According to #8932 these are deleted. Checking the code this seems true:

• DeactivateAccountHandler.deactivate_account calls DeviceHandler.delete_all_devices_for_user
• ...which fetches all devices and then calls DeviceHandler.delete_devices
• ...which deletes each device, then deletes access tokens for that device, then deletes E2E keys for that device

So maybe some other piece of data isn't deleted? (The key backup perhaps?)

[erikjohnston]

I think #8932 fixes this issue