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

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.