Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.
2 added 1 character in body
source | link

I am going to start with saying I have no idea if a best practice exists on this, but I will go ahead and answer with two points of view in mind; the security view and the user view...

First off, when a password request is made, the password should not be removed. What if you user all of a sudden remembered their password? TheThey should be able to login without the reset request affecting their experience. Instead a onetime securely (lot's of entropy) generated random string should be generated and stored with the user as the last reset request identifier. A timestamp should be stored as well. Then the link that the user clicks on in the email should contain that ontime code and their email address in order to actually reset. You can also check the timestamp that was set to see if the request was made within the past 15-minutes or so (just an example). The other point in this is that if the person really didn't request it, they should still be able to log in.

Second, the best way to limit this is to use something like reCaptcha. It will get annoying for the user to constantly spam.

Third, I don't think it's necessary to ever send more than 2 emails within a specific time window.

I think the bigger security risk here is someone brute-forcing your forgot password page in order to discover account login information. Being able to detect that someone is bruce-forcing your "Forgot Password" page would be huge. Maybe recording the number of account reset requests from a specific IP address and watching for when that number gets too high in a certain amount of time and requiring the person to send an email to help@yourdomain.com in order get their account reset. [You will want to play with the numbers here because you need to consider people that sit behind NATs, notably employees at large corporations...you never know when everyone is going to forget their password on the same day].

I am going to start with saying I have no idea if a best practice exists on this, but I will go ahead and answer with two points of view in mind; the security view and the user view...

First off, when a password request is made, the password should not be removed. What if you user all of a sudden remembered their password? The should be able to login without the reset request affecting their experience. Instead a onetime securely (lot's of entropy) generated random string should be generated and stored with the user as the last reset request identifier. A timestamp should be stored as well. Then the link that the user clicks on in the email should contain that ontime code and their email address in order to actually reset. You can also check the timestamp that was set to see if the request was made within the past 15-minutes or so (just an example). The other point in this is that if the person really didn't request it, they should still be able to log in.

Second, the best way to limit this is to use something like reCaptcha. It will get annoying for the user to constantly spam.

Third, I don't think it's necessary to ever send more than 2 emails within a specific time window.

I think the bigger security risk here is someone brute-forcing your forgot password page in order to discover account login information. Being able to detect that someone is bruce-forcing your "Forgot Password" page would be huge. Maybe recording the number of account reset requests from a specific IP address and watching for when that number gets too high in a certain amount of time and requiring the person to send an email to help@yourdomain.com in order get their account reset. [You will want to play with the numbers here because you need to consider people that sit behind NATs, notably employees at large corporations...you never know when everyone is going to forget their password on the same day].

I am going to start with saying I have no idea if a best practice exists on this, but I will go ahead and answer with two points of view in mind; the security view and the user view...

First off, when a password request is made, the password should not be removed. What if you user all of a sudden remembered their password? They should be able to login without the reset request affecting their experience. Instead a onetime securely (lot's of entropy) generated random string should be generated and stored with the user as the last reset request identifier. A timestamp should be stored as well. Then the link that the user clicks on in the email should contain that ontime code and their email address in order to actually reset. You can also check the timestamp that was set to see if the request was made within the past 15-minutes or so (just an example). The other point in this is that if the person really didn't request it, they should still be able to log in.

Second, the best way to limit this is to use something like reCaptcha. It will get annoying for the user to constantly spam.

Third, I don't think it's necessary to ever send more than 2 emails within a specific time window.

I think the bigger security risk here is someone brute-forcing your forgot password page in order to discover account login information. Being able to detect that someone is bruce-forcing your "Forgot Password" page would be huge. Maybe recording the number of account reset requests from a specific IP address and watching for when that number gets too high in a certain amount of time and requiring the person to send an email to help@yourdomain.com in order get their account reset. [You will want to play with the numbers here because you need to consider people that sit behind NATs, notably employees at large corporations...you never know when everyone is going to forget their password on the same day].

1
source | link

I am going to start with saying I have no idea if a best practice exists on this, but I will go ahead and answer with two points of view in mind; the security view and the user view...

First off, when a password request is made, the password should not be removed. What if you user all of a sudden remembered their password? The should be able to login without the reset request affecting their experience. Instead a onetime securely (lot's of entropy) generated random string should be generated and stored with the user as the last reset request identifier. A timestamp should be stored as well. Then the link that the user clicks on in the email should contain that ontime code and their email address in order to actually reset. You can also check the timestamp that was set to see if the request was made within the past 15-minutes or so (just an example). The other point in this is that if the person really didn't request it, they should still be able to log in.

Second, the best way to limit this is to use something like reCaptcha. It will get annoying for the user to constantly spam.

Third, I don't think it's necessary to ever send more than 2 emails within a specific time window.

I think the bigger security risk here is someone brute-forcing your forgot password page in order to discover account login information. Being able to detect that someone is bruce-forcing your "Forgot Password" page would be huge. Maybe recording the number of account reset requests from a specific IP address and watching for when that number gets too high in a certain amount of time and requiring the person to send an email to help@yourdomain.com in order get their account reset. [You will want to play with the numbers here because you need to consider people that sit behind NATs, notably employees at large corporations...you never know when everyone is going to forget their password on the same day].