Autenticación

La autenticación es el proceso por el que un sistema comprueba la identidad de quien pide acceso, sea una persona, un dispositivo o un programa. Se hace presentando credenciales, y las credenciales caen en tres categorías: algo que se sabe (una contraseña), algo que se tiene (un código temporal, una tarjeta, un certificado) o algo que se es (una huella, la cara). Usar dos categorías distintas es la autenticación de doble factor; usar dos o más, la multifactor.

Responde solo a la pregunta de quién eres. Lo que esa identidad tiene permitido hacer a continuación es la autorización, que se decide aparte y en cada petición. En español se lee también «autentificación», que quiere decir lo mismo.

La autenticación coge una afirmación y la pone a prueba. Un sujeto presenta un identificador y alguna evidencia, y el sistema decide si la evidencia es lo bastante buena para aceptar la afirmación. El sujeto no tiene que ser una persona: los servicios, las cargas de trabajo y los agentes se autentican constantemente, y en la mayoría de los parques son más que los humanos.

La evidencia cae en tres categorías. Algo que sabes, como una contraseña o un código de recuperación. Algo que tienes, como una llave hardware, un dispositivo que guarda una clave privada o un teléfono con un autenticador. Algo que eres, es decir, una medida biométrica. Las categorías importan porque combinar dos cosas de la misma categoría añade muy poco: un atacante que puede conseguir una contraseña normalmente puede conseguir una segunda contraseña por el mismo camino.

Por debajo solo hay unos pocos mecanismos. Enviar un secreto compartido y compararlo, que es lo que hace una contraseña y por lo que hay que proteger el canal. Demostrar que se posee una clave firmando un reto, que es lo que hacen los certificados, el TLS mutuo y las passkeys, y que no transmite el secreto en ningún momento. O aceptar una afirmación de una parte en la que confías, que es lo que hace la federación con SAML o con OpenID Connect.

Una vez pasada la comprobación, el sistema emite algo que la sustituye: una cookie de sesión, un token, un ticket. Casi todo lo que viene después en un ataque real va sobre ese artefacto y no sobre la comprobación original, porque robar la sesión se salta la autenticación entera.

El fallo más productivo que encontramos no es una contraseña débil. Es una segunda puerta. Un parque impone autenticación fuerte en el camino principal y deja un protocolo antiguo, una cuenta de servicio, una clave de API o una herramienta de soporte que se autentica de otra manera, sin ninguna de las mismas condiciones aplicadas. En los encargos internos y de cloud buscamos el camino alternativo antes que el principal, porque al principal le han prestado atención y al alternativo no.

El segundo es tratar la autenticación como un instante y no como un estado. La comprobación ocurre al iniciar sesión, se emite una sesión, y no vuelve nadie a revisarla. Si el artefacto de sesión se roba, con cross-site scripting, con un proxy de phishing o con un infostealer en el endpoint, el atacante no se autentica en ningún momento. Llega ya estando dentro. Por eso la duración y la revocación de la sesión son decisiones de autenticación, aunque ocurran después.

El tercero es confundir identificación con autenticación. Un campo que dice quién eres es una afirmación. Encontramos con regularidad APIs internas que aceptan un identificador de usuario en una cabecera y actúan a partir de él, porque el servicio se escribió dando por hecho que solo la pasarela podía alcanzarlo. Esa suposición está a un SSRF de ser falsa.

El cuarto es el camino de recuperación. El restablecimiento de contraseña, la recuperación de cuenta y los procedimientos del centro de soporte son autenticación, y suelen ser más débiles que el mecanismo al que pueden pasar por encima. Un atacante no va a atacar una llave hardware. Va a llamar por teléfono al servicio de soporte y le van a emitir una credencial temporal, que en nuestro trabajo de ingeniería social funciona más veces que cualquier ruta técnica.

Estas dos palabras se usan indistintamente en los requisitos, en los tickets y en la documentación de los fabricantes, y la confusión produce vulnerabilidades reales. Son dos decisiones consecutivas y separadas.

La distinción no es académica. El hallazgo serio de API que más veces escribimos es que la autorización se comprobó en la ruta y no en el objeto, de forma que un usuario correctamente autenticado puede leer el registro de otro cliente sin más que cambiar un identificador. La autenticación funcionó a la perfección. Nadie hizo la segunda pregunta.

Una nota de nomenclatura que pilla a mucha gente: OAuth 2.0 es un marco de autorización y no autentica a un usuario, y por eso existe OpenID Connect por encima. Usar un flujo de OAuth a secas como mecanismo de inicio de sesión es un error de diseño recurrente, y la cabecera HTTP se escribe Authorization en la especificación, diga lo que diga el resto de tu documentación.

Contar dos factores de la misma categoría. Una contraseña más una pregunta de seguridad es una categoría dos veces. Y una contraseña más un PIN memorizado también.

Imponer autenticación fuerte solo en la puerta principal. Los protocolos antiguos, las cuentas de servicio, las claves de API y las cuentas de emergencia también autentican, y todas necesitan una postura declarada.

Dejar la sesión fuera de alcance. La duración, la vinculación, la revocación al cambiar de privilegio y el comportamiento al restablecer la contraseña forman parte del control, y son donde de verdad se sobrevive o no a un compromiso.

Limitar por cuenta en vez de por origen. El bloqueo por intentos fallidos es lo que hace atractivo el password spraying: un atacante prueba una contraseña contra miles de cuentas y no dispara ningún contador por cuenta.

Construirte la tuya. La federación, la emisión de tokens y el almacenamiento de credenciales son problemas resueltos, con especificaciones e implementaciones auditadas. Todas las variantes caseras que hemos probado tienen al menos un hallazgo dentro.

Consolida. Cada aplicación que autentica por su cuenta es una cosa más que hay que hacer bien y un sitio más por el que ser atacado; federarlas contra un solo proveedor de identidad significa un solo conjunto de políticas, un solo rastro de auditoría y un solo sitio donde revocar. Esa consolidación es lo que hace viable todo lo demás.

Lleva los caminos más fuertes a factores atados al origen, es decir, credenciales WebAuthn en vez de códigos, para que una réplica convincente de tu página de acceso no pueda retransmitir la prueba. Donde los códigos sean inevitables, dilo de forma explícita y trata esos caminos como más débiles y no como equivalentes.

Ata las sesiones a algo. Un token que funciona desde cualquier dirección, cualquier dispositivo y cualquier cliente es un token que merece la pena robar; unas políticas condicionales que reevalúan el estado del dispositivo y la ubicación en las operaciones sensibles reducen el valor de uno robado. Vuelve a autenticar antes de un cambio de privilegio, no solo al iniciar sesión.

Y arregla después el camino de recuperación, que es donde aterriza el ataque de verdad. Decide quién puede restablecer qué, exige una verificación al menos tan fuerte como el factor que se está sustituyendo, y déjalo registrado. En parques con un centro de soporte grande, este suele ser el cambio de más valor que hay disponible.

La autenticación se revisa en casi todos los encargos, y el hallazgo se escribe contra el camino concreto, nunca contra la aplicación entera: este endpoint, este protocolo, este tipo de cuenta. Dejamos anotado qué presentamos, qué se aceptó y a qué llegó después la credencial aceptada.

La evidencia es la petición y la respuesta, más el estado al que llegamos con la sesión que produjo. Cuando hemos esquivado un factor describimos el mecanismo con precisión, porque «se saltó el MFA» sin mecanismo no es accionable y se tiende a leer como un fallo de producto cuando normalmente es un hueco de política.

La severidad va detrás de a qué llega la identidad, no de lo elegante que sea la esquiva. Una autenticación débil en una cuenta sin privilegios es una observación. Ese mismo fallo en una cuenta que administra el directorio es el hallazgo alrededor del que se construye el informe.

La identidad es donde acaban casi todos los encargos internos, y es la capa por la que trabajamos al probar desde dentro de la red.

¿Cuál es la diferencia entre autenticación y autorización? La autenticación establece quién hace la petición. La autorización decide qué puede hacer ese sujeto. La primera ocurre una vez por sesión; la segunda tiene que ocurrir en cada petición, contra cada objeto, y es de donde sale la mayoría de los hallazgos de control de acceso.

¿MFA es lo mismo que autenticación fuerte? No automáticamente. Dos factores de categorías distintas son mejor que uno, y la autenticación multifactor con códigos o con avisos de aprobación la puede seguir retransmitiendo un proxy de phishing. Fuerte significa atado al origen, que en la práctica significa WebAuthn.

¿Una clave de API autentica? Autentica a quien tiene la clave, que no es lo mismo que autenticar un servicio. Las claves se copian, se suben a repositorios y se comparten entre entornos. Donde la plataforma lo soporte, unas credenciales de carga de trabajo de vida corta son una respuesta bastante mejor.

¿Por qué unas veces sale un 401 y otras un 403? Un 401 significa que la petición no venía autenticada, o que la credencial presentada se rechazó. Un 403 significa que venía autenticada y que el sujeto no tiene permitido hacer esto. Los servidores se equivocan lo bastante a menudo como para que la distinción merezca comprobarse en vez de suponerse.