Even if the email doesn't exist, we'll show a message that says the email has been sent successfully. When they submit the email address, this will trigger the back-end to check if that email exists in the database. There's usually a simple form available that lets them enter the email address associated with their account. This is how users will begin the process for updating their password. ![]() User enters their email in the UI requesting a password reset ![]() To ensure that your password reset process is as secure as possible, here is a potential flow that takes into account the security issues we discussed above. The JWT secret key (or signing key) must be carefully protected and hence we do not recommend using JWTs as the password reset token. This would allot them to reset any user’s password. Whilst this makes development easy, a major risk is that if the secret key used to sign them is compromised, the attacker can use that to generate their own valid JWT. Passwords are hashed and stored and it’s important that password reset tokens are too (for the same reasons).Īnother related attack vector is the use of JWTs as the password reset token. To mitigate this risk, we store only the hashed version of tokens in the database. ![]() While there are plenty of problems with an attacker getting database access, one of them is their ability to get users' password reset tokens, like in this research on Paleohacks. They could even gain access if someone hasn't updated the default login credentials. There are several ways an attacker can gain access to an application's database: SQL injection attacks, targeting unpatched database vulnerabilities, and exploiting unused database services.
0 Comments
Leave a Reply. |