No, no hay una necesidad abrumadora de hash de tokens de restablecimiento de contraseña, siempre y cuando estén limitados en el tiempo y sean de un solo uso. El hash token de reinicio tiene algún beneficio, pero el beneficio es menor que con las contraseñas, por lo que no consideraría el hash de tokens de reinicio absolutamente necesario.
Normalmente, los tokens de restablecimiento de contraseña tienen un límite de tiempo. Por ejemplo, pueden ser buenos solo por una hora, y expiran después de eso. Además, normalmente los tokens de restablecimiento de contraseña están limitados, por lo que solo se pueden usar una vez, y después de ser usados, se revocan. Esta es una buena práctica, y definitivamente deberías estar haciendo esto.
Si haces esto, no hay ninguna necesidad absoluta de hacer un hash de los tokens para restablecer la contraseña cuando están almacenados en tu base de datos. Recordemos el modelo de amenaza contra el que el hash está diseñado para defenderse: está diseñado para mitigar las infracciones únicas de la base de datos. En otras palabras, asumimos que el adversario encuentra una vulnerabilidad que le permite volcar la base de datos en un solo punto en el tiempo. (Tal vez una vulnerabilidad de inyección SQL, o algo así.) Queremos limitar el daño lo más posible, si esto sucede.
Para las contraseñas, es importante marcarlas. Si no lo hace, suceden dos cosas malas: (i) una sola violación de la base de datos compromete la contraseña de cada usuario, permitiendo que el atacante acceda a la cuenta de cada usuario en su sitio; y (ii) como los usuarios a menudo reutilizan sus contraseñas en otros sitios, esto puede permitirle al atacante acceder a las cuentas de sus usuarios en otros sitios. Si haces hash, una violación de la base de datos sigue siendo mala, pero es mucho menos mala.
Para los tokens de restablecimiento de contraseña, ninguno de ellos es verdadero. Digamos que no hash los tokens para restablecer la contraseña. Luego, una sola violación de la base de datos solo revelará el conjunto de tokens de restablecimiento que están activos en el momento de la violación. Es posible que haya millones de usuarios en su sitio, pero solo unos pocos tokens de reinicio activos en ese momento, por lo que solo unos pocos usuarios tienen sus cuentas expuestas. Eso es mucho, mucho menos serio.
Además, los tokens de restablecimiento de contraseña se eligen al azar, no por el usuario. Como resultado, no se reutilizan en otros sitios y el compromiso de un token de restablecimiento para el sitio x.com no representa ningún riesgo para la cuenta del usuario en otros sitios (por ejemplo, y.com ). Por lo tanto, la segunda razón por la que las contraseñas de usuario de hash no se aplica para restablecer tokens, tampoco.
Vale la pena mencionar que hay un escenario en el que se pueden utilizar tokens de restablecimiento de contraseña no lavados: si el atacante logra obtener acceso de lectura a la base de datos, el atacante puede solicitar un restablecimiento de contraseña para algún usuario ( alice ), lea la base de datos para observar el token de restablecimiento de contraseña de alice , y luego usarlo para cambiar la contraseña de alice y obtener acceso a su cuenta. Sin embargo, hay algunos factores atenuantes aquí. El atacante tiene que hacer esto en tiempo real, por lo que la ventana de tiempo del atacante es limitada. El ataque es altamente ruidoso y detectable, ya que un correo electrónico se envía a alice . Si el atacante intentara tomar el control de muchas cuentas de esta manera, la violación probablemente se notaría muy rápidamente (los usuarios se pondrían en contacto con los administradores del sitio, quienes, con suerte, investigarán). Esto es un impedimento para los atacantes que intentan montar un ataque de este tipo contra muchos usuarios. No detiene un ataque dirigido donde el atacante solo quiere afectar a unos pocos usuarios, pero hace que sea menos probable que un atacante pueda obtener acceso a las cuentas de todos (como sucedería con una contraseña no dañada). Por lo tanto, los tokens de restablecimiento no lavados son menos preocupantes que las contraseñas no lavadas.
No me malinterpretes. Hay algún beneficio para hash de tokens de restablecimiento de contraseña. Sin embargo, también se requiere un poco de esfuerzo para escribir el código para hash los tokens de reinicio. Dado que el beneficio de seguridad es limitado, desde una perspectiva de gestión de riesgos, no sería ridículo decidir almacenar tokens de restablecimiento sin hash.
No estoy diciendo "no hash reset tokens". Si tiene la oportunidad de controlarlos, siga adelante: obtendrá algún beneficio de seguridad. Al mismo tiempo, para poner esto en perspectiva, probablemente esta no sea la característica de seguridad más importante de implementar. Probablemente pueda encontrar muchas otras formas de reforzar la seguridad de su sitio que le ofrezcan mayores beneficios.
Línea inferior: el hash de tokens para restablecer la contraseña tiene algún beneficio, pero es limitado. No lo considero una característica de seguridad imprescindible.