Why not emphasise user privacy more by hiding emails. eg "An email should be sent to the address above. For user privacy, we cannot confirm if it exists."

I wonder how many emails scrapers have done of Forgotten Email pages.

This could work, but there's still vulnerabilities. How about a timing attack? The page with that message probably responds faster if the email address doesn't exist. (Sure, a timing attack can be fixed if you can make the page run in constant time; but is it really cost-effective to spend time developing that rather than actual features?)

1) Validate email address. 5-10ms

2) Send a non-blocking request with a flag, eg "Good" "Bad".

3) Return message to user that email has been sent but can not confirm if the email is true for privacy reasons.

While yes, it can be down to a timing attack, the trouble is that this vector can be used against sessions, logins, etc. It can be a standard that Mozilla should adopt.

This is a tricky issue, for the exact reasons you mention: already taken usernames will cause an inadvertent verification of its existence, as can password reminders that use e-mail addresses as input. The latter can be handled by giving an ambiguous response, which comes with a slight (but negligible) cost of annoyance for forgetful users. The only method that comes to mind for avoiding username mining is forcing the user to pick from a fixed number of available usernames based on f.e. a part of the supplied e-mail address. This is a bit of "userland villainry", though.

sorry, but that's stupid.

a correct site - and I have corrected dozen of them, and they work just fine does not give a specific error msg for password reminders either, or any other function.

so the generic message should be returned from every such function, and i'm pretty sure they talk about password recovery as well. (and again ANY such function should return a generic message)

mind you, its much easier to compromise a site when you can check the username and just have to crack the password. you can automate it easily as well.

ps: oh, look,next paragraph after what you pasted: "The following message should be returned to the user regardless if the username or email address is valid:" for recovery. Pretty sure you've seen it and voluntarily ignored it :-( mean mean mean.

How would you deal with a registration form that takes a username as a parameter, without leaking whether or not a username is already taken?

I would probably have a CAPTCHA on the form already, to prevent automated signups. Preventing username leakage is a side benefit. An attacker would need to hire a CAPTCHA farm to harvest any significant number of usernames.

If you don't want to use a CAPTCHA for regular signups, you can add one to the page dynamically when you see multiple registrations from the same IP address.

Does this mean that you wait until the user submits the whole login form to display an error message if the username is already taken? Do you display a new captcha for each attempt?

What about sites that let the user know his username is already taken using AJAX? Should this be avoided too?

I like zobzu's idea of using an email as login, though.

In the response, thank the user for initiating registration and send her an email with a link (and a token) to continue with the process.

Of course, the downside is that you're slowing the user down. It's acceptable for the sites that choose to require valid email addresses: if you're going to go there you might as well get it done sooner.

You'd also be spamming potential victims, but that may not be that bad, as you'd also be alerting them.

You could set a cookie after a successful login. If a later attempt fails because of a munged username or password, you could inform the user exactly what the problem was if you know they have logged in successfully before and the username is correct or "close" to the real username (not sure how close is "close enough").

EDIT: oops meant this to be a reply to the GP.

But then people would complain that you were tracking them after they've logged out of the website...

email as login plus emailing him for verification captcha against automation for the spam

and if thats too annoying to implement use browserid.org