¿Cómo deberías almacenar las contraseñas de los usuarios?

Las contraseñas deben almacenarse de modo que ni siquiera un atacante que robe toda la base de datos pueda recuperarlas. Ese único requisito descarta el texto plano y descarta el cifrado reversible — si tu servidor puede descifrarlas, también puede hacerlo un atacante que tome tu clave. La respuesta es el hash de contraseñas unidireccional, pero con el tipo de hash correcto.

¿Por qué no un hash rápido como SHA-256?

Los hashes de propósito general están diseñados para ser rápidos, lo cual es exactamente lo contrario de lo que se quiere aquí. Las GPU modernas calculan miles de millones de hashes SHA-256 por segundo, por lo que una base de datos robada de hashes SHA-256 de contraseñas puede descifrarse a escala, especialmente para contraseñas comunes. Quieres una función deliberadamente lenta y exigente en recursos.

Usa una función de hash de contraseñas

• Argon2id — la ganadora moderna del Password Hashing Competition; exigente en memoria, lo que resiste el descifrado por GPU/ASIC, con parámetros ajustables de memoria, tiempo y paralelismo. Preferida para sistemas nuevos.
• bcrypt — probada en batalla, con un factor de coste configurable que aumentas con el tiempo a medida que mejora el hardware. Una opción sólida.
• scrypt / PBKDF2 — aceptables donde las anteriores no estén disponibles (PBKDF2 necesita un alto número de iteraciones y es compatible con FIPS).

Sales (y pimientas)

Una sal es un valor único y aleatorio almacenado junto a cada hash. Garantiza que dos usuarios con la misma contraseña obtengan hashes diferentes, lo que derrota las tablas arcoíris precalculadas e impide que un atacante descifre muchas cuentas de una sola vez. (bcrypt/Argon2 generan e incrustan la sal por ti.) Una pimienta opcional es un secreto añadido a todas las contraseñas y guardado fuera de la base de datos — por ejemplo, en un HSM o en la configuración de la aplicación — de modo que una fuga limitada a la base de datos no sea suficiente.

Ajusta y migra

Configura el factor de coste para que un único hash tarde una fracción significativa de segundo en tu hardware, y auméntalo con el tiempo. Planea volver a aplicar el hash en el siguiente inicio de sesión cuando actualices los parámetros.

Los entrevistadores buscan «hash lento y con sal», nombrar Argon2id o bcrypt, rechazar el cifrado y los hashes rápidos, y explicar por qué importa la sal (tablas arcoíris / contraseñas idénticas).