Pretty much all websites implement a mechanism to allow their users to reset their passwords. It might be called "forgot password" or "reset your password", and it usually consists of sending a special link to the email address associated with the account.
Losing passwords is quite frequent. In that perspective, using a password manager removes the hassle of memorizing credentials and improves account security. Password managers can also generate long, unique and random passwords automatically.
In any case, website have to provide ways to reset passwords. Otherwise, it could be quite frustrating for users. There's nothing wrong with that, but there are security concerns.
Typical scenario
Typically, the user receives a "reset link" by email. It contains an expiring token and redirects to a specific page where the user can change the password.
So far, nothing shocking or unusual. However, if hackers have managed to compromise the email address, they could reset all associated online accounts. What a single point of failure!
What it means here is that the most common implementation is not bad in itself but is not sufficient, especially in 2022. Security experts recommend using 2FA or MFA in addition to the classic authentication (1FA). It's efficient to mitigate bad situations where users' credentials have been compromised.
7 WTF implementations
The following implementations are particularly flawed. I did not include a classic flaw, though:
App should send consistent responses, whether the accounts exist or not. Otherwise, hackers will use it to guess email addresses or usernames, and ultimately brute-force passwords.
More concretely, don't do that:
this email/username does not exist
Instead, you may use the following:
if this email/username exists, you will receive further instructions by mail
Now, let's see some very bad scenarios.
Passwords sent in plain text
Fortunately, it's less and less frequent, but some websites still use that old and very poor approach. Users receive their current passwords by mail in plain text or hashed with reversible algorithms (e.g. base64).
If you see something similar, it's a huge red sign. Hackers who sniff network traffic could get these credentials without having to decrypt anything.
No password policy
Sometimes, users can use the password reset to bypass the general password policy and set very weak passwords.
Such inconsistencies in the app's flow will be exploited in various attacks. It's essential to apply the same policy everywhere.
Tokens in console.log()
Some websites deploy in production without removing console.log(), sometimes exposing JWT tokens and secrets in the console.
Not so secret questions
"Secret" questions are often used by websites as a security layer during the procedure:
What's your favorite pet?
What's your mother's maiden name?
What's the name of your first school?
The problem is that basic social engineering and OSINT can quickly reveal these "not so private" details. For example, if I want to know the name of your dog, I can probably find it on your Instagram account.
If developers absolutely need to implement security questions, they should avoid the most generic ones and use details related to the platform or the service, something users will not share publicly and hackers cannot guess easily.
Auto-login
Some platforms like to skip the login step after password reset. Once the users have changed their password, the system authenticates them automatically.
While the idea of reducing seemingly useless steps is understandable, it's a warning sign that indicates the website is likely sacrificing security over very little convenience. It's also prone to attacks.
Infinite lifetime
Expiration is one of the most critical points with reset links. Applications have to allow a reasonable amount of time, but on no account should the reset link last forever.
An attacker can manage to intercept the request, and the vulnerability is available for an unlimited time.
Predictable tokens
This flaw is a nasty one, as even if the developers have implemented an expiration time, hackers might reverse engineer the hashing procedure, allowing them to break the existing hashes and predict the next ones. After that, they could forge reset links to gain unauthorized access to the targeted accounts.
In doubt or under time pressure, developers must avoid any DIY (do it yourself) approaches and use tested solutions recommended by security experts.
Wrap up
While nothing is bullet proof, secured implementations of 2FA or MFA and good practices can literally save the day. If you see one of these bad implementations, please report it immediately to the website.
If the support doesn't take your request into account for whatever reason, feel free to leave.
Top comments (0)