11–20 of 188 posts
Leaving security aside, "incorrect username/password" is still the more correct and useful statement. Consider the case where you mistype your username (email). For sites like amazon, gmail, hotmail, yahoo, twitter, etc, it is entirely likely that the mistyped username is somebody else's valid username, you typed the password correctly, and "incorrect password" would hide the problem.
Even simpler than trying to sign up for a new account, many sites will tell you if you enter an unregistered email on their "forgot password" page.
I think websites say "Bad combination" not because usernames are treated equally with passwords, but because you don't have a choice but say that.
If I tell you that your username is incorrect, am I telling you your password isn't? This would be silly, because if the website is new and I know a password is correct, then I can either find the username out there (if the website is social), or pretend I forgot my username and have them give it to me.
Assuming that's not what I am saying, then the user is surely to have a bad experience anyway, since they will need to figure out a wrong username, and then in the worst case, a wrong password. When you say a "bad combination" you at least eliminate a possibility to mislead them into thinking only one of their credentials is wrong.
No it doesn't. It assumes, correctly, that that involves a bunch of extra work and that obfuscation raises the economic cost of an attack.
This doesn't address timing attacks, which are why this is done in the first place. If the code checks only for a username existing and returns the error message, this takes a measurably different amount of time compared to then also looking up if the password matches. The error shown isn't to dissuade people from using web pages to try to gain access to accounts - it's because the raw code itself doesn't know which…
I don't follow. Surely the reason to hide usernames is not to prevent a timing attack that would reveal... usernames.
This doesn't address timing attacks, which are why this is done in the first place. If the code checks only for a username existing and returns the error message, this takes a measurably different amount of time compared to then also looking up if the password matches. The error shown isn't to dissuade people from using web pages to try to gain access to accounts - it's because the raw code itself doesn't know which…
Timing attacks are solved by how you implement the backend checking code and not how you present the result to the end user in the most user friendly manner.
RFC 7231[0] suggests something similar
"An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found)."
with RFC 7235[1] suggesting the use of 403.
"A server that receives valid credentials that are not adequate to gain access ought to respond with the 403 (Forbidden) status code […]."
[0] https://tools.ietf.org/html/rfc7231#section-6.5.3 [1] https://tools.ietf.org/html/rfc7235
Indeed, the assumption that usernames should be secret is stupid and senseless. Passwords are meant to be secret. Emails and usernames are not. Heck, emails would be public, were it not for spam issues.
What this really highlights is a lack of consistency. If adding a security measure involves some kind of trade-off (UX in this case), you should really understand what you are trying to prevent and consider the rest of the attack surface. I think it would be a fallacy to immediately give up just because a larger vulnerability exists though.
I was curious to see whether there is a way round this and a quick search threw up https://security.stackexchange.com/questions/40694/disclose-... - the top answer is quite informative.