# Hashcat desde cero para analizar hashes de contraseñas

**Categoría:** Hacking ético · **Nivel:** Intermedio · **Lectura:** 11 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/hacking/hashcat-desde-cero-para-analizar-hashes-de-contrasenas/

## Respuesta rápida

**Hashcat** es una herramienta de código abierto para **analizar la fortaleza de las contraseñas** a partir de sus **hashes** —la huella irreversible con la que los sistemas seguros almacenan las contraseñas en lugar del texto—. Como del hash no se puede volver directamente a la contraseña, Hashcat **prueba candidatas**: calcula el hash de muchas contraseñas posibles y comprueba si alguna coincide. Su rasgo distintivo es que aprovecha la **GPU** (la tarjeta gráfica), extraordinariamente eficiente para el cálculo **masivo y en paralelo** de hashes, lo que le permite probar cantidades enormes por segundo. Su valor legítimo es la **auditoría**: un administrador o un [pentester autorizado](../fundamentos-hacking-etico/index.md) comprueba cuáles de las contraseñas de *su* sistema son débiles para exigir su cambio, y verifica que el algoritmo de almacenamiento es adecuado. El marco es absoluto: solo sobre **hashes propios**, en **laboratorio**, o con **autorización explícita**; auditar credenciales ajenas es un **delito**. Y la lección defensiva: dos medidas vuelven la auditoría **infructuosa** —[contraseñas largas y únicas](../como-crear-y-administrar-contrasenas-seguras/index.md) (que ningún diccionario contiene) y un **algoritmo de hashing lento y con sal** (que hace que ni la GPU pueda probar suficientes candidatas)—. Es prima de [John the Ripper](../john-the-ripper-para-auditorias-de-contrasenas/index.md): mismo propósito, misma defensa, mismo marco.

## Qué es

**Hashcat** es una de las dos herramientas más conocidas para **auditar contraseñas** a partir de sus **hashes** —la otra es [John the Ripper](../john-the-ripper-para-auditorias-de-contrasenas/index.md)—. Parte del mismo principio: un sistema bien hecho **no guarda las contraseñas en texto**, sino su hash, una huella calculada con una función de un solo sentido que *no se puede invertir*. Para evaluar la fortaleza de una contraseña, Hashcat **prueba candidatas**: calcula el hash de cada una y ve si coincide con el que audita.

> **Auditar, no «romper»**
>
> Aunque coloquialmente se hable de «crackear» contraseñas, en un contexto legítimo Hashcat hace **auditoría**: revela cuáles de las contraseñas de *tu* sistema no resistirían un ataque real, para poder **reforzarlas**. Si recupera una rápido, era débil; si no lo logra, era fuerte. Ese resultado es información de seguridad accionable, no un fin en sí mismo.

## Por qué la GPU

Lo que distingue a Hashcat es que aprovecha la **GPU**, la tarjeta gráfica. Una GPU está diseñada para hacer **muchísimos cálculos simples en paralelo** —para eso renderiza gráficos—, y calcular hashes es exactamente ese tipo de tarea. Mientras un procesador general (CPU) prueba relativamente pocas candidatas por segundo, una GPU puede probar **órdenes de magnitud más**. Por eso Hashcat es tan veloz auditando hashes calculados con algoritmos **rápidos**.

> **Atención**
>
> Si la GPU vuelve trivial probar miles de millones de candidatas por segundo contra un hash **rápido**, la defensa evidente es usar un hash **deliberadamente lento** y diseñado para contraseñas: aunque la GPU sea potente, cada intento cuesta tanto tiempo que probar suficientes candidatas se vuelve **inviable**. La velocidad de Hashcat es, precisamente, el argumento a favor de los algoritmos de hashing lentos.

## Cómo audita, a alto nivel

Como toda herramienta de este tipo, Hashcat genera candidatas de dos formas principales:

- **Ataque de diccionario.** Prueba listas de **contraseñas comunes** y filtradas de brechas. Es el método más eficaz, porque las contraseñas débiles suelen estar en esas listas.
- **Fuerza bruta.** Prueba combinaciones sistemáticamente; solo viable para contraseñas **cortas**, aun con la velocidad de la GPU.

Esta guía es **conceptual**: explica el funcionamiento para entender la defensa, no ofrece recetas de ataque.

## El marco legal

> **Atención**
>
> Auditar contraseñas **ajenas sin permiso** es un **delito**. Además, para auditar los hashes de un sistema hay que *tenerlos*, y obtener los de un sistema ajeno suele implicar un acceso no autorizado, que ya es delito en sí mismo. Hashcat solo se usa sobre hashes de **tus sistemas**, en **laboratorios** y CTF, o con **autorización explícita** en una prueba con alcance definido. Como en todo el [hacking ético](../fundamentos-hacking-etico/index.md), la diferencia entre auditoría e intrusión es el permiso.

## Las defensas que la anulan

Entender Hashcat es entender qué vuelve resistente a una contraseña. Dos medidas combinadas hacen que la auditoría **no encuentre nada**:

- **Contraseñas largas y únicas** (usuario). Una [frase de contraseña](../como-crear-y-administrar-contrasenas-seguras/index.md) larga no está en ningún diccionario y, por su longitud, hace inviable la fuerza bruta aun con GPU.
- **Hashing fuerte, lento y con «sal»** (sistema). Un algoritmo diseñado para contraseñas y **lento** neutraliza la ventaja de la GPU, porque cada intento cuesta demasiado tiempo. La **sal** —valor aleatorio único por contraseña— impide reutilizar cálculos entre cuentas y frustra las tablas precalculadas.

Contra un sistema con hashing lento y usuarios con contraseñas largas, ni la GPU más potente logra recuperar nada útil.

## Errores frecuentes

- **Auditar credenciales ajenas sin permiso.** Delito; solo hashes propios, laboratorio o con autorización.
- **Almacenar contraseñas con un hash rápido.** La GPU las recupera en masa; usar un algoritmo lento diseñado para contraseñas.
- **No usar sal.** Permite tablas precalculadas y reutilizar cálculos entre cuentas.
- **Permitir contraseñas cortas o comunes.** Caen en diccionario o fuerza bruta.
- **Creer que un hash «rápido y seguro» basta.** Para contraseñas se necesita justo lo contrario: lentitud deliberada.
- **No actuar sobre los resultados.** Detectar débiles y no forzar su cambio deja el riesgo.
- **Practicar con datos reales de personas.** Usar conjuntos de ejemplo o entornos de CTF.

## Preguntas frecuentes

**¿Qué es Hashcat y para qué sirve?**
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.

**¿Por qué Hashcat usa la tarjeta gráfica?**
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.

**¿Es legal usar Hashcat?**
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.

**¿Cómo hago que mis contraseñas resistan a Hashcat?**
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.

**¿En qué se diferencia de John the Ripper?**
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.

**¿Qué es la «sal» y por qué importa tanto?**
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.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Sección Hacking](https://underc0de.org/foro/hacking/). Auditoría de hashes y contraseñas.
2. **Underc0de, foro.** [Sección Bugs y exploits](https://underc0de.org/foro/bugs-y-exploits/). Análisis de credenciales en laboratorios.

### Documentación oficial

1. **Hashcat.** [Proyecto oficial](https://hashcat.net/hashcat/). La herramienta descrita en la guía.
2. **OWASP.** [Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html). Cómo almacenar contraseñas con seguridad.
3. **NIST.** [SP 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html). Directrices de autenticación.
4. **OWASP.** [Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/). Metodología de pruebas autorizadas.

## Guías relacionadas

- [John the Ripper](../john-the-ripper-para-auditorias-de-contrasenas/index.md)
- [Contraseñas seguras](../como-crear-y-administrar-contrasenas-seguras/index.md)
- [Fundamentos del hacking ético](../fundamentos-hacking-etico/index.md)
- [Passkeys y Zero Trust](../passkeys-autenticacion-sin-contrasena-y-zero-trust/index.md)
- [Índice de Hacking ético](../index.md)