Password reset security Every mobile or web application should allow user to reset his/her password. The cause could be as simple as forgotten password, but such mechanism could also save hijacked account (of course if attacker is not able to change user’s email).

The secure design of password reset module should focus on best security practices like:

• Preventing from user/email enumeration,
• Preventing from token guessing,
• Preventing from token reuse,
• Token should have limited lifetime,
• Making sure that account is not locked when password reset has been initiated,
• Password change logging,
• Passkeys correlation*

*If application utilizes passkeys, password reset should be considered as an additional attack vector. This, however, could be a topic for another article). Where all seemed normal During most recent mobile application pentest another point to consider came out, which was a big surprise.

The password reset flow was as normal as in every other application.

Have you forgot your password? Please provide an email which was used during the registration After the button was clicked, as usual, user was taken to login page where another usual information was provided: According to prompted information, user has received an email with password reset link: Then what’s wrong? But what happens if we intercept mobile traffic and check client-server communication?

The request below is sent when the initial reset password button was clicked: The below response contains the surprise – the same token which was delivered to provided email address is provided in the response body: Screenshot below presents a page which is displayed after clicking the link above: Such behavior opens a possibility to provide any email corresponding to existing application user and then simply open a password reset link from a response in order to set a new password for the selected account. Lesson should be learned Such behavior may result with catastrophic effects from technical and legal (GDPR) perspective, if persists on the production system.

Make sure that the mobile application is subject to regular security audits in order to discover vulnerabilities in the APIs before attackers exploit that in the wild.

Additional security countermeasures such as SSL Certificate Pinning should be in place – this should not be treated as a main defense, but more like an extra layer (same as WAF) which could deter attackers by forcing to allocate additional time to for analysis.