Forcing the user to interact with an email client during the signup process before they've confirmed the availability of a username might be good for security, but it's a horrible way to gain users. That's a very high friction process.
I generally agree with this comment, however.
Hmm, I do see your point, though I'd propose that usernames are more often than not public information. That's been my experience at least.
The difference for usernames is that they may or may not be shared across services. They're a bit more transient to the average user than an email is, though only a bit.
That said, it depends more on your use case than anything else. If any information is private information, it should remain private. Otherwise, I say make it easier to access that information, and be consistent.
To be fair to those implementing the example login systems as well, not all malicious attackers are hackers. It could be an angry ex who wouldn't necessarily think to try creating a new user before proceeding with their password-mashing attempts.
"Bad login combination" and variants do avoid information leakage. It's just not consistently enforced across all surface area. As another example, I believe Amazon public wishlists are searchable by email. That alone can net you an easy list of logins to brute force or check against existing email-password lists.
I think it's most likely that these services are avoiding the "that username exists but it's not actually yours" conundrum while keeping code (and UX) complexity to a minimum.
True, but many site use the email address as the username and require you to validate that email address before you can do anything anyway. Those sites, at least, have nothing to lose by adopting this approach.
Let them signup again. Then send them an email asking that they signed up for a second time and if they wish to update the existing information with the new information provided in the "fake" signup process.
This is why I like federated login with the options of Google and Facebook. Why go through the hassle of creating a new password and sending a verification email, when the user can just click a couple buttons to sign in with a service indefinitely? The username can be chosen afterwards and never has to be re-typed.
I know, but it's so much easier. It's not like I can't look up someones email account manually without federated login, plus then I no longer have to store passwords.
Of course, aside from my own projects, the only service I've seen that exclusively does this is Fancy Hands.
I agree that it's easier, and if you're only getting a unique identifier from that service (as well as a token), then it's really not unsafe. For the purposes of login, data sharing is unidirectional.
The problem is that Facebook totally mismanaged their apps when they first launched, and a lot of people were permanently turned off to "Connect to Facebook" functionality by random apps posting under the user's name.
My account was recently abused by Glassdoor, which fervently promised not to post anything to my friends, and then immediately did so.
My trouble with these things is that they invariably support multiple services, all of which I have accounts with, and I can never remember which one I'm using for any particular service.
