Está decidiendo cómo almacenar las contraseñas de los usuarios. ¿Cuál es el enfoque correcto?

Almacenar contraseñas es un problema con respuesta establecida, y los entrevistadores lo plantean para ver si recurre a la primitiva creada para ello o a una que simplemente suena criptográfica. La elección correcta es un hash de contraseña lento, salado y con alto coste de memoria: Argon2 (variante id), bcrypt o scrypt.

Por qué lento-y-salado es la herramienta correcta

Estas funciones están diseñadas para el almacenamiento de credenciales. Son deliberadamente costosas de calcular (factor de coste / coste de memoria ajustable), de modo que un atacante que roba la base de hashes solo puede probar conjeturas lentamente — convirtiendo un crackeo por GPU de miles de millones por segundo en un arrastre de miles por segundo. Un salt único por usuario garantiza que contraseñas idénticas produzcan hashes distintos, lo que derrota las rainbow tables precalculadas e impide que un atacante crackee muchas cuentas a la vez. La dureza de memoria de Argon2 mitiga aún más los ataques por GPU y ASIC.

Por qué falla cada alternativa

• SHA-256 es un hash rápido y de propósito general — exactamente la propiedad equivocada aquí. El hardware moderno calcula miles de millones de hashes SHA-256 por segundo, así que los hashes robados caen rápido, y los que no llevan salt caen al instante ante las rainbow tables.
• Cifrar las contraseñas con AES las hace reversibles: el servidor debe guardar la clave, así que una sola compromisión de clave (o un infiltrado malicioso) expone todas las contraseñas en texto plano. Además, nunca necesita recuperar la contraseña original — solo verificarla — por lo que la reversibilidad es puro inconveniente.
• Texto plano «pero blindando la base de datos» es indefendible. Una sola fuga de backup, inyección SQL o réplica mal configurada y todas las credenciales se pierden. Las ACL de base de datos no sustituyen el hecho de no almacenar el secreto.

Qué añade una buena respuesta

Nombre Argon2id (o bcrypt) con un coste ajustado y un salt por usuario; mencione un pepper opcional (una clave secreta guardada fuera de la base de datos) como defensa en profundidad; y señale que re-hashearía en el login para migrar datos heredados de hash rápido y elevaría el factor de coste con el tiempo, a medida que mejora el hardware.