Cifrar, resumir y codificar: qué es aceptable y dónde falla

En un código aparecen con frecuencia tres operaciones que parecen parientes y no lo son. Una codificación (Base64, por ejemplo) cambia la forma de unos datos para transportarlos; no usa clave y cualquiera la revierte. Un resumen (SHA-256, por ejemplo) convierte unos datos en una huella de tamaño fijo y no tiene vuelta atrás; sirve para comprobar integridad o para guardar contraseñas con las precauciones adecuadas. Un cifrado (AES en un modo autenticado como GCM, por ejemplo) oculta los datos y los devuelve a quien tenga la clave.

La pregunta de una revisión es siempre: ¿qué se quería lograr aquí y qué operación se eligió? Equivocar la operación es el fallo más común y el que más se nota en un informe.

Un fallo clásico: el código guarda un texto sensible pasado por Base64 y un comentario lo llama «cifrado». No hay clave, no hay secreto: quien lea el archivo lo revierte con una línea. En el informe se redacta como uso de codificación como si fuera cifrado, con su ubicación, y se cierra eligiendo la operación correcta: cifrar con una clave del almacén seguro del sistema o, mejor, no guardar el dato.

Abre el laboratorio y lee el inventario de usos de criptografía. Una sola fila describe este patrón.

MD5 y SHA-1 están desaconsejados para todo lo que dependa de que nadie pueda fabricar una colisión: firmas, certificados, integridad frente a un adversario. Pero marcar todo MD5 como hallazgo llena el informe de ruido. El criterio es para qué se usa: si el resumen no protege un secreto ni decide un acceso —detectar una descarga truncada, por ejemplo—, no hay adversario al que frenar.

El análisis honesto separa el hallazgo (el resumen decide algo de seguridad) de la observación (el algoritmo es viejo pero su uso es inocuo) y no los mezcla.

Guardar un PIN o una contraseña exige un resumen lento y con sal, pensado para ese fin, nunca un resumen rápido de uso general. Un SHA-1 sin sal se calcula miles de millones de veces por segundo y dos socios con el mismo PIN dejarían el mismo valor guardado. En el informe se anota el archivo, la función y el algoritmo, no el valor.

Lee el inventario y localiza dónde se comprueba el PIN de cuatro dígitos.

Cambiar SHA-1 por SHA-256 en un PIN de cuatro dígitos no cambia el fondo: solo hay 10 000 PIN posibles, y probarlos todos contra un resumen robado es cuestión de instantes con cualquier algoritmo. Lo que protege un PIN corto es que el intento no se pueda repetir sin límite: contar los intentos, bloquear tras varios fallos y atar la verificación a una clave guardada en el almacén seguro del sistema, que no sale del dispositivo.

El informe recomienda la mitigación estructural; el cambio de algoritmo puede acompañarla, pero no la sustituye.