Hash vs cifrado: cómo se almacenan contraseñas de forma segura (sal, bcrypt y Argon2)

Hash y cifrado: definición práctica

Cifrado significa que puedes recuperar el texto original si tienes la clave (AES, RSA, etc.). Se usa cuando necesitas guardar o transmitir información y luego leerla: por ejemplo, datos sensibles en reposo.

Hash significa que transformas un valor en una huella unidireccional. No hay “deshash”. Esto es ideal cuando lo que quieres es comparar sin guardar el original. Por eso, las contraseñas se almacenan como hash: el servidor no necesita saber tu contraseña, sólo validar que la ingresada coincide.

Si quieres una introducción general al tema, complementa con Qué es un hash y para qué sirve.

Por qué NO debes guardar contraseñas con MD5 o SHA1

Hay dos razones enormes:

• Son demasiado rápidos: un atacante puede probar miles de millones de contraseñas por segundo con GPUs.
• Existen tablas rainbow y diccionarios masivos: hashes de contraseñas comunes ya están precomputados.

Aunque usaras SHA256 en lugar de MD5, el problema de “ser rápido” sigue. Para contraseñas necesitas algo intencionalmente lento.

Qué es la “sal” y por qué importa

La sal (salt) es un valor aleatorio que se mezcla con la contraseña antes de hashearla. El objetivo no es “hacerla más secreta”, sino evitar que dos usuarios con la misma contraseña tengan el mismo hash, y romper la ventaja de las tablas precomputadas.

Sin sal:

hash = SHA256(password)

Con sal:

hash = SHA256(salt + password)

En sistemas modernos, la sal se guarda junto al hash (no es un secreto). Lo importante es que sea única por usuario.

Entonces… ¿cómo se hace bien hoy?

Para contraseñas, la recomendación es usar funciones de derivación de clave diseñadas para resistir ataques con hardware: bcrypt, scrypt o Argon2 (muy recomendado actualmente).

• bcrypt: probado en producción durante años, fácil de usar y con “cost” configurable.
• Argon2: ganador del Password Hashing Competition, permite ajustar memoria y tiempo.

Ejemplo mental: por qué “lento” es bueno

Si un hash tarda 0,2 ms, un atacante puede probar millones por segundo. Si tarda 200 ms, sólo puede probar 5 por segundo (por núcleo). El objetivo es que atacar sea caro, no imposible.

“Pero yo uso SHA512, ¿no es suficiente?”

No para contraseñas. SHA512 produce un digest más largo, pero sigue siendo rápido y optimizable en GPU. El tamaño no es el problema: el problema es el costo computacional y (en Argon2) el costo en memoria.

Cómo validar contraseñas sin guardar el original

El flujo típico es:

1. Al registrarse, generas una sal y guardas hash(password, salt, params).
2. Al iniciar sesión, recalculas el hash con la contraseña ingresada y comparas.
3. Si coincide, autenticas. Si no coincide, rechazas.

Errores comunes (y peligrosos)

• Guardar contraseñas en texto plano “temporalmente”.
• Usar MD5/SHA1 “porque es fácil”.
• Usar SHA256 sin sal.
• Reutilizar la misma sal para todos los usuarios.
• Comparar hashes con funciones no seguras (timing attacks) en ciertos entornos.

¿Dónde entra nuestro generador de hash?

El Generador de Hash es útil para tareas de desarrollo: comparar valores, depurar APIs, crear checksums de texto y entender cómo cambia un digest. No es un reemplazo de bcrypt/Argon2 para contraseñas reales, pero sí una herramienta didáctica y práctica para el día a día.

Cómo explicarlo en una frase (para tu equipo)

“Hash para comparar sin reversibilidad; cifrado cuando necesitas recuperar el dato; y contraseñas siempre con un algoritmo de password hashing (bcrypt/Argon2), no con MD5/SHA.”

Lecturas recomendadas

• Qué es un hash y para qué sirve
• Verificar checksum SHA256 de un archivo
• Checksums y firmas en DevOps

Sal, “pepper” y parámetros: tres piezas distintas

Además de la sal (salt), a veces se habla de pepper: un secreto global (como una clave) que se almacena fuera de la base de datos (por ejemplo en variables de entorno). La idea es que, si la base se filtra, el atacante no tenga todos los ingredientes. No siempre es necesario, pero puede sumar defensa en profundidad.

La tercera pieza son los parámetros del algoritmo: el “cost” en bcrypt o los parámetros de tiempo/memoria en Argon2. Esos valores definen cuán caro es calcular el hash y, por lo tanto, cuán caro es atacarlo.

Diccionarios, fuerza bruta y tablas rainbow

Cuando se filtra una base de datos de usuarios, el ataque típico es offline: el atacante puede probar contraseñas localmente sin límite de intentos. Por eso medidas como “bloquear tras 5 intentos” no ayudan en este escenario.

• Ataque de diccionario: probar listas de contraseñas comunes (y variantes).
• Fuerza bruta: probar combinaciones sistemáticas.
• Tablas rainbow: hashes precomputados para contraseñas frecuentes, especialmente cuando no hay sal.

La sal rompe el valor de las tablas precomputadas. El algoritmo lento (bcrypt/Argon2) encarece diccionarios y fuerza bruta. Por eso ambos son necesarios.

¿Qué pasa si dos usuarios tienen la misma contraseña?

Con sal única por usuario, aunque dos personas elijan “Password123”, sus hashes serán distintos. Eso evita que un atacante detecte contraseñas repetidas y reduce el impacto de listas precomputadas.

Ejemplo en PHP: password_hash y password_verify

En PHP moderno, la forma correcta suele ser usar las funciones nativas:

// Al registrar
$hash = password_hash($password, PASSWORD_ARGON2ID);

// Al iniciar sesión
if (password_verify($passwordIngresada, $hash)) {
  // OK
}

Estas funciones gestionan sal y formato de almacenamiento por ti. Además permiten migrar parámetros en el tiempo: si subes el “cost” o cambias de algoritmo, puedes rehashear al próximo login.

¿Y para qué sirve SHA256 entonces?

SHA256 es excelente para integridad, checksums y firmas en muchos flujos, pero no para password hashing. Por ejemplo:

• Comparar si dos archivos son idénticos: checksum SHA256.
• Depurar integraciones: calcular digest de un payload o token.
• Identificadores estables: huellas de contenido para cachés o deduplicación.

Para estos casos de texto, el generador online te ahorra tiempo.

HMAC: cuando necesitas autenticidad con un secreto

En APIs es común ver algo como “HMAC-SHA256”. Un HMAC no es sólo un hash: es un hash combinado con un secreto, diseñado para que el servidor detecte manipulación y autenticidad de un mensaje. No es lo mismo que hashear una contraseña; se usa para firmar mensajes, no para almacenarlos.

Si estás depurando una firma, primero confirma la concatenación exacta y luego compara el digest. Nuestro generador de hash te sirve para validar la parte de hashing, aunque para HMAC completo necesitarías la clave y el método específico.

Política de contraseñas y hashing: cada cosa en su lugar

Un buen hashing no reemplaza buenas contraseñas, pero tampoco una “política estricta” reemplaza el hashing. Son capas distintas:

• Política: longitud mínima, bloqueo por intentos, MFA, prevención de contraseñas filtradas.
• Almacenamiento: Argon2/bcrypt + parámetros adecuados + sal única.
• Operación: rotación de secretos, backups seguros, monitoreo y respuesta a incidentes.

Preguntas frecuentes

¿Puedo “desencriptar” un hash si el usuario olvidó la contraseña?

No. Lo correcto es un flujo de reset: generas un token temporal y de un solo uso, y el usuario define una nueva contraseña.

¿Es malo guardar la sal en la base de datos?

No. La sal no es un secreto. Se guarda junto al hash. Lo que sí debe ser secreto son claves (como un pepper o claves de cifrado).

¿Qué algoritmo debería elegir hoy?

Si puedes, Argon2id. Si necesitas compatibilidad amplia, bcrypt. Ajusta los parámetros para que el hashing tarde lo suficiente sin afectar la experiencia de usuario (por ejemplo 100–300 ms en tu servidor).

Para entender mejor qué es un hash en general (y por qué MD5/SHA1 quedaron atrás), vuelve a la guía básica.

Migrar un sistema legado con MD5/SHA1

Si heredas una aplicación antigua que guarda MD5 o SHA1, lo ideal es migrar sin forzar a todos a resetear el mismo día. Un patrón típico es:

1. Dejas el hash antiguo para validación de logins existentes.
2. Cuando el usuario inicia sesión correctamente, rehasheas la contraseña con Argon2/bcrypt y guardas el nuevo formato.
3. Tras un periodo, obligas reset a quienes no migraron (o al primer login).

Esto minimiza fricción y te permite elevar el nivel de seguridad progresivamente.

Evita el “doble hashing” sin sentido

A veces se ve SHA256(password) y luego ese resultado se pasa a bcrypt. Eso no aporta seguridad real y puede generar errores. Si vas a usar bcrypt/Argon2, úsalo directamente sobre la contraseña (tal cual) y deja que el algoritmo gestione sal y formato.

Tip de depuración: reconocer hashes por longitud

En logs o bases heredadas, la longitud del digest en hex da pistas: 32 (MD5), 40 (SHA1), 64 (SHA256), 128 (SHA512). Si necesitas comprobar rápidamente un digest de texto, prueba con Generador de Hash (MD5, SHA1, SHA256, SHA512).