Funciones lentas, sal y parámetros de coste

Las funciones de resumen de uso general, como SHA-256, están pensadas para ser rápidas: resumir un archivo grande en milisegundos. Con contraseñas, esa rapidez juega a favor de quien robó la base, que puede probar miles de millones de candidatas por segundo con hardware común. Las funciones de derivación para contraseñas (argon2id, scrypt, bcrypt, PBKDF2) son lentas a propósito y tienen un parámetro de coste —iteraciones, memoria o ambos— que se ajusta para que una verificación legítima tarde un poco y un ataque masivo tarde muchísimo.

La sal es un valor aleatorio distinto para cada cuenta que entra en la derivación. Hace que dos personas con la misma contraseña tengan resúmenes distintos y que no sirvan tablas calculadas de antemano. NIST pide al menos 32 bits de sal, que la derivación sea con un esquema aprobado y que el coste sea tan alto como el servidor permita, subiéndolo con el tiempo. También recomienda un paso adicional con una clave secreta que solo conoce el verificador, a menudo llamada pimienta, guardada aparte de los resúmenes.

Sin sal, la misma contraseña produce siempre el mismo resumen. Eso se ve sin descifrar nada: basta con buscar valores repetidos en la columna. Dos cuentas con el mismo resumen comparten contraseña, y si una se descubre, la otra cae con ella.

Abre esquema-usuarios.sql para ver qué guarda la tabla heredada y luego muestra-agentes.txt. El recorte del cliente basta para comparar.

La tabla de agentes guarda un SHA-256 de una pasada, sin sal y sin coste. Hay varios CWE cercanos y el informe necesita el que describe el defecto que acabas de demostrar con la muestra: que valores iguales producen resúmenes iguales.

El coste no se elige por costumbre: se mide en el servidor que verifica y se sube hasta donde aguante el presupuesto de tiempo que acepta el equipo. Cada punto de coste en bcrypt duplica el tiempo, así que el salto entre dos valores seguidos es grande. Si el presupuesto lo permite, argon2id es la opción preferida hoy para sistemas nuevos; bcrypt sigue siendo aceptable donde ya está, con un coste que no se quedó en el de hace años. Recuerda además que bcrypt solo usa los primeros 72 bytes de la entrada.

Abre config-hash.txt para ver el coste actual y medicion-coste.txt para ver el presupuesto y los tiempos.

La pimienta solo protege si quien se lleva los resúmenes no se lleva también la clave. Si la clave está en la misma base, una copia robada de esa base trae las dos cosas, y el paso adicional deja de añadir nada. Lo razonable es tenerla fuera de la base: en un almacén de secretos o, mejor aún, en un módulo de hardware que haga el cálculo sin entregarla.

Vuelve a config-hash.txt y al esquema.