> Just because you may be able to find user enumeration somewhere else doesn't mean you should leave it open everywhere.
Why not? Rather than parroting conventional wisdom, how about making a cost/benefit case?
We're pitting a significant UX benefit against a tiny marginal security benefit.
Unless you're demanding a higher level security across the entire service, in which case you don't want user enumeration anywhere, then the correct answer to implement throttling on anything that would make the usernames discoverable. That's more flexible solution that does not conflict with good UX.
I don't think it is a significant UX benefit to reveal to a user that their username is correct but their password is incorrect. How many times has an incorrect username been what's blocking you from logging into an application? Just look at the username you entered right there in front of you. Is it correct? No? Then enter the correct one. The hangup during login most of the time is people fat fingering or forgetting their password. Telling them that their password is incorrect isn't going to help, they will assume that and re-type their password again anyways.
I agree, implement throttling anywhere you have authentication or registration, that's a good idea to have in place in any case. I'm not arguing that.
It seems there is always the problem of balancing security, performance, and usability. You just have to decide which is more important when examining features. I this case I would advocate security. The decision you make with your applications is up to you, but it's important to understand you are making a tradeoff.
All the fucking time. Everything I signed up for when I used gmail uses my gmail address; everything after a different address. Guessing one then the other then the first again is like plugging in a USB adapter in the dark.
Old (forum, ...) accounts, >5 years of inactivity. What e-mail did I use for this again? I end up just typing every e-mail address I can remember in the reset password field because it's faster than the combinatorially exhaustive search with the three / four probable passwords from way back when.
EDIT: My main objection is that taking computer literate people as the litmus users is a UX anti-pattern. We talk a lot, but we easily forget just how much hand-holding, clarity and patience a large (and silent) chunk of our users need.
Why not? Rather than parroting conventional wisdom, how about making a cost/benefit case?
We're pitting a significant UX benefit against a tiny marginal security benefit.
Unless you're demanding a higher level security across the entire service, in which case you don't want user enumeration anywhere, then the correct answer to implement throttling on anything that would make the usernames discoverable. That's more flexible solution that does not conflict with good UX.