Hacker News Reader

Comment by arank | Hacker News Reader

i think its done to prevent brute force attacks on passwords. If someone knows that username was correct and password wasn't, he knows something! That's why the message 'username or password does not match' and that's why both the fields needs to be empty when page loads with error.

View on HN

Depends on whether the login username is public or not.

If you're on a community based site where others can see your username, there's no reason to hide it. Anybody trying to brute force your password is probably specifically targeting your account.

On the other hand, if you're on a service where other people cannot see your username, it would indeed be better to return a 'username or password does not match' error.

Makes sense.

I don't think the idea is to indicate whether or not the username is correct. No matter what the user enters for the username, when you spit back "username or password incorrect," fill the username with what they typed. A brute force attacker gets no more information than he would with an empty username field because what comes out is identically what he put in, but a real user who mistyped his password knows this immediately by checking the username field and verifying it's correct.

You're correct about the message, but actually you don't fill out the password field because you should never return the password to the client. It is OK to return the username to the client, and does not imply that the username was correct as long as the messaging is as you said.

why would you want to show something to user that's wrong or does not exist? Most usernames are anyways smaller and its not painful to enter it again. If you want to serve people with very long usernames by filling in the username field, you are focusing on a very small fraction of users.

Because it's easier to correct something that's almost correct than to start over, and because it would help you determine if the username or the password was at fault.

And how do you know if someone was playing around with usernames or genuinely trying to login? I agree with 'dvdhsu' comment that if its a public service where others can see username its fine to load error form with username but if its a service where other users couldn't see your username its not a good idea to load error form with username irrespective of whether it was right or wrong.

Why does it matter? You assume the best and help the good guy, and in the worst case you don't help the bad guy.

You shouldn't be thinking about security in your validation anyway.

We should always be thinking about security, particularly when validating security credentials. (But remember that security is a trade-off.)

But I don't see the security cost in populating the username box with what the user previously typed there. We're just echoing back what the user typed. The only extra information we've provided is that the potential attacker can't login with that username+password --- we don't say whether this is because the username is invalid or because the password is incorrect for that username.

Is it, though? I find it far easier and faster to click on field, type username vs. look at field, see username is incorrect, click on the field, highlight/backspace to select, re-type part of the username.

If I've gotten my username wrong, it's usually because I made a typo, in which case, re-typing it will solve the issue, or because I simply don't remember it, in which case, seeing what I typed previously isn't really going to help with that.

Reply on news.ycombinator.com