lemmy API enumeration issue

Attackers with a list of suspected credentials, e.g. obtained from another database compromise at a different service, should have a hard time when trying to perform credential stuffing attacks.

In this context, it is important to give as little information as possible why a given credential combination was not accepted. "Oracles" about whether the user/email or password were incorrect can be present via

directly via direct API calls
indirectly via timing and other side channels

The current API design is problematic. Note that I'm unable to test for a timing side channel due to Burp Suite limitations for websocket requests, so this was not attempted in practice.

Via Login

reply error {"error":"couldnt_find_that_username_or_email"} if user/email does not exist
in cases where the user exists, the request returns {"error":"password_incorrect"}
allows lookup if a given username or email address is used on the instance
- -> oracle for general user presence
consideration: most usernames are somewhat public due to public posts
however, email addresses are non-public
ideally, this API interface should return the same error case with the same timing characteristics regardless of whether the email address or password are incorrect