Contraseñas, hashing y sal

Tarde o temprano alguien leerá tu tabla de usuarios: una copia de seguridad olvidada, una inyección SQL, un empleado descontento. La pregunta no es si pasará, sino qué podrá hacer con lo que lea. Si guardaste bien las contraseñas, casi nada.

Codificar, hashear, cifrar: tres cosas distintas

Se confunden constantemente, y cada una sirve para algo diferente:

Codificar

ana:secretoBase64YW5hOnNlY3JldG8=

• ✓ reversible por cualquiera
• ✕ necesita clave
• ✕ protege algo

Cifrar

IBAN del clienteAES-GCM + clave9f3a…c1 (+ tag)

• ✓ reversible con la clave
• ✓ necesita clave
• ✓ para datos que debes recuperar

Hashear

fichero.zipSHA-256e3b0c442…b855

• ✓ irreversible
• ✓ rapidísimo (malo para contraseñas)
• ✓ para integridad

Hash de contraseña

secretobcrypt / Argon2id + sal$2a$10$N9qo8uLO…

• ✓ irreversible
• ✓ lento a propósito
• ✓ sal única por usuario

Solo el hash de contraseñas está diseñado para que adivinar sea caro.

• Codificar (Base64, URL encoding) solo cambia la representación. No es seguridad: la cabecera Authorization: Basic lleva usuario y contraseña en Base64, y por eso solo es aceptable sobre HTTPS.
• Cifrar protege datos que necesitarás recuperar (un número de tarjeta, un token de un tercero). Quien tenga la clave puede descifrar.
• Hashear produce una huella de tamaño fijo que no se puede invertir. Sirve para comprobar integridad y, con un algoritmo especial, para contraseñas.

Idea clave

Las contraseñas no se cifran: se hashean con un algoritmo lento y con sal. Si se pueden descifrar, quien robe la clave las obtiene todas de golpe. Tu aplicación nunca necesita conocer la contraseña original: solo comprobar si la que llega produce el mismo hash.

Por qué un hash normal no sirve

Analogía

La picadora de carne

Nadie “descifra” un hash: el atacante adivina. Prueba contraseñas probables, las pica con la misma máquina y compara. La sal obliga a picar por separado para cada usuario; la lentitud hace que cada intento cueste.

En el mundo realEn tu sistema

De una hamburguesa no reconstruyes la vacaUn hash no se puede invertir

Pero puedes picar mil vacas y comparar hamburguesasAtaque de diccionario: hashear candidatas y comparar

Una especia distinta en cada hamburguesaSal: un valor aleatorio único por usuario

Una picadora que tarda un segundo por kiloHash lento: cada intento cuesta caro

SHA-256 es un excelente hash… para ficheros. Para contraseñas es pésimo porque es rápido: una sola GPU calcula miles de millones de SHA-256 por segundo. Con eso, un diccionario de contraseñas filtradas se prueba entero en segundos.

Y sin sal, el problema empeora:

• Dos usuarios con la misma contraseña tienen el mismo hash: si descubres una, descubres las dos.
• Se pueden usar tablas precalculadas (rainbow tables) que asocian millones de hashes conocidos con su contraseña.

La sal es un valor aleatorio, distinto para cada usuario, que se mezcla con la contraseña antes de hashear y se guarda junto al hash. No es secreta: su trabajo es que cada hash sea único y que nada se pueda precalcular.

Los algoritmos correctos

Los algoritmos de hash de contraseñas son adaptativos: tienen un parámetro de coste que puedes subir a medida que el hardware mejora.

Algoritmo	Por qué	Parámetros mínimos (OWASP)
Argon2id	Usa mucha memoria: caro para GPUs y hardware especializado. Primera opción.	19 MiB de memoria, 2 iteraciones, paralelismo 1
scrypt	También costoso en memoria	N = 2¹⁷, r = 8, p = 1
bcrypt	Probadísimo y disponible en todas partes. Solo usa los primeros 72 bytes de la contraseña.	coste ≥ 10
PBKDF2	Cuando se exige cumplimiento FIPS	600 000 iteraciones con HMAC-SHA-256

La regla práctica: ajusta el coste para que verificar una contraseña tarde entre 100 y 500 ms en tu servidor. Un usuario no lo nota al iniciar sesión; un atacante que quiere probar mil millones de contraseñas, sí.

Anatomía de un hash bcrypt

Todo lo necesario para verificar viaja dentro del propio hash:

1. $2a$versión del algoritmo
3. 10$coste: 2¹⁰ rondas
5. N9qo8uLOickgx2ZMRZoMyesal (22 caracteres)
7. IjZAgcfl7p92ldGxad68LJZdL17lhWyhash (31 caracteres)

En código

En Java no hace falta implementar nada: Spring Security incluye las implementaciones en el módulo spring-security-crypto, que puedes usar incluso sin el resto del framework.

Passwords.java

PasswordEncoder encoder = PasswordEncoderFactories.createDelegatingPasswordEncoder();

String hash = encoder.encode("correct horse battery staple");
// {bcrypt}$2a$10$ZK3x8m4p...   ← el prefijo dice qué algoritmo se usó

boolean ok = encoder.matches("correct horse battery staple", hash); // true
boolean ko = encoder.matches("Tr0ub4dor&3", hash);                  // false

El DelegatingPasswordEncoder guarda el algoritmo como prefijo ({bcrypt}, {argon2}…). Gracias a eso puedes cambiar de algoritmo mañana sin invalidar las contraseñas existentes: las viejas se siguen verificando con el algoritmo antiguo y se pueden re-hashear con el nuevo la próxima vez que el usuario inicie sesión.

Evita

// Rápido, sin sal, y se compara con equals
String hash = sha256(password);
if (hash.equals(user.passwordHash())) {
    login(user);
}

Prefiere

// Lento, con sal, comparación en tiempo constante
if (encoder.matches(password, user.passwordHash())) {
    login(user);
}

Comparar secretos sin filtrar información

Para otros secretos que sí comparas tú (tokens de API, firmas de webhooks), String.equals es peligroso: se detiene en el primer carácter distinto, y midiendo cuánto tarda un atacante puede adivinar el secreto carácter a carácter. Usa una comparación en tiempo constante:

Webhooks.java

static byte[] hmacSha256(byte[] key, byte[] data) throws GeneralSecurityException {
    Mac mac = Mac.getInstance("HmacSHA256");
    mac.init(new SecretKeySpec(key, "HmacSHA256"));
    return mac.doFinal(data);
}

// ...al recibir el webhook:
byte[] expected = hmacSha256(secret, body);
byte[] received = HexFormat.of().parseHex(signatureHeader);

if (!MessageDigest.isEqual(expected, received)) {
    throw new BadCredentialsException("Firma inválida");
}

Políticas de contraseña modernas

Las recomendaciones actuales (NIST SP 800-63B) contradicen muchas costumbres antiguas:

• Longitud antes que complejidad: al menos 15 caracteres si la contraseña es el único factor (8 si hay MFA), y permitir frases largas, espacios y cualquier carácter Unicode.
• Sin reglas de composición obligatorias (“una mayúscula, un número y un símbolo”): producen Password1!.
• Comprobar contra contraseñas filtradas (por ejemplo, la API de Have I Been Pwned por rango de hash, que no envía la contraseña).
• Sin caducidad periódica: cambiar solo cuando hay indicios de compromiso.
• Limitar los intentos de login y permitir gestores de contraseñas (no bloquees el pegado).

Trampa común

'Cifrado' reversible de contraseñas

Si tu aplicación tiene una función “recordar contraseña” que te envía tu contraseña actual por correo, está guardándolas de forma reversible. El flujo correcto es “restablecer”: un enlace de un solo uso, de corta duración, que permite fijar una contraseña nueva.

Mini lab · 15 min

Mide el coste de bcrypt

Marcar como completado

Objetivo: Elegir el coste de bcrypt adecuado para tu máquina y comprobar el papel de la sal.

Con la dependencia org.springframework.security:spring-security-crypto en un proyecto Java cualquiera:

BcryptCost.java

public static void main(String[] args) {
    for (int strength = 8; strength <= 14; strength++) {
        PasswordEncoder encoder = new BCryptPasswordEncoder(strength);
        long start = System.nanoTime();
        String hash = encoder.encode("una frase de paso bastante larga");
        long ms = (System.nanoTime() - start) / 1_000_000;
        System.out.printf("strength=%d  %d ms  %s%n", strength, ms, hash);
    }
}

1. Ejecútalo. ¿Qué pasa con el tiempo cada vez que subes strength en 1?
2. ¿Qué valor eliges para que una verificación tarde unos 250 ms?
3. Ejecuta encode dos veces con la misma contraseña. ¿Los hashes coinciden? Entonces, ¿cómo sabe matches que una contraseña es correcta?

Pista

Fíjate en los caracteres que van justo después de $10$ (o el coste que uses) en cada hash.

Mostrar respuestaOcultar respuesta

1. El tiempo se duplica con cada punto de strength: el coste es exponencial (2^strength rondas). De 10 a 14 el trabajo se multiplica por 16.
2. Depende del hardware; en un portátil moderno suele estar entre 11 y 13. Elige el valor más alto que mantenga el login por debajo de ~500 ms en tu servidor real, no en tu portátil.
3. No coinciden, porque cada encode genera una sal aleatoria nueva (los 22 caracteres tras el coste). matches no necesita compararlos: lee la sal y el coste del propio hash guardado, vuelve a hashear la contraseña recibida con esos mismos parámetros y compara el resultado en tiempo constante.

En resumen

• Codificar no protege; cifrar es reversible con clave; hashear es irreversible.
• Las contraseñas se guardan con un hash lento, con sal única y adaptativo: Argon2id, scrypt, bcrypt o PBKDF2.
• Usa PasswordEncoder (encode y matches); el prefijo {id} permite migrar de algoritmo.
• Compara secretos con MessageDigest.isEqual; prioriza longitud y listas de contraseñas filtradas frente a reglas de composición.