A7:2021 | Password Reset (7) | Cycubix Docs

How to prevent abusing the password reset function

After learning how to abuse the password reset functionality you should now also know how to defend your own website against such attacks. If you want an extensive description of all mitigation methods take a look here: https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html

This lesson will summarize the important points mentioned in the cheat sheet above.

How to use security questions for user verification

Security questions are an easy way to find out information about the validity of the user without asking them for verification data. The problem is, that there are not that many types of security questions and the answers to most of the questions are the same among many users. This makes it easy for an attacker to just guess the question and the answer.

An easy way to make it harder to guess the security question is to let the user themselves decide on the question they want to answer. Further information on this topic can be found here: https://cheatsheetseries.owasp.org/cheatsheets/Choosing_and_Using_Security_Questions_Cheat_Sheet.html#user-defined-security-questions

Sending data over the network

Everything that gets sent via the network in any direction can be read by an attacker. Some data makes it easier for an attacker to compile crucial information on the user’s account that helps them bypassing login and password reset restrictions. Therefor try to not send account information (like usernames, e-mails, …​) over the network during the password reset procedure that didn’t get entered by the user themselves!

For example: If you send a password reset link to a user via e-mail, do not include the username into the password reset form itself by any means! The user doesn’t have to see their username on the form, because a non-malicious user already knows their name. Make it as hard as possible for an attacker to gather further information.

About the password reset token

Password reset tokens allow a user to reset a password without inherently safe information about the verification of the user. Hence they should be safe. It should be hard to guess such a token. The token should also be only valid for a short amount of time and should be invalid after the user successfully reset their password.

Logging user actions

Logging alone can’t prevent any attacks but it can make it easier to determine that an attack happened and how the attacker tried to bypass security. You can also use logs to determine if an account really got hijacked and if it has to be returned the the rightful user. Actions you can log are: How did the security questions get answered? When did the access to the password reset link happen in comparison to the time the e-mail got sent? Were there failed attempts?

Two factor authentication

It is always safer to do an authentication process via two or more separate ways on two or more separate devices. If a user wants to reset their password you can ask them to enter verification codes sent to them via SMS, Messenger, or similar. This makes it hard for an attacker to bypass the verification process, because they need physical access to another device. On the other side it requires the user to give you additional information on the matter of contacting them, which is not welcomed bz everyone.

Further reading

We highly recommend to take a further look on the cheat sheet linked in the introduction! The password reset functionality is easily abusable for an attacker when implemented incorrectly. You can make it harder for an attacker to abuse it by just following a few suggestions made here and in the cheat sheet!