Implement best practices for password recovery

Question

I want to implement password recovery in my web application.

I would like to avoid secret questions.

I can just email the password, but I think that would be risky.

Perhaps I could create a new temporary random password and send it by email, but I think it is as risky as the one above.

Can I send a URL, for example, by email http://example.com/token=xxxx where xxxx is a random token associated with the user. Therefore, when the user navigates to this URL, he can reset the password.

Answer 1

First of all, do not store a text copy of the user password or even an encrypted version. You only want to save a hashed copy of the user's password.

Regarding recovery solutions, I found that a recovery link to change a user's password is the best solution in my experience. This will probably be a little more convenient for the user, although at the same time it will be substantially identical from a security point of view, since the sending of a new random password will be changed after the next login. I would recommend that the restored url expire after a reasonable short period of time, and also be available only once.

Answer 2

When I was in the Air Force, we had a security rule: when setting or resetting passwords, do not send the user ID and password in the same letter. Thus, if someone intercepts email while tracking passwords, he must successfully intercept BOTH emails and be able to connect to them in order to compromise security.

I have seen many sites that use "go to this url to reset your password." Maybe I missed something - I do not claim to be a security expert, but I don’t understand how it is safer than just inventing a new temporary password and sending it. If a hacker intercepts an email, why can't he go to this link and see a new password, as well as a legitimate user? It seems to me that this is an extra hassle for the user without enhancing security.

By the way, congratulations on NOT using security issues. The logic of this device eludes me. From the very beginning of computer security, we told people: “DO NOT make a password that is information about yourself that a hacker can detect or guess, for example, the name of your high school or your favorite color. Perhaps a hacker to find out the name of his high school, or even if they don’t know you or don’t know anything about you, if you still live near where you went to school, they could get it by trying to find local schools until they hit.a small number of likely favorite colors to the hacker could guess about it. And .d. Instead, the password should be meaningless combination of letters, numbers and punctuation marks. " But now we also tell them: “But! If you have a difficult time, remembering that a meaningless combination of letters, numbers and punctuation is not a problem! Take some information about yourself that you can easily remember - for example, the name your high school, or your favorite color - and you can use this as an answer to the "security question", that is, as an alternative password.

In fact, security issues make it even easier for a hacker than if you just chose the wrong password to start with. At least, if you just used personal information for your password, the hacker would not necessarily know what part of the personal information you used. Did you use your dog's name? Date of Birth? What is your favorite ice cream flavor? He must try everyone. But with security concerns, we tell the hacker exactly how much of your personal information you used as a password!

Instead of using security issues, why don't we just say: “If you forgot your password, it appears at the bottom of the screen. If you are trying to hack someone else’s account, you are absolutely forbidden to scroll.” It will be a little less safe.

So that you do not wonder when sites ask me about the city where I was born, or about the manufacturer of my first car, I do not give an answer to this question. I give a meaningless password.

</ bombast>

Answer 3

It is hard to say what you should do, since almost any solution to this problem will weaken security. If you may not want to investigate sending SMS, checking callbacks, one-time password generators or other similar schemes that require password recovery to another medium.

However, what you should not do :

• Send the password - because in the end, as already mentioned, you do not have it.

• Create a new temporary password - this is not only unsafe as sending a password, but also leads to the possibility of a denial of service attack. I can go to the site, pretend to you, ask for a new password, and then (if you have not verified your email address), you can’t log in, don’t know why you need to request a new new password ..

Token is probably the way to go. Receive notification of a forgotten password request, but does not take any action if you do not confirm this. You would also make this a one-time token with a relatively short expiration date to limit the risk.

Of course, a lot depends on the application. Obviously, protecting financial and other sensitive information is more important than preventing your account from being hacked at mytwitteringfacetube.com, because although it’s inconvenient if someone wants to steal someone on a social networking site, they can simply open their own account and masquerade with stolen information anyway.

Answer 4

Obviously, you cannot send the original password by e-mail because you do not store it (right ?!). Sending a temporary password (which needs to be changed since it only works for one login), and a link to reset the password is equivalent from a security point of view.

Answer 5

I do not understand the secret question. It doesn't look like I will make my password "BlueHouse" and then I will make my security question "What are your two favorite things?" and the answer is "Blue and the house." A security issue is not the magic key to getting the actual password. This is usually a way to get a new password sent to the email address in the file. I don’t know how else you do it, but it looks like you are doing one of two things.

1) The user clicks the "I forgot my password" button, and a new password is sent to the user.

2) The user clicks the "I forgot my password" button, and then must answer the security question before receiving a new password by e-mail at the address in the file.

It seems to me that option number 2 is safer.

Why is sending a token safer than sending a password? If the email account was hacked, it was hacked. It doesn’t matter if there is a link to reset the password, token or new password. Do not forget that most sites do not say "A new password has been sent to the following email address for hacking." The hacker needs to guess the email address to be hacked.

Answer 6

I agree with Andy. As a rule, are security issues independent of the password? (my). They have a question and answer, and they are not associated with a password. It seems like this is used to prevent false password reset requests and it really makes sense.

Imagine: someone can go to the "forget password" utility and enter millions of email addresses - or just one person they want to annoy. If at this moment the password is reset, the people belonging to these email addresses will then have to notice the reset password in their email and log in to the site with the reset password the next time they go there. With a security issue, it’s not so easy for someone to do.

I see that Amazon is sending a link to this email. They also require that you enter captcha to prevent DOS attacks. Since this is a link, I believe that this means that they will not reset the password immediately, and that will be reset as soon as the user clicks on the link. In the above scenario, the user will simply see the email message and notice that “no, I didn’t do this”, and continue to do my job without requiring an extra password change. The security question may have prevented the attempt at the beginning, and the legitimate user was to receive the email first.

Here is the document on it: http://appsecnotes.blogspot.com/2010/09/latest-forgot-password-best-practices.html

This question actually recommends security questions as the main part of the authentication process. And by sending an authentication code by email and requesting it, you can add an extra layer.

Answer 7

In fact, it all depends on what kind of security you want to have. One of the extremes is the reset password process, which includes contacting and confirming that you are who you are, for example. via id, as your mailbox may also be compromised. In fact, since people tend to use the same password all over the world, this is very likely. On the other hand, there is a standard approach that simply involves sending email with a random new password.

Secret questions and answers are another form of username and password with a fatal error, which they usually incredibly easily guess, are so good that you don't want to use them.

As for the marker, I do not think it is of great importance for general security. Regardless of whether you send a token that allows the user to change the password or immediately send an arbitrary password, it does not matter much.

Just make sure that the token is used only once and preferably only for a limited period of time, for example. + 24h after request.

And, as pointed out in previous answers, NEVER save simple passwords. Hash them. Preferably add salt .

Answer 8

Here is how I resolved it:

I added the retrieve_token and retrieve_expiration fields to the 'users' table.

The user asks for the reset password by providing his email and filling in captcha. A random hashed value is generated for its retrieve_token field, i.e. md5($user_id.time()) , and retrieve_expiration will be set to datetime, which expires in the next 45 minutes. Email is sent to the user with the link:

https://example.com/reset-password?retrieve_token=912ec803b2ce49e4a541068d495ab570

SSL must be required when authentication is required. You can also add a table to register reset requests that store email and IP address. This helps to track down possible gross attacks, and you can block the attacker's IP address if necessary.

You can implement a security question to request a reset password, but I think that captcha will be enough to prevent someone from repeating the request several times.

Answer 9

@Jay. The reason why you go to the reset URL of your password instead of just sending someone a new temporary password is more than just security. Without something like a token URL, a person could reset the password of others. No need to access email. If someone has a bone to choose someone, they could just start a new password reset. Then the poor target needs to log in and change the password again and again.

By sending a token, the user's password does not change until he logs in and confirms it. Spam reset can be ignored. Tokens are just as easy (if not simpler) to generate a new password using a GUID, this is not a hassle for the developer.

In addition, since the GUID is unique (there may not be a generated password), the token can be bound to the username. If the incorrect username is specified in the URL, then the token can be canceled (i.e. when another person initiates it and someone intercepts it), assuming that the username does not match the email name).

Answer 10

@Jay. The proper use of security issues is to initiate a reset password, and not to actually reset the password. Without a mechanism such as a security issue, it would be possible to initiate a reset password. Although it seems to beign, sending an e-mail reset can be sent by e-mail, which can no longer belong to the original owner. This is not uncommon. For example, when employees leave the company, often these letters are sent to another employee. A defensive question adds a low level of enthusiasm to this scenario. It also reduces problems when one person continues to enter a reset password into the wrong account, which leads to some poor sod getting inadvertently spammed. The security issue is not really intended to be truly secure; they are only intended to reduce such scenarios. Anyone who uses the secret question to actually reset does the wrong password.

Answer 11

Regarding security issues. As a user of sites, I personally do not use them (I introduce garbage into them). But they, of course, are not useless or meaningless, as some of them say.

Consider this situation: A user of your site left his desk to go for lunch and did not block his workstation. Now the ill-fated user can go to the page to recover / reset the password and enter the username. After that, the system will email the recovered password reset without asking for a security response.

Answer 12

Here's an example of how someone did this using Node.js, basically generates a random token, expires, sends a link with an attached token, has a reset/:token route, which ensures that the user exists with this token ( which also did not expire) and, if so, redirect to the password page reset.

http://sahatyalkabov.com/how-to-implement-password-reset-in-nodejs/