As developers, we have as focus to think about applications that are more and more secure, more and more efficient in keeping user data safe. After all, in these times of LGPD and GDPR, we have an obligation to think about security right from the start.
The concern about application security in the early stages of development brings us a huge set of gains. As a complementary reading on this topic, I even suggest reading our article on security by design. But how does this relate to security questions, which is the subject of our article today? We’ll get there.
Predictable security questions
In the vast majority of web applications, we always find in the password recovery process a step where we have to answer a question. Theoretically, this question should uniquely identify us.
However, these questions are usually standardized and often used from an already known list on the internet, which is even worse. After all, the vast majority of questions try to validate the user’s identity by seeking the answer to questions that in theory only the user should know, such as, “what is your mother’s maiden name?” Really, guys? We still have others, such as “What are the last x numbers of your CPF?” or “What’s the name of your first / last school?”
Thus, the most attentive people have already realized that this type of question has no or very little effectiveness in a world where we insist on provide all this information on our social networks, making the “work” of the attacker reduced to knowing how to perform a good search on Google. Using dorks, for example!
Researchers at Carnegie Mellon University and Microsoft together conducted a study on the topic and were able to show that a person without prior knowledge of someone else would be able to come up with the correct answers in approximately 15% of the questions. This without taking into account the ease of searching for this information on the Internet and on social networks. The study is a little old, I know, but this reality is not much different today.
Therefore, this should already make us stop for 5 minutes to think about what we are really doing in our web applications. This problem is not new, it has been observed for a long time, as we can see in this article on the Google security blog.
Usability versus security
As commented in the article, if the question is simple to be remembered by the user, it will also be simple to be found by the attacker. However, if the question is difficult and complex, the user will most likely forget the correct answer. Once again, we have to think about effectiveness and even the balance between usability and security.
The problem of usability versus security is an old one, and is reflected very well in our topic. As developers, the necessity is to make the application easy to use, but at the same time safe for the user and their data. However, there is a conflict of interest between users and system developers.
For users, the main priority is ease of use, while for the developer, among other things, it is the maintenance of data in a safe way. But, as Bruce Schneier says, “software is poorly written because, with few exceptions, the market does not reward good quality software.” And that goes for “security” questions.
How to improve the password recovery process?
Regarding security questions, few users will give importance to a well developed, well thought out password recovery system. This, however, also has a lot to do with the development process itself, which ends up leaving security for a much later concern, and does not see such mechanisms as important.
So, if you care about how your password recovery process is going to be built, and still want to use questions in your process, we strongly suggest reading and studying the Choosing and Using Security Questions Cheat Sheet. It is a material created by OWASP and which focuses on improving the password recovery process.
Get in touch with our AppSec Specialists
This was a slightly shorter article than usual, but that does not mean that it is no longer an important topic and deserves attention. Quite the contrary: the details overlooked during the development process are what allow and facilitate attackers to compromise the system. Therefore, we must always keep this in mind, look at our system from all angles.
I hope this topic was helpful, and I would like to know what you think on the subject. Leave your opinion in the comments!
See you in the next articles!
