How secure is my system for a password reset?

Question

I am using my custom Parse Server with Heroku which I am pretty sure (99%) that it is decently secure using things like oAuth2 and 1 way hashed passwords.

The problem is I am trying to implement my own custom password reset.

This is what I am doing currently:

• User requests password reset

• A custom token is generated (has a timer to be deleted after 10 minutes)

• An email is sent with a http(s) POST request to post the token id

• My application checks if the token id exists

• If true, the user is redirected a webpage where they can reset their password

• User clicks submit and their new password is posted using http(s) POST

• My server can then safely process and set the new password

First off, is it a problem using an initial http(s) post request with the token id to request a password reset? I know if anyone got hold of this physical link while it was active (within 10 minutes) they could change a users password then login.

Second, when I make another http(s) POST request with the new user password, is method this "decently" secure to and safe practice? Because again if someone could somehow intercept the request they could gain access to the users "new" password?

My password reset doesn't need to be perfect, however I want it to be good practice.

Is there anything serious I am doing wrong / making a mistake and if so what do I need to be to fix it?

*Note I use "http(s)" with (s) in brackets because I haven't brought an SSL yet.

Thanks.

Answer 1

Generally, it is ill-advised to implementing your own session handling. If you can, you would be better off by using a well known and well tested implementation.

These are the issues I see in your procedure.

User requests password reset

How will you handle misuse of this function - will you send one email per reset attempt, or will you implement a restriction to prevent misuse?

A custom token is generated (has a timer to be deleted after 10 minutes)

How will you generate the token? There are many attacks on "random" numbers.

What will happen if the timer fails - will the reset password token be valid forever? How about storing the date it was generated, and then only allow tokens that are "fresh"?

An email is sent with a http(s) POST request to post the token id

I think an ordinary link is a better choice here. POST will require mail clients to either accept html forms, or javascript - which most dont.

My application checks if the token id exists. If true, the user is redirected a webpage where they can reset their password

Where will the redirected webpage be located? It should be unpredictable as well, or require the valid reset password token in order to avoid bypass vulnerabilities.

User clicks submit and their new password is posted using http(s) POST My server can then safely process and set the new password

Sounds reasonable

--

Now, you should also invalidate the password reset token. No need to let it float around if it has been used.

And needless to say, HTTPS is a good idea.