Ensure Data Privacy With Single Message For Wrong Credentials

User experience (UX) of today’s applications is one of the most important goals of software development. When we first decide to make a software, we are always driven by the problem we want to solve. The best software in the world is useless if it doesn’t solve anybody’s problems. On the other hand, solving a problem by going through a myriad of steps is as equally painful as having a useless software. Therefore, there is no wonder why software craftsman try to provide as seamless experience for users as possible. Today, I would like to discuss alternative thinking to a widespread UX practice considered to be good. Just to clarify, this blog post is about software security best practice on login page.

A superficial side of the problem

Let’s consider having a regular login page with just two fields. Username which accepts email address and password which should be created during registration of the user.

Imagine now that the user types in wrong username or wrong password. When we design pages similar to these we want to make it easier for the user to understand what they did wrong. It would be a common interest of users and development team to have an intuitive message displaying what went wrong. Then the user can make appropriate changes and hopefully login successfully. Having separate messages for wrong user and password like the one below are considered a good UX practice.

The case against separated messages

Have you ever worked in a company which had strict privacy and data policies? One of those where you periodically have to listen to a course and then take a test about privacy policy? If you haven’t then let me tell you just one thing that you should remember about it. No person should get in the possession of information he/she is not allowed to have. This includes but it is not limited to names, emails, addresses, physical addresses or any other information which can harm the company, its partners or clients. What does that have to do with simple login page?

When we have separate messages for different fields a capable person can easily get in possession of information about a user in the database. Imagine that our login page is a page used by all employees of a company. They need to enter their business email address and personal password to access some portal. As a person outside of the company, I can find some employees in business social networks working for this company. I can then try a few combinations of email patterns like first name dot last name or first letter of first name and last name, etc. I would type in all those email combinations in the username field until I get a different message. Now I know that [email protected] user exists in the database.

I found out the email pattern used by this organization and I have a list of people working there with their titles from social networks. Finally, I have something to sell to the highest bidder. However, when this message just says that either username or password is wrong I cannot be sure what is the correct email pattern to exploit it.

Not so much the best login page security practice

Of course, by now many of you thought that having separate messages is quite helpful for hackers. You would be right. This is the anti-pattern of login page security best practice. Hackers as well can exploit this in a way that once they get their hands on valid email address, all they have to do is to guess the password. Some of you might say that is not so easy. The fact is, today there are a lot of ways to get someone’s password. And let’s face it, most commonly the passwords are nowhere near as strong as they should be. Hackers use social engineering or specialized tools for guessing your passwords.

Alternatively, a lot of applications and portals with login pages have DDoS protection. It locks the user if subsequent number of failed login attempts has been exhausted. This opens a window for new type of DDoS attack. Simply enter wrong credentials for valid users as many times as possible and have their accounts locked out so they cannot use the software. In that sense, our obligation as software engineers is to secure our own data and the data of our customers.

Conclusion

Most security issues are human errors created inadvertently or with the best intention. Social Engineering is a whole new approach used by hackers counting on people being people. Besides us being suspicious about everything we have to secure the access to the application and think like a hacker. Our best chance is to think about all the small things where we can accidentally provide access to a person with malicious intent and prevent it. One of such places is the login page. Our defense must start from the very beginning by implementing security best practice on login page. From now on, when you see a page with separate messages use the arguments to drive a change that will lead your organization and customers to the safe side.