How to create a password reset link?

You should not store passwords that can be recovered. Use one-way algorithms like the one implemented by BCrypt (option that I use in my projects). This means that your 12345 password becomes something like 534df$aa in the bank, and it is not possible to transform 534df$aa back to 12345 , just get 12345 , apply salt defined and reach the generated hash.

As for password recovery: you have an entity (a table) that stores the password reset requests that are linked to the user who requested them. A dynamic hash is generated to increase the security of this process. When the user follows the link, it is informed via QueryString hash, it is verified in the base and, if the link is found (proving that the link is legitimate), a new password is defined by the user through the appropriate form, displayed by you on this screen.

Never implement features that return the password that the user has registered, because storing the password so that it can be recovered is a security flaw.

Links used:

• link
• link
• link (thanks Bacco!)

Remember Password

You can create a link , where the user informs the e-mail of it and with this email you provide a link to troca de senha , since if the password is encrypted in the bank I believe there is no way to revert to criptografia in string format.

Since e-mail will be in base de dados and an email belongs to a user, to tell which user to update or to get an ID based on it.

Note: I do not know your tables and their fields, so think of email as your ID.

Try Password Exchange:

First the user should inform the senha atual , the site checks if the senha is equal to the banco de dados . If they are the same you can allow them to report nova senha and sua repetição .

Fields:

Current Password: | .......... |

New Password: | ............. |

Repeat Password: | ............ |

These links have tokens for each recovery request and / or password change.

For each password recovery request, you should follow the following flow:

Technically, this would be logical.

And just like a log-in system, a password should not be decrypted . Instead, run a new one. Rainbow tables sometimes already bother one-way encryptions, imagine if you used a base64 to "encrypt" the basis of your passwords .

No longer, do not decrypt and use secure cryptography as BCrypt.

Some tips:

Obviously, token encryption is fanciful.

Option 1 (simple)

Generating a random password writes it to its database using its encryption script, and sends the user this new random password.

If there is an attempt to change the password by another malicious user, the real user will have to log in with the new password.

Option 2 (medium)

Switch the encryption algorithm to one that can be decrypted. This way you can send the user his own password, without major problems. The bad part is that if this user "lost" the email, sending the password you can reveal to an impostor (remembering that many users use the same password for several different accounts). And if a user has access to his encryption algorithm he can reverse the encryption of his entire bank.

Option 3 (difficult)

Generate a hash for password exchange. It is not complex and rather laborious to create a new table to store a random hash that will be sent to the user requiring this to reset the password. This option is, say, the most complete, you can not easily avoid theft of an account if the "attacker" has access to the email, but at least the password he will not know. And if a malicious user requests password recovery, the real user can simply ignore the email and continue with the old password.

First you need to know the type of Hashes you are using.

Because there are single-handed and double-handed Hashes, if it is one-way, you can not decrypt the password:

Single-hand: In this case your system needs to generate a new temporary password, and send this new password to the client with the link for it to reset this password.

Double-hand: In this case your system can search the user's email for the password and send it to his email, but it is not a good practice.

UNIQUE HAND CRIPTOGRAPHS IN PHP

MD5

<?php
    $string = 'O rato reu a ropa do rei de Roma';
    $codificada = md5($string);
    echo "Resultado da codificação usando md5: " . $codificada;
    // 54cf74d1acdb4037ab956c269b63c8ac
?>

SHA1

<?php
    $string = 'O rato reu a ropa do rei de Roma';
    $codificada = sha1($string);
    echo "Resultado da codificação usando sha1: " . $codificada;
    // b186b709f7cf5a1d98d413379a66e511df8d59a4
?>

DUAL HAND CRIPTOGRAPHS IN PHP

BASE64

<?php
    $string = 'O rato reu a ropa do rei de Roma';
    $codificada = base64_encode($string);
    echo "Resultado da codificação usando base64: " . $codificada;
    // TyByYXRvIHJldSBhIHJvcGEgZG8gcmVpIGRlIFJvbWE=
    $original = base64_decode($codificada);
    echo "Resultado da decodificação usando base64: " . $original;
    // O rato reu a ropa do rei de Roma
    // Note que $original vai ser idêntica a $string
?>

Following is a link explaining a little more about the types of encryption in PHP

link

My opinion I think you should be better in case you have a logic to generate a new password for the user, concatenating uppercase and lowercase numbers and special characters and send this new password or to the user's cell phone, which in my opinion is well because, depending on the encryption it uses, it does not have a reversion to plaintext, and if it is not 100% safe, I would instead generate a new password and send it to the client and when the client logged in on the system would ask for the password to be exchanged, but would not force it to do so.

I hope you have helped