El 2FA y la seguridad

La seguridad es lo que más se busca cuando, como es nuestro caso, eres la línea de defensa entre tus clientes y los posibles atacantes. En el mundo de la informática son muy frecuentes los intentos de  denegación de servicio, pero hay más tipos de ataques y nunca sabes por dónde pueden venirte. Así que toca reforzar todos los frentes, blindar todas las puertas y tapar las rendijas por donde algún malvado podría intentar realizar fechorías. 

Como muchas otras compañías de producto, Transparent Edge Services ofrece a sus clientes control total sobre su producto a través de un panel de control, al que se accede con un usuario y una contraseña autorizados. Una contraseña robusta -con su longitud, sus letras, números, mayúsculas y caracteres especiales- es fundamental para aportar un punto extra de seguridad. Sin embargo, todavía hay mucha gente que usa contraseñas cortas y sencillas. Para estos usuarios en especial, y en general para todos, recientemente hemos añadido la posibilidad de activar la autenticación de doble factor (2FA). Queremos asegurarnos de que el usuario, y solo el usuario, sea quien acceda con sus credenciales.

2FA porque toda seguridad es poca

La autenticación de doble factor, o verificación en dos pasos, es uno de los sistemas más empleados para reforzar la autenticación de usuarios. Con ella activa, además de tener que introducir el usuario y contraseña, hay que introducir un código de seis dígitos asociado que cambia con el tiempo. Seguro que lo has utilizado alguna vez. Lo que queremos contarte es cómo ha sido implementarlo de forma transparente en nuestro sistema de autenticación.

En las fases de diseño de esta funcionalidad teníamos algo claro. Partíamos de una amplia base de usuarios con diversas maneras de pensar, así que el 2FA no podía ser algo obligatorio, al menos de momento, ya que nuestra intención, siempre, es hacer las cosas fáciles a nuestros clientes. Por ello, decidimos añadir un apartado nuevo en la zona de usuarios donde cada uno podría activar y desactivar el 2FA según sus necesidades.

Precisamente esta posibilidad de activar y desactivar la verificación fue otro de los requisitos que nos autoimpusimos, de nuevo, con la flexibilidad en mente. El último punto importante en la fase de diseño fue la facilidad de activación para el usuario. Tras dos años usando códigos QR por la pandemia, nos decidimos a usar estas imágenes ya de uso común, que además son totalmente compatibles con aplicaciones móviles de terceros como Google Authenticator o Authy.

Manos al código

Con la hoja de requisitos definida nos pusimos manos a la obra. El panel de control, por debajo, emplea nuestra propia API, la cual está disponible para todo el público. Así que virtualmente los usuarios están constantemente realizando peticiones REST a la API, aunque de forma más amigable. Y el 2FA no iba a ser menos. 

Tres fueron los endpoints o URLs que se habilitaron para todas las situaciones planteadas. El primero es el más obvio: un endpoint para recoger los métodos POST y DELETE relacionados con la activación del servicio. Mediante una petición POST, se genera una clave única para cada usuario que queda almacenada de manera cifrada en nuestras bases de datos, y el DELETE sirve para invalidar dicha clave y desactivar el servicio.

Aunque la clave es todo lo que se necesita para poder añadirla a las aplicaciones de verificación, en nuestra hoja de diseño entraba ofrecer código QR, mucho más manejable. Así que mediante una serie de librerías, convertimos dicha clave en un QR que además incluye información extra acerca del servicio y usuario asociados. De esta manera, devolvemos en la respuesta a la petición la imagen QR y la clave para que el usuario pueda almacenarla de forma segura en su aplicación de confianza.

Un punto de verificación extra

En principio se trata de un proceso fácil. Sin embargo, en las primeras pruebas internas nos surgió una duda. ¿Y si el usuario, por el motivo que fuera, no añadía la clave en su aplicación? Internamente, el usuario habría quedado marcado como usuario del 2FA y se le pediría la clave al intentar entrar en el panel de control, pero podría no haberla terminado de guardar. Así que decidimos añadir dos salvaguardas para solventar este problema.

La primera de ella fue implementar el método GET en el mismo endpoint que el POST y DELETE anteriores, de forma que el usuario pudiera recuperar su clave activa en cualquier momento. Y para asegurar que tuviera la clave grabada en su aplicación, se le pediría que introdujera el código 2FA para terminar la activación del servicio, así que añadimos un nuevo endpoint que comprobara dicha clave.

Ahora ya solo nos quedaba aplicar el 2FA a nuestro proceso de registro en el panel de control. Con un sistema de registro de usuarios, y un endpoint ya implementado para ello, hubo que bucear en las tripas del mismo para interrumpir el proceso establecido de registro por usuario y contraseña, y poder revisar si el usuario tiene o no el 2FA activado. En el caso de tenerlo, se indica el proceso de registro mediante el uso de cabeceras especiales en la petición, que debe mostrar y recoger un cuadro para la introducción del código. Este, una vez recepcionado por la API, verifica al usuario y le deja acceder.

Como se puede ver, se trata de un proceso muy sencillo, pero que aporta una capa de seguridad. Como todo en Transparent Edge Services, este sistema está sujeto a mejoras que ya estamos considerando, como, por ejemplo, que los administradores de las compañías puedan ver cuáles de sus usuarios tienen el 2FA activo, teniendo de esta manera más control sobre la seguridad que aplican sus empleados y compañeros.

Ricardo Amador es jefe de Desarrollo de Transparent Edge Services.

Si Richi no hubiera sido ingeniero de Telecomunicaciones, hubiera sido actor de doblaje. La duda es si habría sido igual de bueno en ello que lo es con Python y Django. Graduado por la Universidad Politécnica de Madrid, se marchó antes de ello a Suecia a especializarse en sistemas integrados inteligentes. A día de hoy, no hay quien le tosa programando APIs y diseñando software para la única CDN española. Excelente jugador de balonmano perseguido por las lesiones, es también uno de esos moteros que siente la carretera sin presumir de ello.