Account creation and password reset forms leak user existence

Problem/Motivation

The password reset and account creation forms currently leak information about users in a system. If you use the password reset form, you get a different message on success and failure, so you can infer that a user using that username or email address exists depending on the response the form gives you. The same information is discoverable using the account creation form, which won't let you create an account using a username or email address of an existing user.

Proposed resolution

The password reset form should give the same response regardless of whether a user exists; something like "If a user matching that username or email address was found in the system, then password reset information is on its way." If the user exists; send the email; otherwise, no-op (maybe even with a random sleep so that black hats can't deduce the result by timing how long it takes the server to respond?).

We show a similarly ambiguous message when someone goes to create a new account. If the username and/or email address already exists, then we send the existing user(s) an email reminding them they already have an account on the system. Otherwise, we send the new account validation email to the new address.

(There's some problems with this. What do we do if email validation for new accounts is disabled? Also, if someone is trying to register an account with a pre-existing name but a different email address, they may get frustrated that seemingly nothing happens for them when they try to create a new account. Maybe we send them an email saying that the username is already in use… This still leaks the information, but at least it'll cause more work for black hats - we don't give them a solely RESTful interface to the username and email columns of {users} as we are now.)

Remaining tasks

Discussion and implementation. Possible backport to D7 contrib space.

User interface changes

New, more ambiguous messages when these forms are submitted.

API changes

Possibly none.