Porqué obligar a cambiar las contraseñas cada 90 días (o con cualquier otra frecuencia) es una mala idea

Todos lo hemos vivido.

Estamos trabajando en algo que nos pidieron urgente, y un mensaje nos anuncia que nos quedan 10 días para cambiar la clave del email, o del sistema que nos permite entrar a todo en nuestra empresa.

Pronto los 10 días se transforman en cinco, en dos, y ... diablos, se me olvidó cambiar la clave. Ahora tengo que llamar a soporte, tengo que cambiar mi clave, y tengo que hacer un memo para explicar porqué no la cambié en 90 días.

¿De dónde viene la práctica de obligar a cambiar tu password?

En 2003, el NIST publicó la guía SP 800-63 sobre identidad digital. En un anexo, la guía recomendaba forzar a los usuarios a cambiar sus claves con frecuencia; al parecer recomendaba hacerlo regularmente (pero mencionaba "90 días" como ejemplo). Digo "al parecer" porque el documento original ya no existe, incluso si uno lo busca en Wayback Machine.

El autor de la recomendación, William (Bill) Burr, un jefe de proyecto en NIST en los años 2000, dijo en un artículo del Wall Street Journal que quería basar su consejo en datos reales, pero en ese entonces no había. Le pidió a los administradores de NIST que le dejaran ver las claves de los usuarios en la red del NIST, y le dijeron que no. Presionado por el tiempo, y sin datos, se basó fuertemente en un white paper escrito en los años ‘80, y terminó recomendando que los usuarios cambiaran sus claves cada 90 días. La razón: si un atacante está continuamente buscando la clave por fuerza bruta, el password podía ser encontrado en más o menos ese tiempo.

Obligar a cambiar las claves pasó a la historia como una de aquellas normas sobre ciberseguridad escritas en piedra, y seguidas a rajatabla por empresas como Microsoft y muchas otras. Bill Burr dijo en el mismo artículo del Wall Street Journal que se arrepentía de mucho de lo que hizo en esa época, incluyendo la recomendación de forzar el cambio de claves cada 90 días.

En el 2016, Lorrie Cranor, una investigadora en seguridad usable en Carnegie Mellon, se tomó un año sabático para ser Chief Technologist de la Federal Trade Comission (FTC) de EE.UU., una agencia estadounidense que tiene mucha influencia en las normas y estándares que se exige a las empresas en materia de tecnología y ciberseguridad. En la FTC, el departamento de TI también obligaba a sus empleados a cambiar sus claves cada 90 días. Este era uno de los temas que Lorrie había investigado desde el 2004, así que en 2016 escribió una nota donde explica por qué obligar a los usuarios a cambiar sus claves cada 90 días es una mala idea. La FTC cambió la obligación de cambiar las claves, y tres años después, Microsoft también cambió sus recomendaciones sobre passwords por las que había propuesto.

Porqué es una mala idea, y qué recomienda Microsoft hoy

Hay mucha evidencia que sugiere que si se obliga a las personas a cambiar su clave periódicamente, escogen de partida una mala clave porque saben que van a tener que cambiarla (no se esfuerzan en escoger una buena). Cuando la cambian, hay evidencia de que lo hacen de formas predecibles (como agregar un “!” al final); como los atacantes conocen estos patrones, esto les hace más fácil averiguar claves.

Hoy, en 2024, Microsoft les dice a los administradores de Office 365 que “los requisitos de expiración de contraseñas hacen más daño que bien, ya que hacen que los usuarios seleccionen contraseñas predecibles, compuestas de palabras secuenciales y números estrechamente relacionados entre sí. En estos casos, la contraseña siguiente puede predecirse en función de la contraseña anterior” (Microsoft 365 Learn).

Respecto a las políticas de cómo deben ser los passwords, Microsoft recomienda:

• Mantener una longitud mínima de ocho caracteres para los passwords;
• No solicitar requisitos de composición de caracteres. Por ejemplo, *&(^%$;
• No requerir cambios de contraseña obligatorios para cuentas de usuario;
• Prohibir las contraseñas comunes (es decir, aquellas que uno puede encontrar en las listas de “los 100 passwords más comunes” o similares);
• Entrenar a los usuarios para que no reutilicen las contraseñas de su organización en otras cuentas.

Veamos la evidencia

¿Cómo es que Microsoft, indudablemente un gigante de la industria, cambió tanto de parecer? Hay harta evidencia científica sobre porqué lo anterior es cierto. Revisemos tres investigaciones que me parecen relevantes.

Estudio empírico a gran escala en 2010

En el 2010, Zhang y sus colegas presentaron uno de los primeros estudios cuantitativos sobre la efectividad de la expiración de claves a gran escala (primer estudio en la barra derecha). Lo que hicieron fue muy astuto: obtuvieron las claves de más de 10.000 cuentas cerradas (de antiguos alumnos, profesores y empleados) de la Universidad de North Carolina at Chapel Hill (UNC). Por cada cuenta, los investigadores recibieron un conjunto de entre 4 y 15 passwords, pues a cada usuario se le obligaba a cambiar su clave cada 90 días. Recibieron en total 51.141 claves. Las claves no estaban en texto plano, sino en forma de hash. Esto es más o menos lo que ocurre cuando un atacante “se roba la tabla de claves” en un sitio privado o de gobierno: si el sistema almacena sus claves como debería, no obtiene directamente las claves sino su versión “hasheada”.

Breve paréntesis: ¿qué es un hash? En la mayor parte de los sistemas, las claves de los usuarios no se guardan tal como las tipea el usuario porque sería muy peligroso exponer la tabla completa de claves. Para evitarlo, primero se transforma la clave a través de una función que no puede invertirse (una vez transformada, no hay forma de volver atrás). A esta clave transformada se le llama coloquialmente un “hash”. Cuando un usuario escribe su clave por primera vez, se calcula el hash de su clave, y se almacena. Cuando el usuario vuelve una semana después, se le pide su password, se calcula el hash de la clave ingresada, y se compara contra el hash almacenado. Si son iguales, se permite al usuario acceder al sistema.

Los investigadores intentaron crackear todas las claves que pudieron con los mejores algoritmos existentes entonces. El programa demoró varios meses, pero al final logró averiguar alrededor del 60% de las claves. De las más de 10.000 cuentas, los investigadores pudieron crackear al menos una de las claves en poco más de 7.700 cuentas.

Luego, los investigadores se dieron cuenta de los patrones que los usuarios utilizaban para cambiar sus claves, como incrementar un número (password1 por password2), cambiar una letra por un símbolo similar (password por p4$$w0rd), agregar o borrar un caracter (como agregar “!” al final), o cambiar de orden parte de las claves (hola1234 por 1234hola). Usaron esos patrones y un subconjunto de las claves para entrenar un algoritmo para aplicar las transformaciones más probables a un password específico. Luego aplicaron el algoritmo a todo el conjunto de claves.

El resultado: en el 17% de las cuentas que estudiaron, sólo sabiendo una clave de una secuencia les permitía adivinar el siguiente password en cinco intentos o menos. Determinaron que, en promedio, alrededor del 41% de las claves pueden ser averiguadas desde un password antiguo en menos de 3 segundos por cuenta. Concluyen que “la efectividad de hacer expirar las claves es débil”.

Estudio teórico en 2015

Un capítulo de un libro de 2015, por Sonia Chiasson y Paul van Oorschot (segundo estudio en la barra derecha), se pregunta lo siguiente: supongamos que un atacante está intentando averiguar por fuerza bruta la clave de una cuenta, e imaginemos que en algún momento desconocido para el atacante, el dueño de la cuenta cambia la clave. ¿Cómo cambia la probabilidad de que el atacante aun así encuentre la clave? Para calcular la posibilidad teórica, los autores diferencian entre un ataque en línea (online) y uno fuera de línea (offline).

En un ataque online, un atacante prueba claves directamente contra un sistema sin tener acceso a la lista completa de claves; por tanto, puede probar pocas claves por unidad de tiempo o corre el riesgo de ser vetado. En este caso, a través del análisis probabilístico de los casos posibles, llegan a que la probabilidad de éxito del atacante es en promedio de un 63%, y en varios casos puede acercarse al 99%.

En un ataque offline, el atacante obtiene acceso a la lista de hashes de las claves, con lo que puede realizar análisis intensivos sobre esta tabla en muy poco tiempo. Como hoy es posible probar miles de millones de passwords por segundo con las mejores combinaciones de hardware y software (p. ej., Hashcat o John The Ripper), los autores razonan de la siguiente forma: supongamos que el usuario escoge 8 caracteres al azar de un diccionario con 93 símbolos (por ejemplo, 27 letras mayúsculas, 27 minúsculas, 5 vocales acentuadas minúsculas y 5 mayúsculas, 10 números y 19 símbolos), la cantidad de combinaciones posible es 93^8 (que es aprox. 9 * 10^15), y probar esa cantidad de combinaciones tomaría alrededor de 9,2 días. Para evitar que una clave a ese ritmo fuera adivinada, tendríamos que cambiar nuestro password cada 800 milisegundos.

Por tanto, en ambos casos, una política de cambio de claves es inútil, pues no impide que un atacante determinado averigüe una cantidad no menor de claves.

El resultado: obligar a los usuarios a cambiar sus claves no tiene ninguna ventaja práctica. Si llegara a tenerla, es muy pequeña y no se condice con el costo que tienen.

¿Qué piensan las personas de los cambios de clave obligados?

En un estudio en el 2010, Rich Shay y colegas le preguntaron a 470 usuarios de la universidad Carnegie  Mellon qué pensaban de un cambio de políticas de clave reciente en el sistema de autenticación central (SSO) de la universidad (tercer estudio en la barra derecha). Sólo el 30% de los usuarios reportó que había creado un password nuevo cuando los obligaron a cambiar su clave (es decir, el 70% basó su password en algo existente anteriormente), y el 19% de los usuarios tuvo problemas incluso para recordar su clave.

En resumen: cuando obligamos a los usuarios a cambiar su clave, la mayoría cambia un mal password (fácilmente adivinable) por otro mal password.

En una investigación de Hana Habib y sus colegas, presentada en SOUPS 2018 (cuarto estudio en la barra derecha), se hicieron dos encuestas a un total de 695 usuarios para entender qué pensaban sobre los cambios de clave obligados en el lugar de trabajo. Se preguntó también qué técnicas usan las personas para cambiar sus claves cuando tienen que cambiarlas.

82% de los participantes estuvieron de acuerdo o muy de acuerdo en que los cambios de clave frecuentes hacen menos probable que un atacante acceda a sus cuentas; el 66% dijo que sus claves cambiadas tenían más o menos la misma fortaleza que la anterior. De cuatro prácticas presentadas para segurizar claves, hacerlas expirar fue considerada como la menos importante (las otras fueron usar un password complejo, almacenar el password en un lugar seguro, y crear un password que no haya sido usado en otra parte), pero aun así sólo 10 de 260 participantes estuvieron en desacuerdo con tener una política de expiración de claves.

En resumen: cuando tienen que cambiar sus claves, la mayor parte de los usuarios recurren a modificaciones simples y predecibles de sus passwords; y no tienen una opinión negativa de la expiración de passwords porque, en algunos casos, esto es lo que se les ha dicho repetidamente por las áreas TI de sus organizaciones.

En resumen

Cada vez que menciono en las charlas de concienciación del CSIRT que obligar a los usuarios a cambiar sus claves periódicamente es una mala práctica, recibo la siguiente pregunta: ¿qué hacemos aquellas instituciones donde cambiar el password es una obligación porque es considerado una buena práctica?

Entendamos primero qué es una buena práctica: algo que creemos bueno porque a algunas personas le ha resultado bien, pero para lo cual no tenemos evidencia. El problema es ese “le ha resultado bien”, que muchas veces es subjetivo y sin evidencia. Cuando encontramos evidencia científica de que algo no funciona, lo lógico es dejar de hacerlo.

¿Y qué hay de Auditoría Interna?

Las normas de Auditoría Interna de cada institución no están escritas en piedra. Los auditores internos no tienen por qué ser nuestros enemigos. El área o grupo de auditoría interna dentro de una institución es como el grupo de testing en un equipo de ingeniería de software. Por supuesto que es posible tratarlos como “enemigos”, esconderles lo que hemos hecho, o ignorar los resultados de sus pruebas y recomendaciones; pero esto no tiene ningún sentido. Lo único que creo que es realmente útil es entablar una conversación con los auditores y explicarles que lo que técnicamente pudo tener en sentido en 2004, no tiene porqué seguir siendo válido el 2024.