Hash, integridad y contraseñas

Verificar integridad y guardar contraseñas se parecen —los dos usan «un hash»— y piden funciones opuestas. Para comprobar que un archivo no cambió quieres una función veloz y con fuerte resistencia a colisiones, como SHA-256: la corres sobre gigabytes y comparas. Para guardar una contraseña quieres una función lenta y con sal por usuario —bcrypt, scrypt, Argon2—, porque la lentitud es una defensa: encarece probar millones de candidatos. Usar la función rápida para contraseñas es el error clásico, y no se nota hasta que alguien roba la base y la descifra en masa.

Saber a cuál de los dos problemas pertenece un hash es lo que decide si la elección fue correcta.

El servicio de cuentas de CifraLab guarda las contraseñas como SHA-256, sin sal. El razonamiento del equipo fue «SHA-256 es seguro», y lo es —para verificar integridad—. Para contraseñas es un desastre por dos motivos: es rapidísimo, así que un atacante prueba miles de millones de candidatos por segundo con una tarjeta gráfica; y al no llevar sal, dos usuarios con la misma contraseña tienen el mismo hash, y se atacan todos a la vez con tablas precalculadas. El arreglo no es cambiar a SHA-512 —sigue siendo rápido— sino a una función de contraseñas con sal: bcrypt, scrypt o Argon2.

El uso está mal no porque SHA-256 sea débil, sino porque es la función correcta para otro problema.

Otro servicio publica descargas con su MD5 al lado, para que quien las baje compruebe que no se corrompieron. Como control de erratas de transmisión, un MD5 detecta un bit volteado por accidente. Como control de seguridad no vale nada: MD5 está roto —se sabe fabricar dos archivos distintos con el mismo MD5—, así que un atacante puede sustituir la descarga por una maliciosa que coincide con el hash publicado, y la comprobación pasa. Para verificar integridad frente a un adversario, la función es SHA-256 o SHA-3; MD5 y SHA-1 quedaron fuera.

El fallo no es tener una suma de verificación: es confiar en una función a la que ya se le saben colisiones.

No todo en CifraLab está mal. Un servicio verifica los avisos que recibe de un sistema externo calculando un HMAC-SHA256 sobre el cuerpo con una clave compartida, y comparando el resultado con la firma que llega en la cabecera. Eso es correcto: el HMAC da integridad y autenticidad a la vez —confirma que el mensaje no cambió y que viene de quien conoce la clave—, usa una función vigente, y no intenta ocultar nada porque no es su trabajo. Reconocer un uso correcto es tan parte del oficio como cazar el fallo: si marcas todo como problema, el informe no sirve.

Un HMAC sobre el mensaje, con función vigente y clave compartida bien guardada, es exactamente para lo que existe.

Separaste el hash de verificar del hash de guardar contraseñas y marcaste cuál encajaba. Ahora abre el laboratorio, recorre el almacén de contraseñas, las descargas y la validación de avisos, y lee el código que la auditoría anotó al cerrar la revisión de hashes.