Firmas y algoritmos permitidos

Las firmas de la familia HMAC (HS256 y compañía) usan una sola clave: la misma firma y verifica. Quien pueda verificar un token también puede fabricar uno que otro servicio dará por bueno, porque no hay forma de distinguir los dos usos con ese secreto. Las firmas de par de claves (RS256, ES256) separan los dos papeles: la clave privada firma y se queda en el emisor; la pública verifica y se puede repartir sin riesgo.

Por eso HS256 resulta cómodo entre dos sistemas que se fían mutuamente y se vuelve problemático cuando el secreto se reparte. El portal de conductores de Pico Verde usa HS256: mira en el inventario de servicios cuántos sitios guardan ese secreto y piensa qué puede hacer cada uno.

La especificación de los JWT permite un token sin firma, cuyo algoritmo declarado es none. Existe para usos muy particulares en los que otra capa ya garantiza la integridad. Una API que valida credenciales de acceso no es uno de ellos. La guía de buenas prácticas para JWT (RFC 8725) pide que las bibliotecas no acepten none salvo que quien las usa lo pida explícitamente, y en una API de usuarios casi nunca hay motivo para pedirlo.

Que un servicio lo acepte no significa que alguien lo haya explotado; significa que el servicio no exige firma a un token que dice no tenerla. Busca en el inventario cuál lo tiene en su lista de algoritmos aceptados.

Aceptar dos algoritmos de familias distintas en un mismo punto de verificación suele ser un parche de migración que se quedó: se añadió uno nuevo sin quitar el viejo. Cada algoritmo aceptado es una puerta que hay que vigilar, y dos familias significan que se necesitan dos tipos de clave, con riesgos que no se parecen. El principio de la RFC 8725 es permitir solo algoritmos vigentes que cumplan lo que la aplicación necesita, con una lista fija decidida por quien verifica, no por el token.

Revisa de nuevo el inventario y busca el servicio que verifica con un algoritmo de par de claves y también con uno de secreto compartido.

El riesgo de un secreto compartido crece con cada lugar donde se copia: cada equipo que lo guarda es otro portátil, otra copia de seguridad, otro repositorio de configuración donde puede acabar. Antes de proponer una migración conviene cuantificar el problema, y la tabla de custodia dice qué servicios lo guardan y quién lo administra.

Cuenta los servicios de la tabla de custodia que guardan el secreto compartido.

El arreglo no es endurecer el parámetro de un solo servicio sino cambiar el criterio. Cada verificador declara de antemano la lista corta de algoritmos que acepta, la que le corresponde por el tipo de clave que tiene, y rechaza cualquier token que declare otro. Los servicios que solo verifican deben tener solo claves públicas; el secreto compartido se migra a un par de claves cuando haya más de dos partes implicadas, y entretanto se retira de quien no lo necesita.