Lo que pide hoy una política de contraseñas razonable

La publicación especial SP 800-63B de NIST, en su revisión 4, fija lo que un verificador debe hacer con las contraseñas. Su idea central es que la longitud y el descarte de contraseñas conocidas protegen más que las reglas que fuerzan a la gente a inventar variaciones previsibles. En resumen, con palabras propias:

• Si la contraseña es el único factor, debe tener al menos 15 caracteres; si forma parte de una autenticación de varios factores, basta con 8. El sistema debería aceptar al menos 64 caracteres, espacios y caracteres Unicode.
• No se imponen reglas de composición (mayúscula, número, símbolo) ni cambios periódicos. El cambio se exige cuando hay indicios de que la contraseña se comprometió.
• Cada contraseña nueva o cambiada se compara, entera, con una lista de valores comunes, esperables o filtrados, y si se rechaza se le dice a la persona por qué.
• No se ofrecen pistas visibles para quien aún no se autenticó ni se piden preguntas de conocimiento personal. Se permite el uso de gestores de contraseñas y se debería permitir pegar. Y se verifica la contraseña completa, sin recortarla.

Un gestor de contraseñas genera valores largos y distintos para cada sitio, y los entrega pegándolos o rellenando el campo. Una regla que impide pegar empuja a la persona a elegir algo que pueda teclear de memoria, que suele ser corto y repetido en otros servicios: justo lo contrario de lo que la política quería conseguir.

Abre politica-vigente.txt y busca la regla que choca con el uso de gestores.

Revisar una política no es tachar lo viejo: es separar lo que la guía mantiene de lo que retira o cambia, regla por regla, y tener en cuenta a qué aplicación se aplica cada una. Una regla que vale para el panel con dos factores puede quedarse corta en el portal donde la contraseña es lo único que protege la cuenta, y entonces hay que cambiarla.

Lee el encargo para saber qué factor usa cada aplicación y recorre las diez reglas de politica-vigente.txt con lo que viste en la tarea 1.

Una política puede estar bien escrita y el código hacer otra cosa. Un caso frecuente es el recorte: el formulario limita la longitud y el servidor, «por si acaso», corta lo que sobra antes de derivar el resumen. La persona cree que su frase larga la protege, pero lo que se guarda es solo el principio. La guía pide verificar la contraseña completa.

Abre formulario-registro.txt y lee el código del servidor, no solo la plantilla.

En el informe, cada hallazgo lleva su clasificación. En el portal de clientes la contraseña es el único factor y la política acepta 8 caracteres, la recorta a 16 y obliga a una composición que produce valores previsibles. El defecto no está en cómo se guarda ni en cuántos intentos se permiten, sino en qué contraseñas se dejan elegir.