Avoiding information leakage, whether in terms of error cases (e.g. incorrect padding on crypto showing a different error, leading to a padding oracle attack) or in terms of user-facing content (e.g. exposing whether or not a username or email exists in the system) can be difficult. That said, you should always err on the side of showing a single message rather than multiple -- in this case, always show success. This is common practice in certain things, like always showing "incorrect username or password" rather than "incorrect username" and "incorrect password" messages, but most people don't consider it for other things.

The less data you give to users about state that isn't necessarily theirs, the better.

Ew no, don't always show success, there surely has to be a more elegant solution. I have multiple email addresses and sometimes I'll use a different one for a different service, if I enter email@website.com when I used email@anotherwebsite.com and you show success when it's the wrong one, I'll be waiting for an email that will never appear...

Maybe HN can work out a good solution collectively? I can only think of a secondary authentication piece, but then that's also possible to be forgotten.

How about show success, but adjust the confirmation e-mail accordingly. For example, if the e-mail address is not registered you could say something like "We received a request to recover your password on our service but see that you are not registered for our service with this e-mail address." ?

I considered this, but it makes an easy way for someone to cause the site problems. I guess coupled with captcha it could work, but someone could send a lot of emails to different people, if enough mark it as spam they might have problems as it is TECHNICALLY unsolicited, but I guess at the same time I could do the same with registering...

That's good; that'll mean fishing expeditions like this will warn the, er, fish.

A possible solution is to get the email account holder to send an email to lostpassword@website.com. Auto-reply with a password reset form, or a welcome email in the case with no existing account (maybe you could fast-track account creation here, with a link "Oops, please delete this account. I didn't mean to do that.").

It doesn't really solve the problem of figuring out which email address you used to create your account, but it allows you to provide feedback to the user that the account does/does not exist.

An alternative solution would be to just email whatever account you enter on the website, with the appropriate wording depending whether or not they have an existing account, but this approach seems like it'd be too easy to spam random people.

I think the solution is pretty simple... just be transparent and say for security reasons you can't reveal whether or not the user exists.

Yes, just saying this should be sufficient - "If your email address is our database, you would shortly receive an email to reset your password".

Using Facebook/Twitter/OpenID accounts for login would probably remove this issue completely.

Though, I'm not sure if you can get e-mail from these, and making the users enter their e-mail after login would degrade the user experience.

After an unsuccessful attempt to login, say "Sorry, that login information didn't work."

If someone wants to reset their password, after they enter their email address say "Thanks. If that email address is in our database we will send a reset link."