¿Para qué proteger una contraseña si puedes prescindir de ella?

Un problema que hemos llegado a considerar normal

Prácticamente todas las aplicaciones web tienen un panel de administración. Y, por regla general, ese panel tiene una dirección de acceso, un formulario de autenticación, un nombre de usuario y una contraseña.

Nos hemos acostumbrado tanto a este esquema que prácticamente hemos dejado de preguntarnos: ¿tiene que funcionar todo necesariamente así?

Cuando tienes un solo sitio, el problema no parece importante. Creas una contraseña compleja, activas la autenticación de dos factores, configuras un límite de intentos de inicio de sesión y listo.

Pero ¿qué pasa cuando tienes diez, veinte o treinta proyectos?

En mi caso, se trata del ecosistema DigiMeld, que reúne más de treinta proyectos de software independientes. Cada uno tiene su propia arquitectura, lógica de servidor e interfaz administrativa.

Por tanto, cada uno necesita un mecanismo de acceso administrativo.

Durante mucho tiempo utilicé un enfoque bastante habitual: credenciales administrativas independientes, contraseñas complejas y guardarlas en el navegador.

Funcionaba.

Pero en cierto momento me pregunté: ¿por qué tengo que guardar tantas contraseñas administrativas? ¿Por qué tengo que proteger no solo los servidores, sino también los propios medios para acceder a ellos?

¿Y no podría prescindir de esa necesidad?

Llegué a una idea que más tarde se convirtió en la base de mi solución:

Quizá convenga proteger no un punto de acceso permanente, sino el derecho a obtener acceso temporalmente.

Una contraseña compleja no elimina el problema de fondo

Las herramientas actuales permiten crear contraseñas con una entropía muy alta. Una contraseña larga y aleatoria generada correctamente es prácticamente imposible de adivinar mediante fuerza bruta.

Pero, por compleja que sea, hay que guardarla en algún sitio y luego utilizarla.

Se pueden usar gestores de contraseñas, llaves físicas, autenticación multifactor y restricciones adicionales. Todo ello, sin duda, mejora la seguridad.

Sin embargo, la estructura arquitectónica sigue ahí: existe una interfaz determinada a través de la cual el usuario presenta sus credenciales.

Se le pueden enviar solicitudes. Se puede escanear. Puede convertirse en objetivo de ataques automatizados.

Se puede ocultar la dirección del panel de administración, sustituir la ruta estándar por una larga secuencia aleatoria de caracteres o restringir el acceso por IP.

Pero entonces surge otra pregunta: ¿dónde guardar esa dirección y cómo utilizarla?

Y, lo más importante, ¿por qué conservar un punto de acceso permanente si solo se necesita acceso administrativo en determinados momentos?

Llegué a una idea que más adelante se convirtió en la base de mi solución:

Quizá convenga proteger no un punto de acceso permanente, sino el derecho a obtener acceso temporalmente.

¿Y si no hubiera una página de inicio de sesión convencional?

Decidí abandonar el modelo tradicional de autenticación administrativa en mis proyectos.

No limitarme a ocultar el formulario de inicio de sesión.

No cambiar la dirección.

No sustituir la contraseña por otra aún más compleja.

Sino eliminar la necesidad de mantener un acceso mediante contraseña de forma permanente.

Por supuesto, las interfaces administrativas no desaparecieron. Siguen siendo necesarias para gestionar las aplicaciones.

Lo que cambió fue la forma de acceder a ellas.

Ahora, para iniciar sesión en los paneles administrativos de los proyectos conectados, no hace falta introducir un nombre de usuario y una contraseña guardados.

En su lugar, utilizo mi propio sistema de identificación y gestión de acceso, MeldID.

La idea es bastante sencilla: el acceso administrativo se concede solo cuando realmente se necesita, a un usuario concreto y para un proyecto concreto.

Además, tener una cuenta no implica por sí mismo el derecho a abrir el panel de administración.

Ese derecho debe concederse por separado.

Un acceso que no existía hace un minuto

Probablemente, esta sea la parte más interesante de todo el concepto.

En el modelo tradicional, el administrador siempre dispone de medios para iniciar sesión. Puede utilizarlos hoy, mañana o dentro de un mes, mientras sigan siendo válidos.

Decidí cambiar este principio.

En lugar de credenciales administrativas permanentes, se utiliza la posibilidad temporal de iniciar sesión.

Esta se genera a petición mediante un dispositivo móvil de confianza, incluye un componente aleatorio criptográficamente robusto y tiene una validez limitada.

Pero ni siquiera disponer de ese enlace temporal significa por sí solo que se obtenga acceso.

Este es un punto fundamental.

Supongamos que alguien consigue el enlace de alguna manera. En un sistema convencional basado exclusivamente en mantener la dirección en secreto, esa filtración podría convertirse en un problema grave.

En mi modelo, el enlace solo permite iniciar el procedimiento de confirmación.

Para continuar, se necesita una autorización independiente a través de un dispositivo móvil de confianza con MeldID.

Sin la confirmación correspondiente, no se crea una sesión administrativa.

Por eso no considero el enlace temporal un sustituto de la contraseña, sino uno de los elementos del procedimiento para conceder acceso.

Saber adónde acudir y tener derecho a entrar son cosas completamente distintas.

El teléfono se convierte en una herramienta de gestión del acceso

En este modelo, el dispositivo móvil desempeña un papel mucho más importante que el de un simple generador de códigos de un solo uso.

Se utiliza para confirmar acciones relacionadas con el acceso administrativo.

Cuando quiero abrir el panel de administración, el sistema solicita una confirmación a través de MeldID.

Veo la solicitud correspondiente en un dispositivo de confianza y confirmo la acción.

Solo después de verificarla correctamente, el sistema permite continuar con el procedimiento de inicio de sesión.

Además, la confirmación está vinculada a una acción concreta, no simplemente al hecho de que el teléfono se haya desbloqueado.

La biometría del móvil verifica al usuario localmente, mientras que el servidor comprueba la confirmación criptográfica del dispositivo registrado.

Este enfoque permite no depender exclusivamente de una contraseña ni de un mensaje que afirme que el usuario supuestamente ha confirmado el inicio de sesión.

Y aquí aparece otra ventaja: es posible gestionar los dispositivos de confianza.

Si un dispositivo ya no debe utilizarse para confirmar el acceso, se puede revocar su condición de dispositivo de confianza.

A partir de ese momento, deja de ser un medio válido para autorizar las operaciones correspondientes.

Un sistema para muchos proyectos independientes

Cuando empecé a desarrollar este mecanismo, uno de mis principales objetivos era mantener la independencia de cada proyecto.

No quería unir todos los paneles administrativos en una única aplicación enorme.

Cada servicio de DigiMeld debía seguir gestionando su propia lógica, configuración, usuarios y datos.

Por eso separé dos tareas.

MeldID se encarga de la identificación y de conceder el permiso de acceso administrativo.

El proyecto en sí se encarga de sus propias funciones administrativas y de verificar los permisos vigentes.

Así obtuve un modelo centralizado de gestión del acceso sin necesidad de centralizar las propias aplicaciones.

Además, los permisos se conceden por separado.

El administrador de un proyecto no obtiene acceso automáticamente a los demás solo por tener una cuenta de MeldID.

Se puede definir un grupo específico de usuarios autorizados para cada área administrativa.

Al mismo tiempo, los derechos de los usuarios normales y los privilegios administrativos se mantienen separados.

Esto resultó especialmente práctico para un ecosistema formado por decenas de servicios.

Por qué prefiero el acceso temporal al permanente

Hay otro principio que incorporé deliberadamente al sistema.

El acceso administrativo no debe mantenerse indefinidamente.

La autorización tiene una duración limitada y caduca independientemente de que el usuario siga trabajando en el navegador.

Para continuar trabajando una vez vencido el plazo, hay que iniciar un nuevo procedimiento de confirmación.

Esto permite evitar que una autorización concedida una vez se convierta en un permiso permanente.

Pero limitar el tiempo no es suficiente.

También es importante poder cancelar antes de tiempo el acceso ya concedido.

Por eso MeldID incluye la revocación centralizada de los permisos administrativos.

Cuando se revoca un permiso, los proyectos conectados reciben el evento correspondiente y anulan las sesiones administrativas asociadas.

De este modo, la gestión del acceso no termina en el momento en que el usuario inicia sesión correctamente.

Para mí, poder revocar los permisos es tan importante como poder concederlos.

Al mismo tiempo, un sistema distribuido debe tener en cuenta los retrasos en la transmisión de eventos, la disponibilidad temporal de algunos componentes y otras circunstancias operativas. La duración limitada de las sesiones proporciona una salvaguarda adicional.

¿Qué ha cambiado en el trabajo diario?

Ante todo, ya no hace falta recurrir constantemente a las contraseñas administrativas guardadas.

Ya no necesito tener en el navegador un conjunto de credenciales para iniciar sesión en cada panel administrativo conectado.

En su lugar, gestiono los permisos mediante un mecanismo único.

Elijo el proyecto que necesito, confirmo el acceso y trabajo.

Cuando ya no necesito el acceso administrativo, puedo revocarlo.

También es especialmente práctico que, al aparecer un proyecto nuevo, no haya que volver a diseñar todo el sistema de autenticación administrativa.

Basta con conectarlo al modelo existente y definir los permisos necesarios.

Por supuesto, esto no significa que hayan desaparecido todos los riesgos de seguridad.

También es necesario proteger los permisos temporales, los dispositivos de confianza, las sesiones del servidor y la infraestructura central.

Pero ya no tengo que resolver la misma tarea de gestión de contraseñas administrativas por separado para cada aplicación.

Y ese era precisamente uno de mis objetivos iniciales.

¿Acaso no existen ya tecnologías similares?

Claro que sí.

La autenticación sin contraseña, la gestión de accesos privilegiados, los permisos temporales y la confirmación mediante dispositivos de confianza llevan mucho tiempo siendo conocidos en el sector de la seguridad de la información.

Estos enfoques aparecen en sistemas de gestión de identidades y accesos (Identity and Access Management), de gestión de accesos privilegiados (Privileged Access Management) y en los conceptos Zero Trust.

No pretendo haber inventado estos principios.

Mi objetivo era otro.

Necesitaba crear un sistema propio e integrado que resolviera problemas concretos de la infraestructura de DigiMeld y permitiera gestionar el acceso administrativo a muchos proyectos independientes.

Como resultado, combiné varios enfoques conocidos en una única arquitectura que se ajustaba a mis requisitos.

Y creo que el valor del trabajo de ingeniería no consiste necesariamente en inventar una tecnología completamente nueva.

A veces consiste en formular el problema correctamente y encontrar una solución adecuada.

MeldID no sirve solo para los paneles administrativos

Conviene hacer aquí una aclaración aparte.

MeldID no se creó únicamente como herramienta para gestionar mi propio acceso administrativo.

También ofrece a los desarrolladores un SDK para integrar mecanismos de identificación y confirmación de inicio de sesión en sus propias aplicaciones.

Además, ese SDK está disponible de forma gratuita.

Por ejemplo, un desarrollador externo puede utilizar MeldID como una capa adicional de confirmación de la autenticación de usuarios.

Aunque la aplicación mantenga el inicio de sesión tradicional con nombre de usuario y contraseña, introducir correctamente esos datos podría no ser suficiente para completar la autenticación.

El usuario recibe una solicitud en un dispositivo móvil de confianza, donde confirma o rechaza el intento de inicio de sesión.

Esto permite reducir el riesgo de acceso no autorizado si las credenciales se ven comprometidas.

Es importante distinguir esta función de acceso público de MeldID del modelo de acceso administrativo que desarrollé para los proyectos de DigiMeld.

Ambos utilizan principios comunes de confianza y confirmación de acciones, pero resuelven problemas diferentes.

La seguridad no consiste solo en proteger lo que ya existe

El trabajo en este sistema me hizo replantearme los mecanismos de autenticación habituales.

A menudo intentamos proteger aquello que existe por razones históricas.

Añadimos nuevas verificaciones, restricciones, contraseñas adicionales y capas de protección.

A veces eso es realmente necesario.

Pero en ocasiones es más útil plantearse otra pregunta:

¿Es imprescindible que el propio mecanismo que protegemos siga existiendo tal como está?

En mi caso, la respuesta fue negativa.

No necesitaba un formulario de acceso administrativo permanentemente disponible.

Necesitaba poder obtener permisos administrativos de forma segura justo cuando fueran necesarios.

Son dos problemas distintos.

Y pasar del primero al segundo cambió no solo la arquitectura técnica, sino también el trabajo diario con los proyectos.

No es un punto final, sino una dirección elegida

Hoy, esta arquitectura ya funciona en una parte considerable del ecosistema DigiMeld.

Los proyectos restantes se están migrando gradualmente al nuevo modelo de acceso administrativo.

Estoy llevando a cabo la migración por etapas, comprobando el funcionamiento de cada aplicación y, cuando termine la transición, tengo previsto realizar una auditoría adicional de todo el sistema.

Algunos elementos de la interfaz y las reglas de gestión de sesiones todavía podrían cambiar.

Pero la idea principal ya está definida.

No quiero volver a un modelo en el que, para gestionar decenas de proyectos propios, tenga que guardar y utilizar constantemente decenas de contraseñas administrativas.

Al mismo tiempo, no considero que mi implementación sea una solución universal para todo el mundo.

Las distintas organizaciones tienen diferentes requisitos, infraestructuras, modelos de amenazas y formas de administración.

Lo que resulta práctico y razonable para el ecosistema DigiMeld no necesariamente será lo más adecuado para otro desarrollador.

Sin embargo, el principio de conceder permisos temporalmente merece atención.

A modo de conclusión

Decidí compartir esta experiencia no porque me considere el inventor de un nuevo método de autenticación.

Ni porque quiera presentar otro sistema como absolutamente seguro.

La seguridad absoluta no existe.

Simplemente, me parece interesante la forma de plantear el problema.

En lugar de proteger indefinidamente un acceso administrativo permanente, podemos replantearnos si es necesario que exista.

En lugar de guardar muchas contraseñas, podemos utilizar permisos temporales.

En lugar de confiar automáticamente tras la primera autenticación, podemos confirmar la concesión de permisos concretos.

En lugar de esperar a que la sesión caduque, podemos prever la posibilidad de revocar el acceso de forma centralizada.

Y, por último, en lugar de utilizar un mecanismo de inicio de sesión distinto en cada proyecto, podemos crear un sistema unificado para gestionar los permisos de acceso administrativo y, al mismo tiempo, mantener la independencia de las aplicaciones.

No afirmo que este enfoque elimine la posibilidad de que el sistema se vea comprometido.

Simplemente desplaza el foco de proteger credenciales que existen de forma permanente a conceder y revocar permisos de manera controlada.

Quizá, a veces, la forma más eficaz de reducir la superficie de ataque no sea añadir otro mecanismo de protección, sino prescindir de aquello sin lo que el sistema puede funcionar perfectamente.

Para mí, la historia de MeldID Admin Gateway comenzó precisamente con esta idea.