4 ms·

Quoted: "In step 4, never tell the user if it was the username or password they got wrong. Always display a generic message like "Invalid username or password.

• rurounijones 12y ago
  But if you try to create an account with the username, it tells you "CANNOT CREATE, USER ALREADY EXISTS". Then don't do it, give a generic error message and send an email to the accounts email address saying "Did you try to sign-up, you already have an account, here is the reset link in case you forgot the password"
  • dag11 12y ago
    Sending an email to the registered account is not a solution, because that doesn't tell the registering user that the username is unavailable.
    • kefka 12y ago
      If a username isn't obtainable, it would be fair to assume the username is in use. I know of no situations that seed "unobtainable usernames" in a DB. Although now, I would expect that.
• amckenna 12y ago
  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.
• zackify 12y ago
  I was just about to post this.
• matthewmacleod 12y ago
  No, it's not wrong – you're conflating this with another issue. User enumeration attacks are real and bad. A better solution to that would be to not leak this information when trying to create an account, instead. Since most sign-up processes seem to require email confirmation anyway, nothing is really lost there. Of course, if you don't require email confirmation, then go right ahead – you'll have to use other approaches to avoid enumeration (like rate limits), but then you should be doing that anyway.
• Sami_Lehtinen 12y ago
  First mistake is to let user to select arbitrary username os password. Just provide them with secure ones, that's what I do. I always have wondered also the fact, what's the point of having separate username and passworld fields in the first place. Username: bjdndgEC2S4rHRZy7c8rdQ Password: 6TWe8EvxfRxxCvcyZTaBM6 Isn't it enough to concatenate username and password, it's just as secure to use one field instead of two. Btw. Do many of these services pay enough attention to potential weaknesses presented by the potentially weak(er) session cookies?
  • tedunangst 12y ago
    Link to one of these services? I'd love to see this in action for myself.