Confusión de algoritmos, a nivel de lectura

Una clave pública de RSA y un secreto compartido de HMAC son, para una biblioteca descuidada, solo bytes. Si el verificador toma el algoritmo de la cabecera del token y busca la clave por su kid sin cruzar los dos datos, una clave registrada para una familia puede acabar usándose en otra: el que verifica «obedece» al token. Los materiales de la RFC 8725 lo resumen en una regla: la biblioteca debe comprobar que el alg de la cabecera coincide con la operación criptográfica que va a hacer, y la aplicación debe ceñirse a una lista de algoritmos que ella decide.

El síntoma en un registro es sencillo de reconocer: el algoritmo declarado difiere del que la clave tiene previsto, y aun así el resultado es «aceptado». La causa es de diseño, no de un fallo de la matemática de la firma.

Lo primero que hace un analista con una anomalía es identificar a su protagonista, sin concluir todavía nada. En el registro, las validaciones con el algoritmo desviado se agrupan en una cuenta concreta, y esa cuenta puede ser un atacante o puede ser alguien que estaba probando con permiso. La evidencia sola no lo decide: hay que contrastarla con las anotaciones que acompañan al registro.

Compara las columnas de algoritmo declarado y esperado, filtra las aceptadas y lee la cuenta.

Medir el alcance viene antes de proponer el arreglo: no es lo mismo una aceptación aislada que una racha. En el registro hay también rechazos con algoritmos desviados, y esos son la pasarela funcionando como debe: un token que declara none, o un algoritmo que no está en su lista, se rechaza. Solo cuentan para esta medida los que acabaron aceptados.

Cuenta las validaciones aceptadas cuyo algoritmo declarado difiere del esperado por la clave.

Un hallazgo de este tipo se completa con el origen y el contexto: de qué dirección llegaron las validaciones y si hay una explicación documentada. Aquí las anotaciones del registro incluyen una campaña de pruebas de calidad autorizada por el responsable de la API, con un puesto de pruebas. Eso cambia el tratamiento del caso —no es un incidente—, pero no cambia el hallazgo: la pasarela aceptó un algoritmo que la clave no tenía previsto, y lo habría hecho igual para otro origen.

Lee el origen de esas validaciones.

El arreglo tiene dos mitades. Primera: cada clave registrada declara un único algoritmo y el verificador lo usa, no el que traiga el token; el algoritmo de la cabecera solo sirve para comprobar que coincide y, si no coincide, se rechaza. Segunda: la lista de algoritmos aceptados es corta y la decide el servicio. Además conviene separar las claves por familia, para que ninguna clave pública de par de claves esté cargada en un camino de secreto compartido, y acabar con los parches de migración que mantienen dos familias en el mismo punto.