Cuando una web te dice que tu contraseña tardaría tres millones de años en romperse, está omitiendo la parte importante de la frase. La pregunta correcta no es cuánto tarda. Es cuánto tarda contra qué.
Y la respuesta a contra qué no la decides tú. La decidió un desarrollador de la tienda donde compraste unas zapatillas en 2019, cuando eligió cómo guardar tu contraseña en su base de datos. Tú escribiste la misma cadena de veinte caracteres en los dos sitios. En uno aguanta siglos, en el otro cae antes de comer.
El número que falta en la ecuación
Un ataque por fuerza bruta es aritmética vulgar: número de candidatos que hay que probar, dividido entre candidatos que puedes probar por segundo. El primer factor depende de tu contraseña —su longitud, su alfabeto, si está o no en un diccionario—. El segundo no tiene absolutamente nada que ver contigo.
El segundo factor depende de dos cosas: el hardware del atacante y, sobre todo, la función con la que el sitio convirtió tu contraseña en el churro que guarda en su tabla de usuarios. Esa función se llama hash, y no todas cuestan lo mismo de calcular.
MD5 y SHA-1 se diseñaron para ser rápidos. Es una virtud: son funciones de hash de propósito general, pensadas para resumir mensajes y verificar integridad, y ahí lo que quieres es procesar un gigabyte sin que te dé tiempo a levantarte a por café. Cuando alguien las usa para guardar contraseñas, esa virtud se convierte en el problema. Una función que puedes calcular millones de veces por segundo es una función que el atacante también puede calcular millones de veces por segundo — y él tiene tarjetas gráficas y todo el fin de semana.
bcrypt y Argon2 se diseñaron con el objetivo contrario. Son lentas a propósito, y —esto es lo elegante— con lentitud regulable. Niels Provos y David Mazières presentaron bcrypt en 1999 con un título que lo dice todo: A Future-Adaptable Password Scheme. La idea era que la función pudiera encarecerse con los años, al ritmo al que se abaratase el hardware. Argon2, que ganó la Password Hashing Competition en 2015, añadió otra vuelta: no solo cuesta tiempo, cuesta memoria, que es justo lo que las GPU tienen a mano con menos alegría.
Entre un hash rápido y un hash lento bien configurado no hay una diferencia de porcentajes. Hay órdenes de magnitud. Muchos.
Los benchmarks existen, y son públicos
Nada de esto es especulación. Hashcat, la herramienta que usa medio mundo para romper contraseñas —los buenos incluidos—, trae un modo de benchmark que cualquiera puede ejecutar en su propia máquina y que mide, algoritmo por algoritmo, cuántas veces por segundo se puede calcular cada uno. La comunidad publica esas tablas cada vez que sale una GPU nueva.
Lo interesante de esas tablas no es ningún número concreto —que además caduca con cada generación de hardware— sino la distancia entre las filas. Ordenas la lista por velocidad y ves MD5 arriba del todo, en su propio planeta. Bajas y bajas, y en el fondo de la tabla están bcrypt y Argon2, con cifras que no se parecen en nada. Es la misma contraseña. Es la misma GPU. Lo único que ha cambiado es cómo decidió guardarla el sitio.
Por eso «3 millones de años» sin decir contra qué hash es marketing, no una medida. Es como anunciar que tu coche tarda seis horas en llegar sin mencionar el destino.
Offline y online: dos mundos que no se tocan
Hay una segunda distinción que casi nadie explica y que cambia el resultado igual de brutalmente.
En un ataque online, el atacante prueba contraseñas contra el formulario de acceso, como haría un usuario. El ritmo no lo pone su hardware: lo pone el servidor. Puede haber límite de intentos, bloqueo temporal, un captcha, retardo entre peticiones, alertas al detectar mil fallos desde la misma dirección. Contra un sitio decentemente defendido, un ataque online es lento, ruidoso y bastante estúpido. La aritmética es tan mala para el atacante que la fuerza bruta pura casi no se intenta: se prueban las cuatro contraseñas de siempre contra millones de cuentas, que es otro juego.
En un ataque offline, el atacante ya tiene el volcado de la base de datos. Se lo lleva a su casa. Ahí no hay servidor, ni límite de intentos, ni nadie mirando: hay sus tarjetas gráficas y su factura de la luz. Puede probar durante meses sin que nadie se entere, y sabrá que ha acertado él solo, comparando hashes. Aquí es donde el hash lo decide todo, porque el hash es literalmente lo único que le frena.
Y conviene ser honesto sobre las probabilidades: el escenario offline no es exótico. Es lo que pasa cada vez que se filtra una base de datos. Cuando LinkedIn perdió la suya en 2012, el análisis del volcado filtrado mostró que guardaba las contraseñas con SHA-1 sin sal: un hash rápido y sin el ingrediente que evita precalcular tablas. Que se rompieran tantas y tan deprisa no fue solo cuestión de que los usuarios eligieran mal. Fue, sobre todo, una decisión de ingeniería que ningún usuario vio nunca.
Lo que hacemos aquí, y por qué lo decimos
Nuestro comprobador asume 10¹² intentos por segundo, offline, contra un hash rápido. Está escrito en la propia página, debajo del resultado, y no por transparencia decorativa: sin ese dato, el tiempo que te muestra no significa nada.
Es deliberadamente el caso malo. Asumimos que la base de datos ya está filtrada, que el atacante tiene hardware serio, que el sitio guardó tu contraseña de la peor manera razonablemente posible y que además conoce tu alfabeto y tu longitud. Si el sitio usó bcrypt bien configurado, la cifra real sube muchos órdenes de magnitud y tu contraseña aguanta muchísimo más de lo que te decimos.
Preferimos equivocarnos por ese lado. Un comprobador que te felicita se está felicitando a sí mismo.
La conclusión incómoda
Tu contraseña no tiene un tiempo de ruptura. Tiene un tiempo de ruptura por cada sitio en el que la hayas usado, y ese tiempo lo fija gente que no conoces con criterios que no publica.
De lo cual se deducen dos cosas, y son las de siempre. La primera: como no puedes controlar el hash, controla la entropía, que es la mitad de la ecuación que sí es tuya —por eso el generador te enseña bits y no un porcentaje simpático—. La segunda, y más importante: si cada sitio tiene su propia contraseña, el que la guardó en MD5 solo puede regalar la de ese sitio.
Porque el eslabón débil no es tu contraseña. Es el peor sitio donde la escribiste.
Fuentes: benchmarks públicos de hashcat (hashcat -b), consultables y reproducibles · N. Provos y D. Mazières, «A Future-Adaptable Password Scheme», USENIX, 1999 · Password Hashing Competition, ganada por Argon2 en 2015 · el modelo de amenaza declarado en el comprobador de password.es: 10¹² intentos/s, offline, hash rápido · brecha de LinkedIn de 2012: la compañía confirmó la filtración, y el uso de SHA-1 sin sal se estableció al analizar el volcado publicado.