2FA, Algoritmos OCRA, HOTP y TOTP

OATH responde a las siglas OpenAuTHentication Initiative, una especie de comité colaborativo de expertos en materia de autenticación, que han elaborado con los años diferentes RFC y mecanismos tan familiares como HOTP y TOTP, y algunos más recientes como OCRA.

Empezando por el final, podría resumir el estándar OCRA como el mecanismo de autenticación más robusto hasta la fecha. Y es así porque introduce un challenge o «prueba adicional» para poder facilitarnos la OTP (One Time Password).

Este artículo presupone un cierto conocimiento de base sobre conceptos como MAC, HMAC u OTP. En caso de no tenerlos adquiridos previamente, te recomiendo leer en linea para entender mejor el alcance.

La contraseña de un solo uso es un mecanismo ligado de cerca a los modelos de autenticación multifactor, conocida tradicionalmente como 2FA. Mientras que HOT y TOTP no permiten autentificar la identidad del servidor, OCRA permite realizar este paso, de forma que el dispositivo del usuario sabe que puede confiar en él, potencialmente invalidando ataques tipo MiTM.

Algoritmo OCRA vs HOTP y TOTP

Un dispositivo OCRA o «token» de este tipo es, normalmente, un dispositivo físico o pin pad (un ejemplo conocido es el de la empresa Thales y su EZIO Server) aunque también funciona mediante token tipo Software. El modelo de funcionamiento de este se resume como sigue:

1. Challenge – La aplicación o sitio web a la que el usuario intenta entrar, proporciona un código.
2. El cliente introduce el código en su token
3. Respuesta – el token genera un nuevo código derivado del anterior (si se acepta)
4. El cliente introduce el código de la aplicación, en la web, para completar el inicio de sesión

Es decir, estamos ante un HOTP más avanzado en su diseño. En lugar de utilizarse un contador de tiempo (como en TOTP) para invalidar el token, como en el caso anterior, se puede emplear datos como un challenge o «prueba» de autenticación.

Conozcamos un poco mejor a sus antecesores.

HOTP

HOTP responde a los esfuerzos iniciales de la IETF (Internet Engineering Task Force) comprendidos entre los años 2004 y 2005, cuando se publicó este primer estándar de autenticación. Equivale a Hash-based Message Authentication Code. Más sobre hashes.

Este algoritmo permite generar claves de un solo uso (OTP) utilizando una clave secreta y un contador. El contador del token (definido en la política del administrador) se incrementa en 1 cada vez que se pulsa el botón del dispositivo, del mismo modo que el servidor aumenta su contador con cada OTP aceptado.

HOTP está desfasado a día de hoy (aunque se continúa usando hasta cierto punto) y plantea un problema de seguridad. Dado que el código es válido hasta que se utiliza o bien hasta que uno nuevo lo «refresca», el criminal no tiene la necesidad siquiera de robar el token.

Para conseguir acceso a nuestra cuenta protegida tras OTP bastará con que capturen unos cuantos códigos, pocos. Si tienen tiempo, hasta podrían pulsar el botón más de 100 veces y no sabríamos qué ha sucedido.

TOTP

Con el año 2008 llegó la siguiente iteración del estándar TOTP, conocido como Time-based One Time Password (contraseña de un sosolo uso basada en tiempo). Este sigue siendo el método más común a día de hoy, con aplicaciones tan populares como Google Authenticator para administrarlos.

Como indica su propio nombre, no se utiliza un contador de saltos, sino que se genera una contraseña con la fecha y hora actuales como base.

Su ventaja principal es, por tanto, su duración limitada. No importa si alguien que no debe ha capturado un código OTP en caso de que este ya no tenga vigencia, y hablamos de ventanas muy cortas de tiempo, normalmente 60 segundos o menos.

Así que nuestro token software o hardware posee una clave sereta y la fecha/hora actuales como propiedad adquirida. Ambas serán «hasheadas» con la función correspondiente y el resultado será recortado a una longitud predefinida para el algoritmo.

Así es como se obtiene una OTP que será enviada al servidor, finalmente, para obtener autorización. El servidor, por su lado, verificará que tiene tanto la misma clave secreta que posee el token, como un valor de marca temporal aceptado (se hacen una serie de cálculos).

OCRA

Este algoritmo no es tan reciente como para decir que es algo ultra «novedoso», pero como ya sabéis una cosa son las RFC o nuevas implementaciones y otra, el tiempo que tarda la industria en adoptarlas. En 2010 fue presentado y aún hoy continúa lejos de la predominancia, pero su ratio de adopción aumenta.

A grosso modo, OCRA es una evolución de TOTP para añadirle un challenge-response, es decir, una capa más de seguridad, tras verse durante años las flaquezas inherentes a los otros mecanismos. Básicamente se trata de poder identificar de forma inequívoca al servidor remoto.

Funcionamiento básico

Si tomamos como base la normativa de IETF, lo primero que necesitamos satisfacer antes de que el token produzca un OTP para nosotros, es un dato variable previamente acordado entre las partes.

El administrador podría definir que esto sea:

• Un contador
• Una marca temporal (time stamp)
• Un PIN
• Un identificador de sesión
• Un conjunto pregunta-respuesta
• Una palabra

Etcétera, como se puede ver hay mucha flexibilidad. Más información en la RFC 6287 de OCRA.

La diferencia fundamental entre OCRA y HOTP/TOTP es que en el primer caso, el servidor y el usuario pueden validar la identidad del otro, mientras en el otro caso esto solo es posible por parte del servidor, pero no del cliente.

Básicamente, tanto el servidor como el «cliente» o usuario realizan dos cálculos matemáticos paralelos, tomando una Función Criptográfica compuesta por:

• K –> shred secret o «secreto» pre-compartido por ambas partes
• DataInput –> una estructura que contiene una consecución de varios datos introducidos o calculados, en su conjunto.
• CryptoFunction –> la verdadera función que realiza los cálculos computacionales tomando como base la clave K y la Entrada de Datos (DataInput).

Otros modos de empleo

Un uso más avanzado de tecnologías como OCRA tiene su lugar en cuanto a lo que se conoce como firma transaccional o transaction data signing. Es decir, lo que se verifica no es un proceso de «autenticación» corriente, sino una operación que pretendemos llevar a cabo, confirmando algunos detalles sobre la misma.

Un caso de uso común son operaciones financieras, como transferencias o pagos, que a través de valores conocidos como número de cuenta, cuantía o moneda, pueden ser verificadas a través de OCRA.

A continuación tenéis un video demostrativo.

Y también podéis verlo en funcionamiento rápidamente con la demo de Protectimus.