¿Qué problemas tiene este procedimiento de "recuperación de cuenta"?

En general, esto parece razonable para un sitio promedio. Sugeriría algunos cambios menores:

• Personalmente, consideraría eliminar la pregunta secreta. No creo que las preguntas de seguridad agreguen mucha seguridad; pero son otro secreto que el usuario puede olvidar o equivocarse, por lo que las preguntas de seguridad tienen un costo real para la experiencia del usuario. Se han realizado investigaciones académicas que sugieren que las respuestas a las preguntas secretas tienen poca entropía y que pueden ser objeto de fraude tan fácilmente como las contraseñas. Por lo tanto, creo que eliminar la pregunta secreta mejorará la usabilidad y no tendrá mucho efecto en la seguridad. En efecto, la seguridad del sistema depende de la dirección de correo electrónico del usuario. El principal riesgo de que se dirija la pregunta secreta es cuando el usuario cierra su cuenta de correo electrónico, y luego alguien más registra el mismo correo electrónico y puede adivinar el nombre de usuario del usuario; o donde la cuenta de correo electrónico del usuario es secuestrada; o donde el usuario comparte su cuenta de correo electrónico con otras personas.

• Yo agregaría un indicador de seguridad de contraseña a la página donde el usuario elige su contraseña. Vea qué sitios como Google usa, donde hay una barra que indica dinámicamente la fortaleza de la contraseña y que cambia de color (rojo = pobre, amarillo = borde, verde = bueno). Esto podría inducir / ayudar a los usuarios a elegir mejores contraseñas. Probablemente no necesite imponer requisitos mínimos de resistencia, esto puede proporcionar suficiente empujón.

• Haría que el código de recuperación fuera limitado en el tiempo, de modo que deba usarse dentro de (digamos) una hora o dos, y luego ya no se acepte después del final del período de validez. Además, el enlace debe expirar inmediatamente en el primer uso (gracias, @AviD, por señalarlo).

• Use SSL / TLS (es decir, HTTPS) para toda la actividad relacionada con la selección / configuración / envío de la contraseña del usuario. Esto protegerá contra la escucha de contraseñas para los usuarios que acceden a su sitio a través de una red inalámbrica abierta; Sin embargo, no protege contra Firesheep. Considere adoptar SSL / TLS en todo el sitio, que protegerá contra Firesheep.

(Supongo que no tiene ninguna necesidad de seguridad especialmente sensible: por ejemplo, esto no es para banca en línea o similar).

Como de costumbre, depende de la naturaleza de lo que estás protegiendo. Parece bastante decente para información básica. Puede necesitar más si está escribiendo código para algo de alto nivel, como la banca por Internet.

Cada vez que se usan preguntas / respuestas secretas, la respuesta toma el lugar de una contraseña en algún lugar, y es fácil que sea su enlace más débil. Dado que las respuestas secretas pueden ser fácilmente cosas que un atacante podría descubrir al buscar en Google a la persona, puede ser un factor de riesgo real, y es difícil pisar la línea de preguntas que son tan inusuales que no son relativamente fáciles de entender y las preguntas. que son tan esotéricos o no aplicables que el propietario de la cuenta no puede responderlos.

Me gusta la idea de @ Iszi de dejar que la persona escriba sus propias preguntas y respuestas, un conjunto, que evita el problema muy bien.

En el caso de que mencione si un atacante puede interceptar el correo electrónico proveniente de su sistema, entonces no necesita la cuenta del usuario. Eso significa que la mayor línea de defensa es ese secreto compartido.

No lo dijo, pero supongo que toda la configuración de la cuenta y el restablecimiento de la contraseña se realizan con la protección SSL / TLS, ¿verdad? Si no, ese sería probablemente el problema más grande.