Utilizaría un código hash para validar los detalles en la URL de restablecimiento de contraseña. Todo esto se puede hacer sin escribir nada en el DB o enviar información privilegiada a un atacante.
Para explicar brevemente sal y hashing de contraseña normal; digamos que la sal es 1111 y la contraseña es password, concatenaría los dos y trocearía la cadena 1111password, digamos que esto le da un hash de 9999, luego almacenaría el sal original 1111 y el hash 9999 en su registro de usuario.
Cuando está validando una contraseña, utiliza la sal almacenada, concatenar el intento de contraseña, hash it y compararla con el hash almacenado. Por ejemplo, asecret se convierte en 1111asecret pero hash en 8888. Esto no coincide con el hash original, por lo que la coincidencia de contraseña falla.
Por supuesto, la sal y el hash normalmente se generarán correctamente y se calcularán con las bibliotecas de cifrado establecidas (¡no invente la suya propia!).
Para la URL de restablecimiento de contraseña, pondría el identificador único para el usuario, es decir, la dirección de correo electrónico, la fecha en que se realiza la solicitud y un nuevo hash. Este hash se generaría a partir de los detalles concatenados más la sal y el hash ya almacenados para el usuario.
Por ejemplo:
Email: [email protected]
Request Date: 2014-07-17
Salt: 1111
Hash: 9999
generar una nueva almohadilla de los concatenado, es decir '[email protected]', dicen que esto da un hash de 7777.
La URL entonces generar tendría entonces el correo electrónico, fecha de solicitud y la nueva almohadilla:
https:\\www.example.com\[email protected]&requestdate=2014-07-17&hash=7777
El servidor combinará el correo electrónico y la fecha suministrada con su sal y hash y confirmar el hash que genera es lo mismo que el suministrado. Si esto está bien, entonces mostrará el formulario de reinicio con los mismos tres parámetros ocultos detrás, de lo contrario un error. Éstos se vuelven a enviar y se vuelven a comprobar cuando se ingresa la nueva contraseña para evitar que se falsifique el formulario.
La dirección de correo electrónico se debe enviar para realizar la solicitud y solo se envía por correo electrónico a la misma dirección. la fecha no es información privilegiada y el hash no es reversible, por lo que no ofrece nada. No se ha escrito nada en la base de datos y cualquier alteración de los parámetros hace que el hash falle y la URL informe un error.
Es una mala práctica incluir datos en el token de restablecimiento de contraseña. Evento si está encriptado Un pirata informático que conoce el algoritmo podrá restablecer la contraseña de cualquier usuario, incluso sin acceso al buzón del usuario. –
-1. La idea es buena en cierto sentido, pero NO debe usarse debido a un problema de seguridad que Slava explicó en un comentario anterior. – Mohayemin
@SlavaNadvorny Un pirata informático también necesitará conocer la clave del algoritmo de encriptación.Puede suponer que si el pirata informático tiene acceso a la clave de cifrado, probablemente también tenga acceso a los valores hash almacenados, por lo que sí, esta técnica todavía parece una buena idea. – Guillaume