Argon2 o bcrypt: el algoritmo correcto falla con parámetros débiles

Para almacenar contraseñas nuevas, elige Argon2id y configura sus costes según la capacidad real del servicio. Bcrypt conserva una función útil al verificar hashes heredados, pero elegir cualquiera de los dos nombres sin revisar sus parámetros puede dejar hashes baratos de atacar. Si migras desde bcrypt, necesitarás la contraseña que el usuario introduzca en un inicio de sesión válido para generar el nuevo hash.

La elección combina resistencia frente a intentos masivos de adivinar contraseñas con el tiempo y la memoria que consume cada verificación legítima. Argon2id permite ajustar memoria, pasadas y paralelismo; bcrypt utiliza un factor de coste y tiene un límite de entrada que afecta a las contraseñas largas. La configuración nueva y los hashes ya almacenados requieren atención por separado: cambiar los valores predeterminados de la aplicación no modifica los registros anteriores.

Qué coste añade cada algoritmo

Argon2id reserva memoria para cada cálculo. Sus parámetros son la memoria total m, las pasadas t y el paralelismo p, que distribuye el trabajo entre vías. Aumentar las vías no multiplica por sí mismo la memoria total ni sustituye una pasada adicional. Es la combinación de esos valores la que determina el trabajo exigido por cada intento.

Bcrypt eleva el trabajo de cálculo mediante su factor de coste. Puede seguir verificando contraseñas de cuentas existentes mientras se prepara una migración, siempre que la aplicación reconozca cómo se creó cada hash. Ni el factor de bcrypt ni las pasadas de Argon2id describen por sí solos la resistencia de una contraseña: también importan el esquema utilizado, los demás parámetros y lo fácil que resulte adivinar la contraseña elegida por el usuario.

Mínimos y perfiles para tomar una decisión

La guía de almacenamiento de OWASP recomienda Argon2id con 19 MiB de memoria, dos pasadas y una vía como configuración mínima; también recoge 46 MiB, una pasada y una vía como otra combinación mínima. Para bcrypt heredado indica un factor de coste de al menos 10 y advierte de un límite de entrada de 72 bytes en la mayoría de las implementaciones. Son combinaciones de parámetros: tomar la memoria de una opción y las pasadas de otra no conserva automáticamente la resistencia prevista.

El RFC 9106 propone dos perfiles Argon2id con cuatro vías: 2 GiB y una pasada como primera recomendación, o 64 MiB y tres pasadas para entornos con menos memoria. Esas recomendaciones emplean más memoria que el punto de partida citado arriba, pero el RFC también plantea elegir la memoria que puede permitirse cada llamada y después ajustar las pasadas al tiempo disponible. Sus perfiles no son resultados de latencia medidos en la infraestructura de cada aplicación.

• Aplicación nueva: Argon2id con una combinación recomendada de memoria, pasadas y vías; selecciona el perfil que pueda sostener la carga de autenticación.
• Servicio con hashes bcrypt: conserva la verificación de esos registros durante la transición y revisa tanto su factor de coste como el tratamiento de entradas largas.
• Hashes Argon2id existentes: compara los parámetros guardados en cada registro con la política vigente; la configuración actual de la biblioteca solo describe los hashes que crea ahora.

La lista separa recomendaciones de configuración de mediciones de rendimiento. Un coste bcrypt no se puede convertir en una cantidad equivalente de memoria Argon2id: los parámetros controlan trabajos distintos. Tampoco conviene adoptar el perfil de mayor memoria sin calcular cuántas verificaciones pueden ejecutarse simultáneamente.

Latencia y memoria bajo carga

Mide la verificación con la biblioteca, el hardware y la concurrencia previstos para producción. Registra el tiempo habitual y el de los periodos de mayor demanda; después ajusta memoria o pasadas de Argon2id, o el coste de bcrypt, dentro del presupuesto de respuesta del servicio. Una ejecución aislada puede parecer rápida y, aun así, ocupar demasiados recursos cuando coinciden varios inicios de sesión.

En Argon2id, el presupuesto de memoria debe cubrir las verificaciones activas a la vez, además del resto de la aplicación. Como ejemplo condicional, diez cálculos simultáneos configurados con 64 MiB por hash suman 640 MiB solo en la memoria asignada a ese trabajo. Si el servicio no puede sostener esa concurrencia, puede limitar los cálculos simultáneos o elegir otra combinación completa de memoria y pasadas; reducir un parámetro aislado y mantener el mismo nombre de algoritmo no garantiza una protección equivalente.

La prueba debe incluir el camino real de autenticación, donde también hay espera, acceso a datos y otras tareas. El resultado útil es una configuración que el servicio pueda mantener durante picos previstos sin convertir cada intento legítimo en una demora excesiva. Una cifra de latencia obtenida en otro procesador o con otra cantidad de solicitudes simultáneas no reemplaza esa medición.

Por qué aparecen hashes Argon2id débiles

El estudio de repositorios de Tippe y Berner clasificó 75 de 161 configuraciones examinadas, el 46,6 %, como más débiles que una curva construida al extrapolar las recomendaciones de OWASP. Los autores revisaron código público cuyos parámetros podían identificarse; el porcentaje describe esa muestra y su método de comparación, no la proporción de servicios en producción.

El hallazgo señala un problema verificable en una aplicación concreta: disponer de Argon2id no revela qué valores usa para crear hashes. Además, los registros antiguos pueden contener menos memoria o pasadas que los nuevos. Para conocer el estado real hay que distinguir la configuración que genera el servicio hoy de los parámetros almacenados con cada contraseña; ambas poblaciones pueden convivir durante años si algunas cuentas dejan de iniciar sesión.

El límite de bcrypt con contraseñas largas

El límite de entrada de bcrypt se mide en bytes, no en caracteres visibles. Una contraseña con caracteres Unicode puede alcanzarlo antes que otra con el mismo número de letras ASCII. Si una biblioteca trunca silenciosamente la entrada, dos contraseñas que difieren solo después de los bytes procesados pueden dar una verificación equivalente. Por eso importa comprobar el comportamiento exacto de la implementación que creó los hashes existentes.

Las directrices de NIST para verificadores exigen verificar la contraseña completa y recomiendan permitir al menos 64 caracteres. Una política expresada en caracteres y un límite de biblioteca expresado en bytes pueden chocar, sobre todo con Unicode. Para contraseñas nuevas, Argon2id evita el límite propio de bcrypt; para cuentas heredadas, cambiar de golpe la codificación o el tratamiento de la entrada podría impedir verificar contraseñas que antes funcionaban.

Aplicar un hash rápido a la contraseña antes de pasarla a bcrypt tampoco es una sustitución automática: introduce decisiones sobre codificación y posibles riesgos si el resultado se utiliza incorrectamente. Cuando el destino es Argon2id, la ruta más sencilla es verificar el hash heredado y calcular el nuevo directamente a partir de la contraseña introducida tras una autenticación correcta.

Rehash al iniciar sesión y salida del legado

Guarda con cada hash el esquema y los parámetros necesarios para verificarlo y decidir si cumple la política vigente. Durante la transición, el mismo almacén puede contener bcrypt y distintas configuraciones de Argon2id. Esa mezcla es manejable si el verificador selecciona el método correspondiente a cada registro antes de comparar la contraseña.

1. Identifica el algoritmo y verifica la contraseña presentada con el esquema del hash almacenado.
2. Tras una verificación correcta, compara el algoritmo y sus parámetros con la política actual. Si el registro es heredado o insuficiente, calcula un nuevo hash Argon2id con esa contraseña y sustituye el anterior.
3. Cuenta los hashes antiguos que permanecen. Para las cuentas que no vuelvan a autenticarse, fija una política de caducidad y restablecimiento de contraseña.

Como ejemplo de implementación, la documentación de PHP para password_needs_rehash muestra cómo comprobar, después de verificar una contraseña, si el hash coincide con el algoritmo y las opciones deseados antes de reemplazarlo. La misma lógica de decisión puede aplicarse en otros entornos con sus propias bibliotecas.

Un hash bcrypt no permite recuperar la contraseña original para convertirla directamente en un hash Argon2id. Por eso el inicio de sesión ofrece el momento para actualizarlo sin pedir a todas las personas que cambien su contraseña a la vez. La migración queda pendiente mientras haya registros antiguos almacenados: que las altas nuevas usen Argon2id solo resuelve una parte del inventario.

Lee también:

• Archie descarta creadores con IA: la marca aún debe aprobar cada nombre
• Resect AI aparece con 25 millones: los inversores siguen sin nombre
• Australia dejará apagar el algoritmo: el feed alternativo sigue sin definir