Question

I couldn’t come up with anything on Google, but this is a question I’ve had in my mind for a while, so I figured I’d present it here.

Let’s say you’re designing a typical username/password login. You set up a form where the user enters their username and password and then clicks a button to log in. Now, let’s say they typed the password wrong. Is it better to generically say the login failed, or is it acceptable to specifically inform the user that it was their password that was wrong?

My thinking is that telling them exactly what part of their credentials was wrong would make hacking attempts easier because a hacker could determine a username that is valid and then keep trying passwords for that username. If the error message is generic and doesn’t say whether it was the username or the password that was wrong, then it becomes more difficult for them. Of course, ideally the system would be designed to make brute-force hacking infeasible.

When I’m trying to log in somewhere and the login fails, I find it somewhat frustrating when I am given a generic error message. If I don’t remember what my username was exactly, and then on top of that I may have used a different password than normal, it makes it much more difficult for me to figure it out because I’m working with two variables and never know if I got one of the two right.

I’d appreciate any input on this. I’m leaning toward specific error messages for a system I’m designing because it’s more informative and convenient for the user, but I can be convinced otherwise.

Thanks!

Answer 1

FranklyI do not see why you shouldn’t tell the user what went wrong. Surly some will disagree with me, and if we potentially give an attacker valid usernames this will off course be used in SQL injection attacks and brute force attacks which might be a security risk. But I motivate my answer by these points.

1. First one is from your own question

   Of course, ideally the system would be designed to make brute-force hacking infeasible.

   This is really the key and if you have mechanisms in place such as only allowing a number of failed attempts for a username per hour, a limited failed attempts per IP-adress per hour, long passwords and so on, will drastically reduce an attackers chances to brute force a password even if they know a username. If they can only test 10 passwords per username, and 100 passwords in total each hour, it would take around 285 days to test each possible combination of a 6 character ASCII only password, and 1995 days with a 7 character one. I know that attackers can fake IP-adresses so this specific method isn’t watertight on it’s own but it is possibly to severely obstruct bruteforcing, which is my point.

2. The generic error message is bordering on Security by Obscurity. Chances are that an attacker already knows one or more username. I.e. they know a mail address and people often use the same username, they use timing (as pointed out by Jonathan Leffler) to determine if their usernames might be valid, some usernames are really common (admin and administrator for instance) and so on. If part of your security relies on the fact that the attacker shouldn’t know/guess usernames you will be unprepared when they do.

3. Stored procedures will mitigate the risks of SQL-injection attacks and by using basic security measures (not using urls like domain.com/delete/user/username/ to do things and be vigilant with authorization ) an attacker can’t really do much with the username other than try to bruteforce.

So basically I see the risk as really low and the benefits as quite high for the user. It also encourages you as a developer to not be lazy with security.