@tinitun @kastwey @modulux @Javichi De hecho por fin el NIST recomienda prácticas con sentido. Ha salido hace poco el nuevo boceto de recomendaciones y para las contraseñas, entre otras cosas dicen...
Que acepten contraseñas de más de 16 caracteres, recomendando por lo menos 64
Que no se impongan reglas de composición por tipos de caracteres
Que no requieran cambios de contraseñas periódicos (pero que fuercen los cambios de contraseñas si se demuestra que están comprometidas)
Que no se usen preguntas de seguridad (por fin, ya era hora, no entiendo como Microsoft siguen haciendo eso)
He hecho un paseo rápido por las recomendaciones y en general me han parecido bastante buenas. Y lo bueno es que, si aparecen en la guía del NIST, las empresas estadounidenses que quieren hacer determinados trabajos de con el gobierno o entidades grandes, tienen que cumplirlas. Y eso va permeando al resto.
Aparte, también te da una excusa para cumplirlo tú en un proyecto. "Lo siento pero estamos usando la guía SP 800-63-4 del Instituto Nacional de Estándares y Tecnología, no puedo hacer que el software te pregunte tu apellido de soltera para recuperar tu contraseña."
@andor @tinitun @kastwey @Javichi Todas ellas reglas racionales. sin embargo, hasta donde yo sé, ENISA continúa recomendando cambios periódicos de claves.
El tema de las preguntas de seguridad es interesante, sobre todo porque aunque no sean un mecanismo muy fiable tampoco tengo muy claro que otros mecanismos de recuperación pueden funcionar bien. Lo de que te manden un correo, vale, pero si es la clave de la cuenta de correo ya tenemos un pequeño gran problema, por ejemplo.
@tinitun @modulux @andor @Javichi No no, no se puede, pero se podría, y creo que molaría mucho. Que los grandes proveedores confiasen en los certificados raíz de autoridades como FNMT, certcat y demás, y que si el usuario introduce su documento de identidad como parte de la configuración del correo, se pudiesen usar esos certificados para iniciar sesión o recuperar la clave.