Abusing Password reset functionality to steal user data (Part–2)

In continuation to my last blog about possible attacks on a password reset functionality, this part of the same series will look into below two implementations:

• Email sent with a temporary password or current password
• Secret questions asked and then given the option to reset the password

I will mention possible issues which might occur with each of these implementations and how an attacker can make use of such vulnerability to hack an account. So, let’s start with the first:

Email sent with a temporary password or current password:

You must have seen various applications over the internet which uses this type of password reset. The process is:

• User clicks on the button of “Forgot Password” or a similar button and is sent to a page where he needs to select the account or provide the associated email address.
• Once the user provides the email address or username, the application checks if the account is valid or not.
• Finally, the application sends the password in clear text over an email to the user.

In this whole process, the core idea is that the application relies on the security of the email system and this is the catch. What if:

• The user’s email has got hacked and now the attacker is trying to get access to his/her bank account.
• The email which the user uses does not provide proper security and is vulnerable to hacks.
• The email account is accessed over HTTP, and hence the traffic between the email account and the user’s browser is vulnerable to Man In The Middle Attack.

Considering the above cases, it is not the best advisable method for implementing the password reset functionality. Let’s take an example and see the possibilities:

John is a regular user of an e-commerce website (www.bad-ecom.com) and loves to shop. Unfortunately, long back when he registered on the website he used a poor email service provider. But due to long usage, he is not willing to create a new account as all his older orders are there with the old account only.

Paul lives next door and is always hunting for opportunities to hack John. One day, Paul was able to guess the password of John’s WiFi network and started to sniff all the traffic. But unfortunately, everything was encrypted, all the major websites that John access are over HTTPS. To his surprise, there was one website which was working on HTTP and this was the bad email provider for John. Now, Paul got access to John’s email account but could not find anything in the email, apart from emails of www.bad-ecom.com.

So he then decided to reset the password of bad-ecom application and was able to get access to John’s account on bad-ecom as he got the clear text password over the hacked email. The logical issue is that the bad-ecom application is relying on the email to be secure enough. It might come to your mind that if the email gets hacked then all the methods of password reset can be hacked, but I will explain the best method of implementing this in my next part of the blog.

Also, there are cases in which this implementation may have improper settings like;

• Temporary password never expires
• Temporary password is easy to guess
• There is no rate limit applied for temporary password generation.

Considering all the above cases, it is never the best way to implement for password reset functionality. Similarly, let’s analyze the implementations with secret questions.

Password Reset with secret questions:

Before going ahead, just think for once that how many times we actually try to choose the most difficult question and provide a ‘difficult to guess’ answer…… Never… right?
So for a critical application, relying on this type of implementation is itself very vulnerable because of human nature.

But there can also be other ways of hacking a secret question-based system. For example, some time ago a Facebook vulnerability was disclosed. In this, after answering the secret question wrongly for 3 times, the user gets an option to choose one of the friends from his/her friend list to recover the password. So, it was possible for an attacker to add himself to the victim’s account and then choose himself while resetting the password of victim.

Hence, it is very crucial for secret questions to have difficult answers and limit the number of wrong attempts. If you have selected your dog’s name as the secret question, then that’s not very secret.

Take a look at Secret Questions for a popular website.

Most of the above mentioned questioned does not have a very secret answer. Hence, there is a possibility that the victim might unknowingly leak details about these things. For example, how many times do you ask the person over a call (from a bank) to validate and prove his identity before you answer his questions…. very rarely or probably never. So, an attacker can make a fake call to you and get this information easily from you only.

Any application which deals with critical data, secret questions should be one of the details required to reset the password, but should not be the only detail required.

Some suggestions to developers:

• Do not only rely on users to chose the difficult questions, rather implement something which restricts them to have ‘difficult to guess’ answers.
• Provide an option to choose personal questions.
• Never directly give the option to go to the secret questions; this will give the attacker a hint about what to social engineer for i.e. never show all the secret questions on the same screen. Always go to next question if the user answers the previous one correctly.

Secret questions are being used in numerous websites as a mechanism to reset the password. But it may have vulnerabilities if not implemented properly.

Thus, it is important to assess the level of security of your application at regular intervals. This is as simple as answering a 5-minute questionnaire like the one below –

Follow the next and final part of this series to know about the best possible way to implement a password reset functionality.