In a world where passwords remain the most implemented way to authenticate someone, setting up a website password management strategy both simple and secure can sometimes be quite challenging.
One key aspect of a password management strategy is the way users will recover a password they lost. The objective is to find the best scenario, simple enough to allow users defining a new password without going through exhausting and complex steps, but secure enough to avoid account hijacking by malicious people.
Poorly secured password recovery scenario:
- Ask for the connection ID (email or ID) as well as the date of birth.
- Verify provided information
- Ask for the new password the user wants to define
- it is quite easy to get the date of birth of someone along with their email address (if you know that person, of through social engineering)
- if a bad guy changes the password (knowing the date of birth), the real account owner is not made aware of the change and cannot react
This process is badly secured and is not recommended, especially if the web application provides access to sensitive data or transactions.
Let’s look at a secured password recovery process
- a. Ask for some personal data, like last numbers of social security number, date of birth, client number…
b. Ask for answers to security questions previously given during registration (“what was you first home phone number during your childhood?”, “name of your first pet?”… )
- Send a simple secret code through another communication channel (secondary email address or mobile phone). The user will possibly choose which channel they prefer. This secret code must have a limited validity in time and must be deactivated once used a first time.
- Once the secret code is confirmed, display a password change form, asking for the new password.
- Confirm that the password has been changed by sending an email to the user (on the primary email address and possibly on the secondary one). In case of fraud, the victim will therefore be warned.
Steps 1.a and 1.b can be complementary, e.g. you can choose to implement only 1 a and not using security questions. The detailed choice of implementation will depend on the data already collected during registration and may possibly imply adding information in the registration forms.
From a technical standpoint, the password recovery process will have to be protected against CSRF (Cross Site Request Forgery) attacks, which could allow a malicious website to perform password changes on the victim website, without the user noticing it.
A user account must be locked (for a given period of time) if multiple password change tentatives are done on it.
Developers must also ensure that the different steps of the password recovery process require preceding steps being properly completed. A logical security flaw would allow an attacker to directly go to step #3 without confirming the user identity.
It goes without saying that all features involving password and all authenticated pages must be properly served under SSL (HTTPS).
The current trend is on using a secondary channel to verify the identity of the user (as done on step #2, usually with an SMS code). PII confirmation and security questions are in decline, because they often imply a loss in ergonomics and increase the drop-off rate when consumers have to fulfill endless registration forms.
As we can see in the management of password recoveries, web applications security is done through purely technical items (code, cryptography…) as well as designing secure processes and user journeys.
Verifying your existing processes
When it goes to penetration testing, it is obvious that automated security tools, focusing on technical flaws, cannot detect weaknesses in this kind of process, even if the recovery process we just discussed is one of the most common in web applications.
Only manual penetration testing and security reviews provide good results here.