Control de acceso

Detrás de lo que coloquialmente se llama «entrar en el sistema» hay cuatro operaciones distintas que ocurren una detrás de otra. Se confunden constantemente en el lenguaje corriente y se preguntan enfrentadas, así que merece la pena separarlas antes de ver ningún protocolo.

A las tres primeras se las llama a menudo por sus iniciales inglesas, AAA, de authentication, authorization y accounting, y ese es el nombre que llevan los protocolos y los servidores dedicados a prestarlas de forma centralizada. La regla que ordena las cuatro es que cada una presupone la anterior: no se puede autorizar a quien no se ha autenticado, y no sirve de nada registrar la actividad de un usuario cuya identidad no se ha comprobado.

Sobre la autorización hay además dos principios que se dan por sabidos en cualquier examen. El de mínimo privilegio dice que a cada usuario se le concede exactamente lo que necesita para su trabajo y nada más. El de separación de funciones dice que ninguna persona debe controlar por sí sola todos los pasos de un proceso crítico, para que un error o un abuso necesiten la complicidad de otro.

Identificar es declarar la identidad, autenticar es probarla y autorizar es decidir qué se permite. Un fallo de autorización deja pasar a un usuario perfectamente autenticado a un sitio donde no pinta nada.

Para demostrar una identidad solo existen tres clases de prueba, y todas las técnicas conocidas caen en alguna de ellas. La clasificación es corta y se pregunta pidiendo que se sitúe un ejemplo concreto en su casilla.

La autenticación multifactor, MFA, consiste en exigir pruebas de dos o más factores DISTINTOS. Ahí está la sutileza que decide las preguntas: pedir una contraseña y además una pregunta de seguridad no es multifactor, porque las dos cosas son conocimiento; pedir una contraseña y un código enviado al móvil sí lo es, porque combina lo que se sabe con lo que se tiene. Cuando los factores son exactamente dos se habla de 2FA, verificación en dos pasos o doble factor.

El motivo de exigir dos factores es que las amenazas de cada uno son independientes. Una contraseña se roba por phishing, por fuerza bruta o porque el usuario la reutiliza en otro sitio; ninguna de esas tres cosas le da al atacante el teléfono de la víctima. Por eso el multifactor neutraliza de golpe la mayor parte de los ataques a credenciales, incluso cuando la contraseña ya se ha filtrado.

Multifactor significa factores de tipo distinto, no dos contraseñas. Lo que sé, lo que tengo y lo que soy.

En una organización con cientos de equipos no puede haber una lista de usuarios en cada máquina: las credenciales se guardan una sola vez en un servicio central y todo lo demás pregunta a ese servicio. Los dos protocolos clásicos para conseguirlo son distintos en objeto y en mecanismo, y por eso se preguntan enfrentados.

La pieza que hay que retener de Kerberos es el tique. El usuario se autentica una sola vez ante el centro de distribución de claves y a partir de ahí no vuelve a enviar su contraseña por la red: lo que viaja son tiques cifrados y con fecha de caducidad. De ahí dos consecuencias que caen. La primera, que Kerberos es la base del inicio de sesión único dentro de un dominio. La segunda, que exige que los relojes de todas las máquinas estén sincronizados, porque un tique caducado no se acepta y un desfase de minutos rompe el sistema entero.

Junto a RADIUS suele citarse su sucesor, Diameter, que cubre las mismas funciones AAA con más capacidad y mejor seguridad en el transporte. En el mundo de los equipos de red conviven además con TACACS+, de uso frecuente para administrar dispositivos de comunicaciones.

RADIUS controla la entrada a la red y es AAA. Kerberos autentica dentro del dominio y trabaja con tiques. La palabra «tiques» en un enunciado apunta siempre a Kerberos.

El inicio de sesión único, SSO por sus siglas inglesas, es el mecanismo por el que un usuario se autentica una vez y accede después a varias aplicaciones distintas sin repetir la operación. No es una comodidad menor: reduce el número de contraseñas que la persona tiene que recordar, que es la causa de que se reutilicen y se apunten en un papel, y concentra el control en un único punto donde se puede exigir multifactor y desde el que se revoca el acceso a todo a la vez.

Para que ese esquema funcione entre organizaciones distintas hacen falta dos papeles bien separados. El proveedor de identidad es quien conoce al usuario y responde de él; el proveedor de servicio es la aplicación a la que el usuario quiere entrar y que confía en lo que el primero le diga. A esa confianza entre dominios distintos se la llama federación de identidad.

SAML es el lenguaje con el que esos dos papeles se hablan: un formato basado en XML en el que el proveedor de identidad emite una aserción firmada que dice quién es el usuario y qué atributos tiene, y el proveedor de servicio la verifica y le abre la sesión. Es el estándar tradicional del SSO empresarial y del sector público.

El ejemplo español es Cl@ve, el sistema común de identificación y autenticación de las Administraciones Públicas. El ciudadano se identifica una vez y accede con ello a las sedes electrónicas de organismos distintos, sin que cada uno tenga que montar y custodiar su propio registro de usuarios y sus propias contraseñas.

OAuth 2.0 es el estándar con el que un usuario autoriza a una aplicación a usar en su nombre un recurso alojado en otro sitio, sin entregarle su contraseña. La aplicación no recibe credenciales: recibe un testigo de acceso, limitado a un alcance concreto y con caducidad, que puede revocarse en cualquier momento sin cambiar nada más.

El error clásico, y la pregunta que lo persigue, es tomar OAuth por un protocolo de autenticación. No lo es: OAuth resuelve la AUTORIZACIÓN, es decir, qué puede hacer el portador del testigo, y no dice nada fiable sobre quién es el usuario. Lo que añade esa pieza que falta es OpenID Connect, una capa de identidad construida encima de OAuth 2.0 que incorpora un testigo adicional, el de identidad, con los datos del usuario autenticado. Por eso hoy se habla de OpenID Connect y no del antiguo OpenID.

El formato en que suelen viajar esos testigos es JWT, un objeto compacto de tres partes separadas por puntos: la cabecera, que dice cómo está firmado; el cuerpo o carga útil, con las afirmaciones sobre el usuario y la caducidad; y la firma, que permite comprobar que nadie lo ha modificado. Su propiedad interesante es que el servidor puede validarlo sin consultar una base de datos, porque toda la información va dentro y la firma la respalda.

// Carga útil de un JWT emitido al iniciar sesión un alumno.
// Va firmada, pero NO va cifrada: cualquiera que intercepte el
// testigo puede leer su contenido, así que aquí nunca se mete un
// dato que deba permanecer secreto.
{
  "sub": "alumno-4192",
  "itinerario": "sistemas",
  "plan": "express",
  "nivelMaximo": 1,
  "iat": 1755300000,
  "exp": 1755303600
}

De ese ejemplo salen las dos cautelas que hay que recordar. La primera, que un JWT va firmado pero no cifrado, de modo que su contenido se lee sin ninguna clave: no es sitio para secretos. La segunda, que el servidor tiene que verificar siempre la firma y la caducidad antes de creerse una sola de sus afirmaciones, porque el testigo llega del navegador y todo lo que llega del navegador es sospechoso hasta que se comprueba.

OAuth autoriza, OpenID Connect autentica sobre OAuth, y JWT es solo el formato en que viaja el testigo. Son tres cosas de tres capas distintas.

La contraseña sigue siendo el mecanismo más extendido y el más débil, porque su seguridad depende de una persona. Se roba por phishing, se adivina con diccionarios, se reutiliza en un servicio que sufre una filtración y se comparte entre compañeros. La recomendación actual no insiste tanto en la complejidad tipográfica como en la longitud, en no reutilizarla y en no obligar a cambiarla periódicamente sin motivo, porque la caducidad forzosa lleva a variaciones previsibles de la misma clave.

Del lado del sistema, la regla no negociable es que las contraseñas nunca se almacenan tal cual, ni siquiera cifradas de forma reversible: se guarda el resultado de aplicarles una función resumen pensada para ser lenta, junto con un valor aleatorio distinto para cada usuario, la sal, que impide precalcular tablas de equivalencias. Así, quien roba la base de datos no obtiene contraseñas utilizables.

Sobre esa base se apoyan los dos refuerzos que se preguntan por su nombre.

• OTP, contraseña de un solo uso: un código válido para una única operación y durante un intervalo muy corto. Puede generarse en el propio dispositivo a partir de una semilla compartida y del reloj, o enviarse por un canal distinto. Su ventaja es que capturarlo no sirve de nada, porque caduca; por eso es el segundo factor más frecuente.
• Biometría: reconoce a la persona por un rasgo físico o de comportamiento. Es cómoda y no se olvida, pero tiene un problema que no tienen las otras dos: si se compromete, no se puede sustituir. Una contraseña filtrada se cambia; una huella dactilar, no. Además nunca compara de forma exacta, sino por umbral de parecido, lo que obliga a equilibrar dos errores contrarios: rechazar a un titular legítimo o admitir a un impostor.

Cierra el cuadro el certificado electrónico, que es el factor de posesión característico de la Administración: la clave privada está en una tarjeta o en el almacén del equipo, y con ella se acredita la identidad y se firma. Es el mismo mecanismo en que se apoya el documento nacional de identidad electrónico.