Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Research on how to allow users/admin to reset passwords #706

Open
mario-nt opened this issue Feb 4, 2025 · 2 comments
Open

Research on how to allow users/admin to reset passwords #706

mario-nt opened this issue Feb 4, 2025 · 2 comments
Assignees
Labels
Needs Research We Need to Know More About This

Comments

@mario-nt
Copy link
Contributor

mario-nt commented Feb 4, 2025

Part of #657

Password reset is a complex subject and can be tackle in a lot of different ways, we have to consider possible security breaches and users ease to change their password.

Research has to be done on the topic before discussing the right way to approach this, taking all the factors into account.

Estimate time of completion: 4-16 hours (including final thoughts after research)
Actual time of completion: 12 hours

@mario-nt mario-nt self-assigned this Feb 4, 2025
@mario-nt mario-nt added the Needs Research We Need to Know More About This label Feb 4, 2025
@mario-nt
Copy link
Contributor Author

mario-nt commented Feb 4, 2025

Conclusions:

After doing some research I noticed the following:

All the websites I checked (Amazon, Netflix, Outlook, Disney+, Github, etc) required the user to self manage a password reset. None of them send the new password by email.

Usually the user navigates to a page and then request a password reset.

Then, the user is asked to enter some personal information (email, phone, username, security question) before an email is sent to them so they can continue with the process of creating a new password. Other platforms like Disney+ have the option to send a code to the email of the users, and that code can later be used to directly log in into an account.

When the users click on the link inside the reset password's email, it will be redirected to a page where the user can write their new password so they can log in with their new one.

Security vs convenience

There is a tradeoff when it comes to handling passwords resets, favoring either the user (by making the proccess less secure but less troublesome) or security (adding extra layers of security but bothering the user with more steps or information to remember, also it is more prone to a permanent access loss to an account)

Here's a quick table with several methods that could apply to a password reset, split into two columns:

User Security
Randomly generated code when creating an account (this code is only generate once and if lost, the user will lose access to their account permanently)
Don't require any other recovery info besides the email 2FA
Can use username or email to get a password reset link Only one of them is needed (username for example if its not displayed anywhere in the app)
Longer expiration date for reset links Shorter expiration dates
Don't require any proof of ownership Require additional info to recover access to account (payment method info, receipts, software codes previously redeemed, etc)
Don't required a verified account Required a verified account

I think it is a good idea to let the user choose their own level of security, that way, we don't bother users too much, and those who want a more secure account, they can enable a two factor authentication or something similar.

Proposal

As a first iteration, I would add a forget password link to the sign in form, then, the user will be prompted to enter their email address or username (I like the idea of asking for the username when it is private, as it can work as a filter for DOS attacks, but in our app, the username is public so that does not apply.

Asking for the email is a bit more secure, but if someone knows the other user's email, could start asking for passwords resets.

So I think for the moment, asking for the email and adding a CAPTCHA would be a middle point regarding security and bothering the user too much.

I still have to do some research on how hard it is to implement a CAPTCHA, and we can even add this later on.

After that step, an email containing a link with a token identifying that particular user would be sent to their email (we have to consider if we only allow users with verified emails to change their passwords, and let them know this when signing up)

Once the user/token has been verified, a create new password form will be shown, and the user can create a new password. Once completed, the password will be changed in the database.

Even if a password reset has been requested, the user should be able to access their account with the old password until a new one is created.

Another approach would be to redirect the user to a page where is asked to enter a code that was sent to their email (the user can request that another code is send again if the email is not received), once the code is verified the user is redirected to the password form.

What do you think @josecelano @da2ce7

@josecelano
Copy link
Member

josecelano commented Feb 4, 2025

Hi @mario-nt, I think in the first iteration we can implement only the basic reset-password link (step 1).

  1. Basic reset-password link.
  2. Consider implementing a CAPTCHA for the reset password form and other public forms in the app (signup, login).
  3. Consider adding 2FA.
  4. Consider using passkeys.

I'm not sure if CAPTCHA makes sense anymore and it seems users don't enable 2FA very often.

Basic reset-password link

  • It only works when the users provide their emails.
  • We have to warm users in the sigup form there will not be a way to recuperate their account if they loose the password.
  • Short expiration for the token.
  • Users can only reset the password with the token.
  • I prefer the option where the app send the link to the reset form and the code. It seems to be safer than sending the link with the token (it reduces the risk of token leakage through URL exposure). However I think it's also harder to implement.

NOTE: if we implement this, I would not implement this unless there is a reason to do it that is not the users trying to reset their own password.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Research We Need to Know More About This
Projects
None yet
Development

No branches or pull requests

2 participants