Muchas reglas habituales sobre contraseñas dificultan el uso sin frenar los ataques actuales. Conozca qué controles respaldan las recomendaciones vigentes de NIST, NCSC y Microsoft.
Las políticas de contraseñas suelen tratarse como una lista de requisitos: exigir una letra mayúscula, un número, un símbolo y un cambio cada 60 o 90 días. Esas reglas son visibles y fáciles de auditar, pero que sean visibles no significa que sean eficaces. Los atacantes aprovechan las elecciones humanas predecibles, las credenciales reutilizadas, los procesos de recuperación débiles y las bases de datos de contraseñas mal protegidas.
Una política útil debe reducir esos riesgos concretos sin dificultar tanto el uso que las personas busquen formas de eludirla.
Longitud mínima
La longitud amplía el espacio de búsqueda, pero solo cuando la contraseña no es una frase común ni un patrón predecible. Las recomendaciones vigentes de NIST exigen al menos 15 caracteres cuando la contraseña es el único factor de autenticación y permiten un mínimo inferior, de ocho caracteres, cuando se utiliza como parte de la autenticación multifactor. Los sistemas deben admitir al menos 64 caracteres para que los gestores de contraseñas y las frases de contraseña funcionen correctamente.
La longitud es un requisito básico, no una prueba de seguridad. Hace falta una lista de bloqueo de contraseñas comprometidas, porque una contraseña larga que los atacantes ya conocen sigue siendo insegura.
Caducidad periódica de las contraseñas
Obligar a cambiar las contraseñas a intervalos fijos suele dar lugar a modificaciones pequeñas y predecibles. También impone una carga a todos los usuarios sin que haya pruebas de que todas las contraseñas hayan quedado expuestas. NIST, el NCSC del Reino Unido y Microsoft desaconsejan la caducidad periódica. En su lugar, una contraseña debe cambiarse cuando haya pruebas o una sospecha razonable de que se ha visto comprometida, cuando se descubra que se ha almacenado de forma vulnerable o cuando un proceso de recuperación de la cuenta lo requiera.
Las organizaciones siguen necesitando capacidad para detectar problemas y restablecer contraseñas con rapidez. Eliminar los cambios periódicos no significa conservar una contraseña que se sabe que está comprometida.
Reglas de composición
Las reglas que obligan a incluir mayúsculas, minúsculas, números y símbolos fomentan patrones como una primera letra mayúscula y un dígito o símbolo al final. Las herramientas de ataque ya tienen en cuenta esas sustituciones. Los servicios deben permitir espacios y una amplia variedad de caracteres, evitar reglas de composición arbitrarias y comparar la contraseña propuesta en su totalidad con contraseñas comunes y comprometidas.
Bloquear los signos de puntuación porque podrían utilizarse en una inyección SQL o en ataques de secuencias de comandos entre sitios es una señal de alerta. El código de la aplicación debe utilizar consultas parametrizadas a la base de datos y un tratamiento seguro de la salida. Restringir la contraseña de un usuario no sustituye la corrección de las vulnerabilidades de inyección.
Reutilización de contraseñas y credenciales filtradas
La reutilización es uno de los riesgos con mayores consecuencias, porque una filtración en un proveedor puede dar acceso a cuentas de otro. Una política debe exigir una contraseña única para el servicio, admitir gestores de contraseñas y comprobar las contraseñas propuestas frente a valores que se sabe que están comprometidos mediante un método que preserve la privacidad. Las organizaciones también deben vigilar los patrones de ataques de relleno de credenciales y los comportamientos inusuales de inicio de sesión.
El historial de contraseñas puede impedir que se reutilice exactamente la misma contraseña dentro de un servicio, pero los historiales muy extensos pueden fomentar cambios superficiales. No permite detectar la reutilización en proveedores ajenos y no debe considerarse la defensa principal.
Almacenamiento seguro de contraseñas
Las contraseñas solo deben transmitirse al servicio a través de una conexión TLS protegida y nunca deben guardarse en los registros. En el servidor, cada contraseña debe procesarse con una sal aleatoria única y una función lenta de hash de contraseñas diseñada para ese fin. OWASP suele recomendar Argon2id; scrypt, bcrypt o PBKDF2 pueden ser adecuados bajo determinadas restricciones. Los factores de trabajo deben revisarse periódicamente a medida que mejora el hardware.
Un pepper almacenado fuera de la base de datos de contraseñas puede añadir otra capa de protección, pero conlleva responsabilidades de gestión y rotación de claves. No sustituye a una sal ni a una función robusta de hash de contraseñas. Las funciones hash rápidas de propósito general, como MD5 y SHA-1/SHA-2 usados directamente, no son adecuadas por sí solas para almacenar contraseñas.
Qué incluye una política eficaz
Una longitud mínima acorde con el riesgo y compatibilidad con contraseñas largas.
El bloqueo de contraseñas comunes, previsibles y que se sabe que están comprometidas.
Compatibilidad con gestores de contraseñas, pegado y autocompletado.
Hash de contraseñas con una sal única, una función lenta y factores de trabajo revisados.
Limitación de la frecuencia de intentos en varias capas y detección de intentos de adivinación, ataques de rociado de contraseñas y relleno de credenciales.
MFA resistente al phishing o claves de acceso, especialmente para cuentas privilegiadas y sensibles.
Recuperación segura, sustitución de autenticadores, revocación de sesiones y restablecimientos cuando las contraseñas se vean comprometidas.
