Obviamente, quiero que los usuarios de mi aplicación cambien sus contraseñas de forma regular (de hecho, algunas de nuestras aplicaciones deben estar aprobadas por UL, y requieren un sistema para hacer cumplir las contraseñas cada 90 días). La forma más sencilla de hacerlo es almacenar la última vez que el usuario cambió su contraseña en su registro. También estoy implementando un indicador que, si se establece, básicamente marca su contraseña como "temporal", lo que obliga al usuario a cambiar su contraseña en su próximo inicio de sesión exitoso.
La pregunta es simple: ¿el almacenamiento de estos datos en texto sin formato (la bandera y / o la fecha) expone una vulnerabilidad?
Veo un vector de ataque principal, y es bastante serio; un atacante que obtuvo derechos de edición en la tabla de usuario podría modificar el campo o la bandera de la fecha, obligando al usuario a cambiar su contraseña a voluntad, posiblemente exponiéndolo a un keylogger instalado en la máquina cliente. Eso requiere múltiples "ins", pero si lo hacen de una manera, pueden hacerlo de otra manera. La información de solo lectura podría proporcionar un vector similar al identificar al siguiente usuario que debe cambiar su contraseña, lo que los convierte en el próximo objetivo para detectar su nueva contraseña.
Ya tengo un sistema para el cifrado de datos de usuario basado en contraseña que confunde otros datos confidenciales en el sistema; La pregunta (que bien podría haber respondido yo mismo) es si incluir estos campos en el blob encriptado. Si lo hago, esto obliga legítimamente a los usuarios a cambiar sus contraseñas más difíciles (es posible que desee forzar a cada usuario a cambiar su contraseña, y algunos otros datos para iniciar, si tuviera que descubrir que el DB se había volcado), pero también evita que un atacante haga lo mismo.