4 ms·

They are correct, it is important to show a generic message on the login. The login is the first place an attacker will look for user enumeration. Just because

They are correct, it is important to show a generic message on the login. The login is the first place an attacker will look for user enumeration. Just because you may be able to find user enumeration somewhere else doesn't mean you should leave it open everywhere. For user enumeration on registration you have two choices: 1. Provide a unique registration link to an email for signup. The prospective user goes to the registration page, submits and email, checks their email, then follows the link to a registration page. On this page it's easy to see if someone is enumerating usernames, and every request contains the token from their unique signup link so the token can be invalidated quickly. 2. Provide a slow rate limited lookup to verify an existing username, every 2-3 seconds, which shouldn't negatively affect users as they signup because they have to fill out a registration form in the mean time. This will however greatly slow down a bot.

kefka 12y ago
That still goes back to user interface implementation. You can have a website that tells you "Bad password", and the user knows what it is. They fix it, on they go. If there's a bad actor, it says "bad password". Same warning. Now, you slow down the response so that after 5-10 times, the website gets dog-slow. It's still useful if you're a legitimate user. And if someone is script-attacking you, they're going to get an enumeration of your usernames by using a different script. Or they'll dump the username:passwd database if they get in. In that case, obfuscating usernames is moot anyways. It's security through obscurity, and it's not that obscure. And it's bad UI.
- amckenna 12y ago
  It's defense in depth. Why tell a probable attacker that they have the correct username if you can hide it from them. The less you give them the better. Most users will know if they got their username incorrect, it's right there in front of them on the screen. The slowed down responses (exponential back-off) is a the preferred method of rate limiting over account lockout. "Or they'll dump the username:passwd database if they get in. In that case, obfuscating usernames is moot anyways." Well if they can dump your DB it's game over for your whole app and possibly infrastructure anyways.
dasil003 12y ago
> 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.
- amckenna 12y ago
  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.
  - nothrabannosir 12y ago
    To be honest: every now and then. 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.

kefka 12y ago

That still goes back to user interface implementation. You can have a website that tells you "Bad password", and the user knows what it is. They fix it, on they go. If there's a bad actor, it says "bad password". Same warning. Now, you slow down the response so that after 5-10 times, the website gets dog-slow. It's still useful if you're a legitimate user. And if someone is script-attacking you, they're going to get an enumeration of your usernames by using a different script. Or they'll dump the username:passwd database if they get in. In that case, obfuscating usernames is moot anyways. It's security through obscurity, and it's not that obscure. And it's bad UI.

amckenna 12y ago
It's defense in depth. Why tell a probable attacker that they have the correct username if you can hide it from them. The less you give them the better. Most users will know if they got their username incorrect, it's right there in front of them on the screen. The slowed down responses (exponential back-off) is a the preferred method of rate limiting over account lockout. "Or they'll dump the username:passwd database if they get in. In that case, obfuscating usernames is moot anyways." Well if they can dump your DB it's game over for your whole app and possibly infrastructure anyways.

dasil003 12y ago

> 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.

amckenna 12y ago
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.
- nothrabannosir 12y ago
  To be honest: every now and then. 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.