Enlaces de restablecimiento de contraseña: ¿valor aleatorio o mensaje autenticado?

Crear una ficha aleatoria que no contenga absolutamente ninguna información y vincularla en la base de datos con un nombre de usuario y un tiempo de caducidad es, con mucho, la mejor solución.

El cifrado (y el hashing) se utiliza para almacenar y transferir datos que deben enviarse absolutamente. Si hay alguna forma de hacer algo sin tener que enviar esos datos, encriptados o no, que proporcionen la misma funcionalidad y seguridad, debe usar ese método. En otras palabras, el cifrado debe ser un último recurso para proteger los datos.

Estos tokens son equivalentes de contraseña y, como tales, deben cumplir requisitos similares. Pero, por mucho, lo más importante es que no debe ser arbitrariamente adivinable por un adversario. Por lo tanto, debería ser indistinguible de los datos aleatorios.

Cuando codificas cualquier dato, obviamente necesita estar cifrado. Ahora, es probable que esto implique cierto nivel de rodamiento, o al menos armar las primitivas de cifrado usted mismo, lo que probablemente hará mal (consulte: no seas un Dave ).

Por lo tanto, esto significa que su solución más segura y simple es crear un token muy aleatorio, y almacenarlo con hash / sal en la base de datos, así como una identificación para ese token. Únase al ID y al token, y serialícelos en hexadecimal, o Base32 y envíelos al usuario. Cuando el token vuelva a aparecer, use la identificación para tomar el token / salt de la base de datos, y haga un hash del resto del token para ver si coincide.

Debes asegurar varias cosas adicionales sobre los tokens, ya que estarán en los correos electrónicos de las personas.

• Asegúrese de que tengan una entropía lo suficientemente alta como para resistir las conjeturas
• Deben ser lo suficientemente cortos como para codificarse en una URL cómodamente
• Deben caducar después de un lapso de tiempo razonablemente corto, ya que estarán en las bandejas de entrada de correo electrónico de las personas
• Deben ser de un solo uso

Puede codificar el tiempo de caducidad en un token y utilizar un HMAC, pero generalmente el restablecimiento de una contraseña implica visitar una URL específica. Por lo general, para facilitar las cosas al usuario, uno incluye el token en la URL como un campo GET.

Si desea mantener la URL relativamente pequeña y solo está compuesta de caracteres imprimibles, probablemente codifique la marca de tiempo como un número entero y use la configuración de ancho fijo. Esto tiene que especificar el usuario, la caducidad y el MAC. Yo lo llamaría confiable, pero no está exento de algún tipo de esfuerzo de codificación.

Como, de todos modos, debes ingresar a una base de datos para obtener contraseñas y no es necesario pensar en codificar un valor aleatorio de ancho fijo, simplemente seguiría con eso. Si todo lo demás es igual (y creo que es más bien igual), fácil gana. Bonificación adicional: menor uso de la CPU.

Es un tema común. Su escenario # 1 es una optimización de almacenamiento sobre el escenario # 2. En el # 2, debe generar y almacenar un servidor de valores aleatorios. Esto le brinda todo el control que pueda desear, pero requiere una columna adicional en su base de datos, o algo así. El escenario descarga este requisito de almacenamiento del lado del cliente. Dado que no se puede confiar en el cliente, debe agregar al enlace una verificación de integridad, es decir, un MAC ; el cifrado no es necesario porque no hay nada en el enlace de restablecimiento que deba mantener en secreto para el usuario (el usuario ya sabe su nombre y cuando solicitó un restablecimiento de la contraseña), pero desea evitar que un cliente malintencionado cree un falso restablecer enlace, de ahí el MAC.

Por lo tanto, el contenido del token, en el escenario # 1, debe incluir todos los datos que necesita para hacer cumplir su política de restablecimiento de contraseña, pero decidió no almacenar en el servidor; esto significa el nombre de usuario y una marca de tiempo (hora a la que se activó el proceso de restablecimiento de la contraseña o el tiempo de caducidad). Es posible que desee incluir un hash de la contraseña anterior en la entrada del MAC (no necesariamente en el token) si desea evitar que el usuario reutilice el enlace de restablecimiento varias veces.

Calcular y verificar un MAC no requerirá muchos recursos, probablemente un poco menos que generar un token aleatorio y almacenarlo en una base de datos (el acceso a la base de datos será considerablemente más costoso que la criptografía). Sin embargo, lo más probable es que este efecto sea insignificante de todos modos (las bases de datos son rápidas). Una desventaja del escenario # 1 es que necesita mantener una clave secreta en el servidor, compartida entre los front-end (si tiene varios), resistente a los reinicios (así que no solo una clave en la RAM, a menos que esté listo para invalidar todos los enlaces de restablecimiento de contraseña cuando el servidor se reinicia), y, por supuesto, a salvo de los espías.

El token aleatorio (escenario # 2) es probablemente más fácil o, si lo prefiere, es más difícil equivocarse . Lo cual es una razón suficiente para recomendarlo.

Recomiendo este artículo de Troy Hunt: Todo lo que siempre quisiste saber sobre la creación de una función de restablecimiento de contraseña segura

Esto es lo que está diciendo sobre cómo manejar el token de reinicio:

  

Lo que queremos hacer es crear un token único que pueda enviarse en un   correo electrónico como parte de la URL de restablecimiento y luego coincidió con un registro en el   servidor junto con la cuenta del usuario, confirmando así la cuenta de correo electrónico   propietario es de hecho el que intenta restablecer la contraseña. Por ejemplo,   el token puede ser "3ce7854015cd38c862cb9e14a1ae552b" y se almacena en un   tabla junto con el ID del usuario que realiza el restablecimiento y el tiempo   en el que se generó el token (más sobre esto en un momento). Cuando el   El correo electrónico se envía, contiene una URL como   “Restablecer /? Id = 3ce7854015cd38c862cb9e14a1ae552b” y cuando el usuario carga   esto, la página comprueba la existencia del token y por consiguiente   confirma la identidad del usuario y permite que la contraseña sea   cambiado.

También hay una hoja de trucos en la wiki de OWASP: Olvidó la contraseña de la hoja de trucos . No diga si es mejor o no almacenar la información en la base de datos.