Roman Kuznetsov¿Dónde está la MFA sin contraseña para Windows?
Sin contraseña es una palabra de moda muy ruidosa en el mundo moderno de la autenticación, con distintos enfoques que encuentran su lugar sobre todo en productos basados en la web (piense en las passkeys). Por desgracia, los entornos de dominio Windows no han contado con soporte nativo para una MFA real, si no tenemos en cuenta la MFA basada en Azure y Windows Hello for Business, por lo que la mayoría de los proveedores externos ofrecen soporte de MFA para Windows en combinación con un enfoque basado en contraseña.
Solo hay muy pocas soluciones en el mercado que ofrezcan una auténtica MFA sin contraseña para Microsoft Active Directory local, y SystoLOCK es la única que es totalmente autónoma, autoalojada, no depende de ningún servicio en la nube y admite todos los escenarios de uso habituales, desde el inicio de sesión en el sistema, pasando por la suplantación y el acceso a recursos compartidos de red, hasta el acceso RDP y VPN.
¿En qué se diferencia SystoLOCK de la MFA tradicional?
El enfoque de SystoLOCK respecto a la MFA es muy diferente al de la mayoría de proveedores: aunque es un auténtico sistema de MFA, es decir, utiliza 2 de los 3 factores para autenticar a un usuario, no depende de la contraseña del usuario para hacerlo, ni gestiona ninguna rotación de contraseñas en segundo plano. Más concretamente, mantiene conjuntos separados de credenciales criptográficas que están desvinculadas del objeto de usuario en Active Directory y se verifican en el momento del inicio de sesión. Tras verificar correctamente estas credenciales, SystoLOCK inscribe un certificado de corta duración (válido únicamente para ese único inicio de sesión) para el usuario y presenta este certificado al controlador de dominio, donde tiene lugar la autenticación final. A continuación se muestra un diagrama de todo el proceso:
SystoLOCK se basa en instancias reforzadas de AD CS, diseñadas para atender únicamente sus propias solicitudes.
Es importante destacar que este enfoque no se detiene en la pantalla de inicio de sesión, sino que se extiende a todas las solicitudes de credenciales posteriores, incluidos el acceso a la red, la suplantación de usuario y la elevación de privilegios:
¿Y qué pasa con la contraseña? Pues bien, SystoLOCK es esencialmente una tarjeta inteligente virtual y se presenta como tal ante el sistema. Por lo tanto, podemos aplicar una configuración de cuenta de “tarjeta inteligente obligatoria” al objeto de usuario en AD, lo que impide eficazmente cualquier autenticación basada en contraseña y cualquier ataque de fuerza bruta o robo de credenciales.
SystoLOCK para RDP: armonía repentina
Iniciar sesión en una sesión RDP nunca ha sido un proceso trivial cuando se hace correctamente. Cuando se intenta añadir MFA al proceso, salen a la luz aún más problemas y, con un requisito de NLA, se puede acabar atascado en la resolución de problemas. Con los proveedores tradicionales de MFA, normalmente se utilizaría la contraseña en el aviso local de RDP, si está configurado para ello, y luego se completaría el segundo paso del proceso de MFA en la pantalla remota. Simplemente no hay lugar en la arquitectura del protocolo RDP para las credenciales de MFA, de ahí esta dualidad.
Cuando diseñamos SystoLOCK, quisimos simplificar la experiencia de usuario y eliminar esta dualidad. El flujo resultante es exactamente eso: se proporcionan las credenciales una sola vez y, a continuación, se accede a la sesión RDP sin necesidad de un segundo paso; ya sea que se aplique NLA o no, la experiencia siempre se asemeja al inicio de sesión único.
Otro aspecto importante del soporte de RDP es la prevención del robo de credenciales. Si utiliza un enfoque sencillo basado en contraseña o una MFA tradicional y su cliente o host se ve comprometido, la contraseña que introduce en el aviso de autenticación de RDP puede ser robada, a menos que Credential Guard esté implementado en el lado del servidor. El panorama también es sombrío en cuanto a los robos de contraseñas en el lado del cliente. Con SystoLOCK, dado que las contraseñas se eliminan de manera efectiva de los objetos de usuario y los certificados utilizados son de corta duración (con sus claves privadas inaccesibles), no hay forma de que un atacante comprometa la sesión RDP.
Y, por supuesto, ¡es compatible con Devolutions Remote Desktop Manager de forma inmediata!
Ordenadores sin conexión y trabajadores remotos
Dado que cada inicio de sesión da lugar a la emisión y verificación de un nuevo certificado, durante el inicio de sesión se requiere una conexión al servidor de SystoLOCK, a un servidor de certificados y a un controlador de dominio. Esto puede ser un problema para quienes viajan o trabajan desde casa y no disponen de una VPN. Aquí se utiliza un enfoque diferente para superar esta carencia. Mientras que los casos de uso descritos anteriormente podrían simplemente utilizar un OTP, el inicio de sesión sin conexión requiere el uso de un smartphone para iniciar sesión. Las credenciales almacenadas en caché, una función de Windows, también deben estar habilitadas para que funcionen los inicios de sesión sin conexión; sin embargo, esta opción suele estar habilitada.
Una vez que un usuario ha iniciado sesión correctamente con anterioridad en un ordenador utilizando SystoLOCK (y ese ordenador ha sido configurado por un administrador para permitir inicios de sesión sin conexión), dicho ordenador intercambiará cierta información criptográfica con el servidor de SystoLOCK y almacenará las claves criptográficas del smartphone para su uso posterior.
Cuando el usuario intenta iniciar sesión sin conexión, el ordenador, incapaz de comunicarse con el servidor, se comunica en su lugar con el smartphone mostrando un código QR. Al escanear este código QR, el smartphone inicia una verificación de credenciales en el servidor, actuando como el enlace de red que falta entre el ordenador y el servidor de SystoLOCK. Si el servidor no está disponible, el smartphone verificará criptográficamente la identidad del ordenador y del usuario, si está configurado para ello. Si la verificación se realiza correctamente, el teléfono mostrará un código numérico que debe introducirse en el ordenador. Después de que el usuario introduzca este código en el aviso de inicio de sesión sin conexión, el proceso de inicio de sesión se completa. Para el usuario, el inicio de sesión sin conexión no parece muy diferente del inicio de sesión en línea, lo que lo convierte en una experiencia fluida:
Trabajar sin conexión no siempre significa estar completamente desconectado de la infraestructura de la oficina. En algunos casos, simplemente significa establecer una VPN antes de iniciar una aplicación de oficina o una sesión RDP. SystoLOCK ofrece distintos enfoques para lograr la conectividad requerida.
Un enfoque consiste en controlar los clientes VPN compatibles. El cliente VPN de Microsoft y el cliente AnyConnect de Cisco son compatibles de forma nativa con SystoLOCK. El único requisito es que la puerta de enlace VPN acepte certificados de usuario para la autenticación y sea capaz de verificarlos frente a Active Directory. El otro enfoque consiste en utilizar nuestro complemento genérico de servidor RADIUS, diseñado para ejecutarse bajo un componente NPS en un servidor Windows.
Si tiene la suerte de utilizar los clientes VPN compatibles de forma nativa, puede aprovechar la compatibilidad de SystoLOCK con PLAP y conectarse a la VPN e iniciar sesión en el ordenador en un solo paso:
¿Qué falla en la 2FA tradicional?
Aunque “2FA” es un acrónimo de autenticación de dos factores, a veces se utiliza para referirse a la llamada autenticación en dos pasos. Aquí es donde reside el principal problema: la autenticación realizada de esta manera no es principalmente de dos factores, sino que se lleva a cabo en dos pasos: el primero es la autenticación real, y el segundo es una forma de confirmación que incluso se puede activar y desactivar o configurar.
Aplicado a un inicio de sesión en Windows o RDP, esto significa que el usuario primero proporcionaría su contraseña, se llevaría a cabo la autenticación real frente a un controlador de dominio y, a continuación, si este primer paso se realiza correctamente, se realizaría alguna forma de verificación adicional. Esta verificación, si hablamos de inicios de sesión locales o RDP, generalmente se realiza “inyectando” una pantalla adicional justo antes de que se inicie el shell del usuario, y esa pantalla se utiliza para comunicar el segundo factor. El truco es sencillo: si la verificación falla en este punto, el shell del usuario nunca se inicia y la sesión de inicio de sesión se aborta.
La mayoría de los proveedores tradicionales de MFA, incluidos Duo, Thales, etc., utilizan este truco para realizar la verificación del segundo paso, dependiendo así, en primer lugar, de una autenticación basada en contraseña exitosa.
El primer problema de este enfoque es que solo puede aplicarse al proceso de inicio de sesión. Si a continuación necesita acceder a un recurso compartido de ficheros o ejecutar un programa como administrador, se queda sin ese segundo paso de verificación. Esto puede ser un problema en sí mismo (¡piense en el cumplimiento normativo!), pero da lugar a otros problemas más importantes:
- La mayoría de los demás dispositivos de su dominio que no son compatibles con MFA todavía pueden sufrir ataques de fuerza bruta, y en algún momento los sufrirán si un dispositivo de su red “atrapa” un virus.
- Los usuarios elegirán contraseñas más sencillas porque se sienten más seguros utilizando 2FA al iniciar sesión, lo que facilita los ataques de fuerza bruta.
- Las sesiones RDP pueden ser secuestradas y las credenciales de contraseña robadas si el cliente o el servidor RDP se ven comprometidos. Estas contraseñas podrían utilizarse después contra esos nodos que no son compatibles con MFA.
Estos son solo algunos de los problemas asociados a la autenticación en dos pasos; otro buen ejemplo es la “fatiga de MFA”, también conocida como ataque de bombardeo de MFA, el tipo de ataque que se utilizó en el hackeo de Uber en septiembre de 2022. Este ataque y otros similares llevaron a algunos investigadores de Bleeping Computer, Sentinel One y PC Magazine a cuestionar incluso la eficacia general de la MFA.
Enfoque universal y perspectivas de futuro
Las cuentas de dominio de usuario de Windows son el núcleo de la experiencia del usuario. Se utilizan de muchas formas diferentes en muchos escenarios distintos, y estos escenarios varían en complejidad y enfoque. No se trata solo del inicio de sesión y RDP; SystoLOCK es capaz de comunicarse con ADFS, por ejemplo, lo que abre el camino a un inicio de sesión sin contraseña en Office 365 con usuarios gestionados localmente, y puede indicar a RD Gateway y RDWeb que realicen un SSO frente a una granja de aplicaciones publicadas. Y, por supuesto, SystoLOCK cuenta con su propia aplicación de autenticación móvil que puede sustituir a todos los demás autenticadores que haya conocido hasta ahora. Aquí puede encontrar una variedad de módulos de SystoLOCK disponibles para distintos componentes de Windows.
El objetivo principal de SystoLOCK es eliminar las contraseñas, ofreciendo al mismo tiempo la mejor experiencia de usuario y sin depender de ningún servicio en la nube. SystoLOCK lo consigue transformando un conjunto de credenciales en otro. Esta transformación implica que el conjunto inicial puede variar y, aunque todavía no es compatible, estamos trabajando para incorporar tokens FIDO2 y otros medios de autenticación al flujo de trabajo.
Cada vez es más evidente que el futuro de la autenticación no requiere contraseñas. SystoLOCK está ahí para respaldar esta transición en el lado de Windows, donde Microsoft no ha logrado hasta ahora ofrecer un enfoque adecuado para la MFA moderna.
Más información:
- Sitio del producto: SystoLOCK.com
- Programe una demostración de SystoLOCK
- Demostraciones de uso en una lista de reproducción de YouTube
- Folleto de SystoLOCK
- Certificado de prueba de penetración
- Contactos: a través de la web o LinkedIn