[BUG] Can reset some other user's password by accidently mistyped OTP

[hassan404]

Describe the bug A user can reset the password of some other user if they accidently/intentionally type their OTP password

How to reproduce

• Request a token A for User1 using ResetPasswordRequestToken APIView
• If User2 provides token A to ResetPasswordConfirm APIView (accidently/intentionally), they will be able to reset password for User1

Expected behavior During OTP Validation, a user should not be able to accidently change email of another user, no matter how low the probability of doing so

[ra-dave]

If User2 somehow comes into possession of the token for User1, what are you expecting can be done about that?

[nezhar]

This is a very interesting use case. We may need to think first on how does User2 get into possession of the token. If User2 has access to the mailbox of User1 the token is compromised, and any other factor added would not really help preventing this.

[hassan404]

@nezhar @ra-dave e.g. for a 4 digit OTP, it can simply be brute-forced if the APIs are not throttled, without getting into user's mailbox. There are only 10000 possibilities from 0000 to 9999. Just need to somehow know the the email of the user account to hack, can ask to reset password and then brute-force their way into resetting it.

We have experienced a brute-force attack like this and using 4-digit OTPs is common. Even if we throttle it, a simple python script can hack it in a matter of days

As a workaround, we can send a uid that is unique to the user in the password reset email and ResetPasswordConfirm can validate if the token actually belongs to that user using the uid, just an additional security measure