Hashcat desde cero para analizar hashes de contraseñas

Hashcat es una herramienta de código abierto para auditar la fortaleza de las contraseñas de un sistema a partir de sus hashes. Parte del hecho de que los sistemas seguros no almacenan las contraseñas en texto, sino su hash, que es una huella irreversible calculada con una función matemática de un solo sentido, de modo que del hash no se puede volver directamente a la contraseña. Como no se puede invertir un hash, Hashcat trabaja probando candidatas: calcula el hash de muchas contraseñas posibles y comprueba si alguna coincide con el que está auditando, y si coincide, ha encontrado la contraseña original. Su rasgo distintivo frente a otras herramientas es que aprovecha intensivamente la potencia de la tarjeta gráfica o GPU, que es extraordinariamente eficiente para el cálculo masivo y en paralelo de hashes, lo que le permite probar cantidades enormes de candidatas por segundo. Su propósito legítimo es la auditoría de seguridad: permite a un administrador o a un pentester autorizado descubrir cuáles de las contraseñas de un sistema son débiles, para exigir su cambio, y verificar de paso que el sistema almacena las contraseñas con un algoritmo adecuado. Su valor real es defensivo, no ofensivo.

Hashcat aprovecha la GPU, es decir la tarjeta gráfica, porque el tipo de trabajo que implica auditar hashes encaja perfectamente con lo que las GPU hacen mejor. Una tarjeta gráfica está diseñada para realizar una cantidad enorme de cálculos relativamente simples de forma simultánea y en paralelo, que es exactamente lo que necesita hacer para renderizar gráficos, y calcular hashes de muchas candidatas de contraseña es esa misma clase de tarea repetitiva y paralelizable. Mientras un procesador general o CPU está optimizado para tareas variadas y secuenciales y prueba comparativamente pocas candidatas por segundo, una GPU puede probar órdenes de magnitud más, lo que hace a Hashcat especialmente veloz cuando el hash a auditar fue calculado con un algoritmo rápido. Esta característica tiene una consecuencia directa para la defensa: si la GPU vuelve trivial probar cantidades inmensas de candidatas por segundo contra un hash rápido, entonces la contramedida evidente es almacenar las contraseñas con un algoritmo de hashing deliberadamente lento y diseñado para ese propósito, de modo que aunque la tarjeta gráfica sea muy potente, cada intento individual cueste tanto tiempo que probar suficientes candidatas resulte inviable en la práctica.

La herramienta es perfectamente legal y legítima, pero su uso solo lo es dentro de un marco estricto. Auditar contraseñas ajenas sin autorización es un delito, sin importar la intención, y en este caso hay un agravante particular: para poder auditar los hashes de un sistema hay que tenerlos primero, y obtener los hashes de un sistema ajeno normalmente implica haber accedido a él sin permiso, lo que ya constituye una intrusión ilegal por sí misma. Por eso Hashcat debe usarse exclusivamente sobre los hashes de tus propios sistemas, en entornos de laboratorio y competencias de tipo CTF diseñadas para la práctica, o sobre credenciales que audites con autorización explícita en el marco de una prueba de penetración con alcance definido. El uso legítimo más habitual es el de un administrador que audita las contraseñas de su propia organización para identificar las débiles y exigir su cambio, reforzando la seguridad desde dentro. Esto es coherente con el principio que rige todo el hacking ético: lo que distingue una auditoría de una intrusión no es la herramienta ni el conocimiento, sino la autorización y la intención.

La resistencia depende de dos factores combinados, uno del lado del usuario y otro del lado del sistema. Del lado del usuario, lo esencial es usar contraseñas largas y únicas, idealmente frases de contraseña con varias palabras, porque una contraseña larga y poco común no figura en ningún diccionario de contraseñas filtradas y, por su longitud, vuelve inviable la fuerza bruta incluso aprovechando la velocidad de la GPU, ya que el número de combinaciones crece exponencialmente con cada carácter añadido. Del lado del sistema, lo esencial es almacenar las contraseñas con un algoritmo de hashing fuerte, diseñado específicamente para contraseñas, deliberadamente lento y con sal. Que el algoritmo sea lento es la clave frente a Hashcat, porque neutraliza justamente la ventaja de la GPU: por muy potente que sea la tarjeta gráfica, si cada cálculo de hash cuesta mucho tiempo, probar la cantidad de candidatas necesaria se vuelve prohibitivo. La sal es un valor aleatorio único que se añade a cada contraseña antes de calcular su hash, lo que impide reutilizar cálculos entre distintas cuentas y frustra el uso de tablas de hashes precalculadas. Cuando ambos factores están presentes, ni la GPU más potente logra recuperar nada útil, que es exactamente el objetivo de una buena política de contraseñas.

Hashcat y John the Ripper son las dos herramientas de referencia para auditar contraseñas a partir de sus hashes, y comparten el mismo propósito, la misma lógica de probar candidatas y comprobar si su hash coincide, y exactamente el mismo marco ético y legal de usarse solo sobre hashes propios, en laboratorio o con autorización. La diferencia histórica más citada es el enfoque en el aprovechamiento del hardware: Hashcat se ha destacado por su capacidad de exprimir intensivamente la potencia de las tarjetas gráficas o GPU para el cálculo masivo y paralelo de hashes, lo que lo hace muy veloz, mientras que John the Ripper es especialmente valorado por su versatilidad, su amplio soporte de formatos de hash y su flexibilidad, funcionando bien en distintos entornos. En la práctica, muchos profesionales conocen y usan ambas herramientas según la tarea concreta, el tipo de hash y el hardware disponible, y a menudo son complementarias más que excluyentes. Lo esencial es que ambas responden a la misma necesidad de auditar la fortaleza de las contraseñas, se defienden con las mismas medidas de contraseñas largas y hashing fuerte y lento con sal, y están sujetas al mismo requisito absoluto de autorización.

La sal es un valor aleatorio único que se genera para cada contraseña y se combina con ella antes de calcular su hash, de modo que el hash almacenado no depende solo de la contraseña, sino también de esa sal específica. Su importancia es enorme por dos razones relacionadas. La primera es que impide que dos usuarios que casualmente eligieron la misma contraseña acaben teniendo el mismo hash, ya que cada uno tiene una sal distinta, lo que evita que un atacante que recupera una contraseña la aplique de golpe a todas las cuentas que la compartían. La segunda, y más decisiva frente a herramientas como Hashcat, es que la sal frustra el uso de tablas de hashes precalculadas, que son listas gigantes de contraseñas con sus hashes ya computados de antemano para buscar coincidencias al instante. Como la sal cambia el hash resultante de cada contraseña de forma impredecible, esas tablas precalculadas dejan de servir, y el atacante se ve obligado a recalcular los hashes candidata por candidata para cada cuenta, con su sal correspondiente. Combinada con un algoritmo de hashing deliberadamente lento, la sal multiplica el coste de una auditoría o de un ataque real hasta volverlo inviable. Por eso almacenar contraseñas sin sal se considera un error de seguridad grave.