Limit number of devices per user

[TheJJ]

Synapse should have a limit of, say 100, devices per user. "Old" devices have to be removed first.

I've encountered a database where a bot account created over 20000 devices, because it apparently logs in again very often.

[ptman]

Hopefully a configurable limit. What should happen when limit is hit? Remove oldest device (or only if there are no keys associated with the device)? Or prevent logging in with new? If you cannot login you also cannot selectively log out the ones you want.

[TheJJ]

Of course configurable :)
Good question how to handle it. I'd say yes, the oldest one is logged out/accesskey revoked. Otherwise your account might be locked.

[clokep]

What would be your expected behavior when you run over that limit? An particular error during login? Maybe a 403 with a sane message. (The spec around this doesn't offer too many ideas for this.)

[TheJJ]

I think the new login should always succeed, but the oldest session is then logged out? That way you can never be locked out of your account, and old devices will be removed.

[richvdh]

What would be your expected behavior when you run over that limit? An particular error during login?

the problem with this approach is that users could lock themselves out of their accounts by creating lots of devices and forgetting the access tokens for them. Then they can't log in to clear them out.

I think the new login should always succeed, but the oldest session is then logged out? That way you can never be locked out of your account, and old devices will be removed.

this doesn't seem like a great idea. A user with a long-running Element (or other) client, as well as a bot that logs in regularly, would suddenly find their Element logged out.

Deleting the least-recently-used device might work ok. I'm a little wary of letting people rely on that, but I can't think of many better ideas right now.

[auscompgeek]

I would probably suggest deleting the LRU device without any device keys - those will be the most likely to be useless.

[notramo]

Sometimes app reinstalls cause new devices

• deleting app from mobile without logging out
• closing private browser window

In this case, the device info should be taken into consideration:

• one Element Android device
• one Element Desktop device
• several Element Web in Firefox

In this case, they are probably from private browsing mode, so even if the Element Desktop is the least recently active, the least recently active Firefox device should be deleted.

[aaronraimist]

I do not think the server should be trying to parse device names to figure out which one it should log out. The server should not be picking which devices to log out at all unless the user has ignored many warnings. Logging out random device and possibly destroying E2E keys should be avoided as much as possible. The user should choose which device should be logged out.

I think there should be two configurable limits. One to start encouraging the user to log out of devices. For example when the user logs in to the 101st device let’s say then the server allows the login to proceed but provides a some message/error to the client which prompts the client to show an interface to encourage the user to log out of some sessions. If the user doesn’t delete any devices and stays above the limit then the error should continue to be given during every additional login.

For the case of a broken bot that continually logs in there should also be a second hard limit that can be set by the server admin where after that number of logins then the least recently used session is automatically logged out. I imagine this being set to 2500 or 5000, a high enough number that an account is not likely to hit it unless they are really doing something wrong. Maybe the server could provide additional notice of this limit by 403ing every other login attempt when the account reaches 90% of the limit or something.

[babolivier]

Another alternative is something like #12855 that automatically logs out devices that haven't been active for a configured amount of time.

[richvdh]

It's maybe worth thinking about if OIDC (and also refresh tokens) will change the landscape here. For one thing, it will make it harder to write a hacky bash script which logs you in and forgets about the access token. (Any thoughts, @sandhose?)

I'm still not sure it solves the fundamental problem here, which is that it is impossible to distinguish between a shell script or incognito window which has long forgotten its access token (or refresh token), and a valid client which a user has chosen not to fire up for a few months.

[ptman]

One thing that could be done is to clean out devices that are older than x and haven't been used since the first y after being created

[richvdh]

Another suggestion here:

• Aggressively expire non-e2e devices (eg Delete stale non-e2e devices for users #14038)
• Limit the number of devices which can have keys uploaded for them to N; if someone tries to call POST /_matrix/client/v3/keys/upload on an N+1th device, reject it with an error code; the client is then expected to take the user to the device-management panel to delete something.