Probablemente hayas leído que los sitios web almacenan tu contraseña como un "hash" en lugar de la contraseña real. Entonces, ¿cómo consiguen los atacantes que roban esos hashes convertirlos de nuevo en contraseñas? Una de las respuestas más antiguas e ingeniosas es la rainbow table, y entenderla también explica por qué una pequeña técnica, el salado, la derrota sin hacer ruido.
Qué es una rainbow table
Cuando creas una cuenta, un buen sitio web no almacena tu contraseña real. Almacena un hash: la salida de una función de un solo sentido que transforma la contraseña en una cadena de longitud fija, de una manera que no se puede revertir sin más. Si alguien roba la base de datos, obtiene los hashes, no las contraseñas, y todavía tiene que averiguar qué contraseña produjo cada hash.
Una rainbow table es una forma de hacerlo rápido. Es una consulta masiva y precalculada que enlaza los hashes con las contraseñas que los generaron. El atacante hace el costoso trabajo de hashing por adelantado, lo almacena de forma compacta y luego simplemente consulta cada hash robado. Esa es toda la idea: gastar almacenamiento ahora para ahorrar tiempo despues.
Cómo funciona el ataque
Descifrar un hash por brute force significa calcular el hash de cada intento posible en vivo hasta que uno coincide: correcto, pero lento a gran escala. Las rainbow tables aceleran esto con un ingenioso truco de almacenamiento. En lugar de guardar cada hash, construyen largas cadenas que alternan pasos de hashing y de "reducción" y guardan solo el inicio y el final de cada cadena. Eso mantiene lo bastante pequeña una tabla que de otro modo sería inmanejablemente grande. Para descifrar un hash robado, el atacante reconstruye la cadena correspondiente y recupera la contraseña original.
Por qué el salado las derrota
Aquí viene la parte importante, y la buena noticia. Una rainbow table solo funciona si una contraseña dada siempre produce el mismo hash. La defensa es una sal: un valor único y aleatorio que se añade a cada contraseña antes de calcular su hash. Con sales por usuario, dos personas con la misma contraseña acaban con hashes completamente distintos, y una tabla precalculada no sirve de nada: el atacante necesitaría una rainbow table separada para cada sal posible, lo que no es práctico.
Los sistemas modernos van más allá, combinando sales con funciones de hash deliberadamente lentas como bcrypt, scrypt o Argon2. El hashing lento encarece incluso las conjeturas en vivo, y el salado elimina el atajo de la precomputación. Juntos convierten las rainbow tables en una amenaza sobre todo histórica: peligrosa contra sistemas antiguos o mal construidos que almacenan hashes sin sal, pero neutralizada por cualquiera que hoy haga bien el almacenamiento de contraseñas.
Cómo se compara con otros ataques
Ayuda situar las rainbow tables junto a los ataques con los que suelen confundirse:
- Brute force calcula el hash de cada combinación posible en vivo hasta que una coincide: lento, derrotado por contraseñas largas. Consulta que es un ataque de fuerza bruta.
- Dictionary attack prueba una lista de contraseñas probables en vez de todas las combinaciones: más rápido, derrotado por no usar contraseñas comunes o reutilizadas.
- Credential stuffing reutiliza pares reales de usuario y contraseña filtrados: derrotado por contraseñas únicas. Consulta que es el credential stuffing.
- Rainbow table precalcula el trabajo de hashing y lo consulta: derrotada específicamente por el salado.
Qué significa para ti
No puedes controlar cómo un sitio web almacena sus hashes, y los sitios de confianza ya usan sal y hashes lentos, lo que detiene en seco las rainbow tables. Lo que sí puedes controlar es lo único que limita el daño cuando un sitio se equivoca: una contraseña única y larga en cada cuenta. Si un sitio almacena mal sus hashes y sus contraseñas son descifradas, una contraseña que no usaste en ningún otro lugar no expone nada más allá de esa única cuenta. Un gestor de contraseñas hace que generar y almacenar esas contraseñas únicas sea muy fácil, que es la lección práctica detrás de cada uno de estos ataques.
★ Audit Cure53 2024 · ✓ Plan gratuit · Cross-platform
Blinda tus cuentas → NordPassContraseñas fuertes y únicas · escáner de filtraciones · plan gratis→Preguntas frecuentes
¿Qué es una rainbow table?
Una rainbow table es una tabla grande y precalculada que asigna hashes de contraseñas a las contraseñas que los generaron. Los sitios web almacenan las contraseñas como hashes en lugar de texto plano, de modo que un atacante que roba la base de datos de hashes todavía tiene que averiguar las contraseñas originales. En vez de calcular el hash de cada intento sobre la marcha, una rainbow table hace ese trabajo por adelantado y guarda los resultados de forma compacta, así el atacante puede consultar un hash robado y encontrar rápidamente la contraseña correspondiente. Es un clásico intercambio de tiempo por memoria: mucho almacenamiento por adelantado a cambio de un descifrado rápido despues.
¿Cómo funciona un ataque con rainbow table?
Las contraseñas suelen almacenarse como hashes, transformaciones de un solo sentido que no se pueden revertir sin más. Para descifrarlas, un atacante necesita averiguar qué entrada produce un hash dado. Calcular eso en vivo para miles de millones de intentos es lento, así que las rainbow tables precalculan largas cadenas de pasos de hash y reducción y guardan solo los extremos, lo que mantiene la tabla lo bastante pequeña para ser práctica. Con un hash robado, el atacante reconstruye la cadena correspondiente para recuperar la contraseña original. La pega es que esto solo funciona contra hashes que no fueron salados de forma individual.
¿Cómo se defiende uno contra las rainbow tables?
Con una sal. Una sal es un valor único y aleatorio que se añade a cada contraseña antes de calcular su hash, de modo que dos usuarios con la misma contraseña obtienen hashes completamente distintos. Como una rainbow table se precalcula para entradas sin sal, una sal por usuario la vuelve inútil: el atacante necesitaría una tabla separada para cada sal posible, lo que no es viable. El almacenamiento moderno de contraseñas combina sales por usuario con funciones de hash deliberadamente lentas como bcrypt, scrypt o Argon2, que juntas convierten las rainbow tables en una amenaza mayormente histórica más que actual.
Rainbow table vs brute force vs dictionary attack: ¿cuál es la diferencia?
Las tres intentan recuperar contraseñas a partir de hashes, pero de formas distintas. Un ataque de brute force calcula en vivo el hash de cada combinación posible hasta que una coincide: exhaustivo pero lento. Un dictionary attack prueba una lista de contraseñas probables (palabras comunes y contraseñas filtradas) en vez de cada combinación. Una rainbow table precalcula el trabajo de hashing por adelantado y consulta las respuestas, cambiando almacenamiento por velocidad. El salado derrota específicamente a las rainbow tables, porque rompe la suposición de que la misma contraseña siempre produce el mismo hash.
¿Debería seguir preocupándome por las rainbow tables?
Para tus propias cuentas, de forma indirecta. No puedes controlar cómo un sitio web almacena sus hashes, y los sitios bien gestionados ya usan sal y hashes lentos, lo que neutraliza las rainbow tables. Lo que sí puedes controlar es usar una contraseña única y larga en cada sitio, de modo que aunque un sitio almacene mal sus hashes y sean descifrados, la contraseña expuesta no abra nada más. Un gestor de contraseñas hace que eso sea práctico.
