Week 3: User Feedback Messages

One of the things we, as developers, try to do is create applications that are intuitive to our users. After all, what good is it to make a wonderfully functional application if the end user has to have a Ph.D. in order to understand how to use it? Some companies write vast amounts of documentation and training manuals as a way to provide an understanding of the application’s functionality. However, when a user is expected to enter a particular type of data into an input field, we aren’t going to waste our time or our user’s time writing documentation on input types. So what we do is provide instant feedback to the user in the form of messages.   We may provide feedback when an error has occurred or when we want to confirm a user’s input or selection.

Providing feedback messages is an excellent way to interact with the user and it provides the user with a much better experience when he knows what is or isn’t expected. There’s nothing worse, from a user’s perspective, than an application which errors unexpectedly and doesn’t provide any feedback as to what may have caused it. Providing feedback messages to the user is an essential method for ensuring a positive user experience. However, as developers, we need to be aware of the types of messages we present to the user. There are occasions when we need to provide detailed feedback to the user, such as when a user enters invalid data into an input field. For example, if the user mistakenly enters numeric values into a name field we may provide detailed error message stating the only allowed characters are a-z.

On the other hand, there are times when we need to provide as generic an error message as possible, such as when a user’s login attempt has failed or when a user has accidentally locked out his account or has forgotten his password and uses the application’s functionality to reset it. These are three separate examples of when we would want to provide generic error messages, because if we provided detailed error messages a malicious user might use them to attack the application.

Failed login attempts are common. The more complex the user’s username or password, the more likely the user is to forget it or make errors, and attempt to login with invalid credentials. As developers, we need to inform our users when their login attempts have failed, but we need to ensure we do it in a safe and secure manner. Below are examples of bad feedback messages to a user whose login attempt has failed.

Figure 1                                                                                          Figure 2

Both examples above are bad; why, because they reveal too much information to the user. While these two feedback messages reveal to the user which part of the login credentials are incorrect, they also reveal which part of the credentials may be valid. In either case a malicious user has potentially already harvested a valid password (Figure 1) or a valid username (Figure 2). This would allow an attacker to attempt a brute force attack against the system in an attempt to discover the second part of the login credentials. This attempted discovery of valid accounts is called account harvesting. Error messages such as those used above can aid a malicious user in discovering and harvesting valid account credentials. It is much safer, for both the application as well as the user, to provide a generic “login failed” error message (see Figure 3 below), as this mitigates the risk of exposing which portion of the login credentials is incorrect.

Figure 3

This same example holds true when a user has forgotten his password. If the user supplies an invalid username to request a forgotten password, and the feedback message states “Invalid Username” or “Unknown Account”, but reveals another message if the username supplied is valid, such as “New password has been emailed”, or the user is taken to another page or step in the process, these messages can also reveal to a malicious user that they have discovered some valid credentials.

Okay, so now we know what account harvesting is and how our feedback messages to our users can be used against us. As a developer we would need to take steps to implement generic feedback messages. Plus, we would want to take steps to prevent a malicious attacker from running a brute force attack against our login or forgotten password process in an attempt to discover valid account credentials. How would we do this? The first step would be to limit the number of invalid login attempts by a user. Ideally, we would want to limit this number to five or six invalid attempts. After the limit has been reached we would then lock the account and prevent even legitimate login attempts, using valid credentials, from occurring.

However, now that we’ve locked the user’s account how do we inform him of this? Would the feedback message provided below be a good idea or a bad one?

Figure 4

If you said the feedback message in Figure 4 was bad, give yourself a pat on the back, because it is a very bad idea to reveal to the user that his account has been locked. One thing to remember, we can never assume that the person attempting to use the application can be trusted. If a malicious user attempted to log into the application using the “asmith” username and received this message, he would know two things. One, that “asmith” is a valid account and two, they have just locked the real account holder user out of the application, thus preventing a login even with valid credentials.   The worst case scenario in a situation like this can result in a complete DoS (Denial of Service) attack against all users attempting to access the application. DoS attacks aren’t just about massive requests to a server and consuming the bandwidth, DoS attacks can also be done at the application level as described above. If a malicious user successfully locks out a user’s account, they have denied the service of the application to that user.

Providing detailed feedback messages can cause major security issues with our applications. We never want to provide intimate details of an issue to the end user, because we can never ensure that the user is a valid account holder. It may place a greater inconvenience on your user base, but in the end the application is much more secure and your customers’ accounts are less likely to be compromised by a malicious attacker. Ideally, we would provide the same feedback message to the user regardless if it were an invalid login or if the account has been locked. The difference between feedback messages is the difference between protecting your customers’ accounts and having them compromised.