[eddiemunster666]

I humbly disagree, if you say to the user that the username was correct but the password was wrong then you have leaked information to the user that they should not have access to. i.e. If email is used as a username and I go to a porn site and type in my wifes email address and a random email and it comes back 'username right, password wrong' then I now know she has an account there which she was trying to kepp secret.

It's not only bad from that point of view, but also the attacker now knows you have a account there and so could try social engineering techniques to gain access to your account, it basically provides a attack opportunity that it doesn't have to.

[mistercow]

I think you're missing the point, which is that that information is already unavoidably leaked by the signup form. So leaking it from the log in form doesn't change anything.

[HeyImAlex]

Yep, the only way to really leak no information is to just always say that the action (sign up, forgot password) was sucessful, which is awful from a ux perspective. Don't forget to go through the motions of registration/recovery to stave off timing attacks as well.

[mistercow]

I have actually worked on systems where the signup form allowed multiple users to have the same user name, and the log in process consisted of checking for the existence of a (username,password) pair. Needless to say, I regarded this as a major design flaw and fixed it (except for the existing non-unique users). But there is, for all the reasons it shouldn't be done, a situation where the signup form doesn't leak usernames.

[aiiane]

That's a very binary way of looking at it. Depending on the sign up flow, it may be much more difficult to discover the existence of a username or not, than it is in the login form. (For instance, if the signup flow involves payment details before the username step.)

[mistercow]

Are you going to enforce uniqueness of payment details? And if so, what part of those details must be unique? Will you require a unique credit card number?

If so, you will have to maintain either a bloom filter or a list of hashes for all eternity to ensure that nobody signs up twice with the same CC number. [Edit: actually, you could keep the scrambled CC data for a finite length of time if you're just trying to rate-limit, but still see below]

So suppose you've done all that. Are you going to do a test charge to see if the credit card number is valid before allowing the user to choose a username? If you don't, your efforts are wasted, since anyone can just use a CC generator (they're used for testing) to sign up for new accounts all day. If you do, you've probably driven away 99% of your users with your ridiculous signup process.

[jfarmer]

If you're using a third-party payment provider like Authorize.net or Braintree to store CC numbers, you'll be given a unique token from the provider when you add the CC number. When you add the CC you can also have the provider run and immediately void a dummy transaction to verify the card is real, too.

[aiiane]

I was actually thinking of cases like MMO game accounts - often times the actual game account isn't created until after the game is purchased.

[dllthomas]

Leaking emails is bad. Leaking site-specific user-names seems like less of an issue, particularly when they're exposed anyway through simple use of the site.