En el ecosistema hispanohablante, Django es uno de los frameworks más usados para nuevos backends, y desde hace varias versiones incluye Argon2PasswordHasher como opción de primera clase junto a PBKDF2. Lo mismo ocurre con Laravel: su Hash facade soporta Argon2id de forma nativa. Esa disponibilidad "de fábrica" es la razón práctica por la que Argon2 se ha vuelto la opción por defecto para proyectos nuevos en la región, más que una imposición regulatoria concreta.
Por qué la memoria importa tanto como el tiempo
Bcrypt y PBKDF2 solo hacen más lento el cómputo. Argon2 obliga además a reservar una cantidad configurable de memoria RAM por cada intento de hash — es lo que se llama una función memory-hard. Una granja de GPUs alquilada en la nube paraleliza cálculos simples de forma barata, pero paralelizar el acceso simultáneo a mucha memoria es mucho más caro: la memoria, a diferencia de los núcleos de cómputo, tiene un límite físico estricto por tarjeta.
Tres variantes: d, i, id
- Argon2d — el acceso a memoria depende de la contraseña, lo que da la máxima resistencia frente a GPU pero abre una exposición teórica a ataques de canal lateral.
- Argon2i — el acceso a memoria es independiente de la contraseña, lo que cierra ese canal lateral a costa de algo de resistencia frente a GPU.
- Argon2id — combina ambas estrategias en distintas fases del cálculo. Es la variante recomendada por RFC 9106 y la que usan por defecto Django, Laravel y PHP.
Tres parámetros independientes
A diferencia del único "cost factor" de bcrypt, Argon2 permite ajustar memoria, iteraciones y paralelismo por separado. Esto es útil en la práctica: una función serverless con poca memoria disponible puede compensar con más iteraciones, mientras que un servidor de autenticación dedicado con RAM de sobra puede permitirse lo contrario — algo que un parámetro de complejidad único no puede expresar.
Para qué se necesita esto
- Elegir un algoritmo moderno para un nuevo sistema de autenticación en vez de MD5 o SHA-256 simple.
- Entender por qué Argon2 encarece específicamente los ataques con hardware de minería de criptomonedas alquilado.
- Planificar una migración desde bcrypt o PBKDF2 como parte de una auditoría de seguridad.
La trampa del paralelismo
El paralelismo parece una ganancia gratuita: más hilos, hash más rápido en un servidor con varios núcleos. Pero un atacante con el mismo hardware multinúcleo obtiene idéntica ventaja en cada intento. Ajustar el paralelismo al número real de núcleos del servidor es seguro; subirlo "por si acaso" solo le da al atacante un descuento proporcional.