Okta FastPass es el autenticador resistente al phishing de Okta disponible en dispositivos iOS, macOS, Windows y Android. Hace unos años, algunos de nuestros clientes informaron que FastPass no funcionaba correctamente en ciertos entornos virtuales de Windows. Nos propusimos identificar y resolver los problemas, lo que demostró ser un desafío muy interesante.
En esta publicación de blog, nos centraremos en Okta Verify y FastPass para Windows. Exploraremos por qué no funcionó en ciertos entornos virtuales y cómo los ingenieros de Okta resolvieron creativamente los desafíos técnicos para llevar nuestro autenticador a entornos virtuales.
Para obtener más información sobre FastPass, consulte nuestro análisis profundo de FastPass y nuestro documento técnico de FastPass.
¿Por qué FastPass no funcionó en entornos virtuales?
Hay dos motivos principales por las que FastPass no funcionó bien en entornos virtuales. El primero tuvo que ver con algunas de sus dependencias en el dispositivo y, la segunda, con la verificación del usuario con Windows Hello. Exploraremos cada uno de estos problemas en detalle, pero, antes, veamos los tipos de entornos virtuales y cómo difieren.
¿Qué son las VDI?
VDI significa “infraestructura de escritorio virtual”. Es un término que abarca cualquier infraestructura de virtualización diseñada para dar a los usuarios acceso a una máquina virtual en forma de escritorio. El término VDI puede referirse tanto a la infraestructura como al escritorio al que se conecta un usuario.
Tipos de VDI
Existen tres tipos principales de VDI:
- Persistente
- No persistente
- En capas
VDI persistentes
Una VDI persistente es aquella en la que el estado de la VDI y todos los datos del usuario se mantienen entre sesiones. Por ejemplo, cuando un usuario crea una máquina virtual en su computadora portátil, funciona como una VDI persistente. Cada vez que el usuario se conecta, se conserva el estado de su escritorio y todos sus datos.
En un entorno donde hay múltiples usuarios y múltiples máquinas virtuales, el usuario normalmente se asigna estáticamente a la máquina. Esto significa que un usuario se conecta a la misma máquina virtual cada vez que inicia sesión. Por esta razón, las VDI persistentes a veces también se denominan VDI estáticas.
VDI no persistentes
En una VDI no persistente, el estado de la máquina virtual, incluidos todos los datos del usuario, no persiste entre sesiones. La máquina virtual se borra o se restaura desde una nueva imagen principal entre sesiones. En la mayoría de los entornos, hay un grupo de máquinas virtuales nuevas desde el cual se selecciona aleatoriamente la máquina del usuario. En un entorno de VDI no persistente, lo más probable es que el usuario se conecte a una máquina virtual diferente cada vez que inicia sesión.
VDI en capas
Algunos proveedores de infraestructura ofrecen un tercer tipo de VDI, que es un híbrido entre la VDI persistente y la no persistente. Estos entornos se dividen normalmente en capas distintas. Existe una capa de usuario, una capa de aplicación, una capa de máquina, etc. Por esta razón, llamamos a estos entornos “VDI en capas”. En un entorno de VDI en capas, el usuario se conecta a una máquina virtual no persistente, pero un servicio de perfil de usuario sincroniza los datos del usuario para que se conserven entre sesiones. Al igual que en un entorno de VDI no persistente, lo más probable es que el usuario se conecte a una máquina virtual diferente cada vez que inicia sesión. Pero, al igual que con una VDI persistente, sus datos se conservan entre sesiones.
Los entornos de VDI en capas son el tipo de entorno virtual más difícil en cuanto a compatibilidad, ya que el usuario se desplaza entre máquinas virtuales. Nos centraremos en los desafíos técnicos de la compatibilidad con las VDI en capas y, luego, analizaremos brevemente qué desafíos y soluciones también se utilizaron para la compatibilidad con las VDI estáticas.
Compatibilidad con VDI en capas
Para lograr la compatibilidad con los entornos de VDI en capas, se debían abordar cuatro componentes de Okta Verify y FastPass:
- La cuenta de servicio utilizada para proteger el par de claves criptográficas de prueba de posesión.
- Las claves criptográficas protegidas por TPM.
- La credencial localmente persistente de Okta Verify.
- La información de identificación del dispositivo remitida al backend de Okta.
Analizaremos cada uno de estos componentes en detalle.
La cuenta de servicio de Okta Verify
Uno de los pares de claves criptográficas que Okta Verify utiliza para la autenticación es el par de claves de prueba de posesión (PoP). La clave de PoP se puede utilizar para la autenticación silenciosa de un solo factor sin interacción del usuario. Por lo tanto, debe protegerse para garantizar que otro proceso en la máquina no pueda tener acceso a ella y usarla sin el conocimiento del usuario. En el pasado, Okta Verify creaba una cuenta local de Windows que se utilizaba para proteger la clave de PoP. Llamamos a esta cuenta el servicio de Okta Verify o la cuenta de entorno de prueba. Okta Verify suplanta la cuenta de servicio durante las operaciones de la clave de PoP. Dado que esta cuenta es una cuenta de usuario local, no puede desplazarse con el usuario entre máquinas virtuales en un entorno de VDI en capas.
Nuestra solución para proteger la clave de PoP en entornos virtuales fue usar la protección de clave con código de acceso. Al iniciar la aplicación, Okta Verify deriva un código de acceso de protección de clave. Cuando Okta Verify crea una clave de PoP con las API Win32, utilizamos la función NCryptSetProperty con el identificador NCRYPT_PIN_PROPERTY para establecer la propiedad del PIN en el identificador de la clave, y proporcionamos nuestro código de acceso de protección de clave. Al configurar esta propiedad, se le indica al sistema operativo que cree una clave que esté protegida por nuestro código de acceso de protección de clave. Después de la creación, cuando se utiliza la clave, se debe proporcionar el código de acceso correcto. Esto impide que otros procesos en la máquina carguen y utilicen la clave de PoP, ya que no tienen el código de acceso de protección de clave.
Las claves criptográficas protegidas por TPM.
Okta Verify protege las claves criptográficas que crea con el módulo de plataforma segura (TPM) de la máquina si está disponible. Incluso en múltiples entornos virtuales, Okta Verify protegerá las claves con el TPM, ya que muchos entornos virtuales tienen TPM virtuales. Sin embargo, en un entorno de VDI en capas, Okta Verify no puede utilizar el TPM para proteger sus claves. Cuando Okta Verify protege sus claves con un TPM, esas claves están enlazadas criptográficamente a ese TPM. Si Okta Verify se traslada a una máquina diferente con un TPM diferente, como es el caso en un entorno de VDI en capas, no puede acceder a las claves que creó y no puede autenticar al usuario.
Nuestra solución, en entornos de VDI en capas, fue que Okta Verify almacene sus claves criptográficas en un proveedor de almacenamiento de claves de software en un formato no exportable. El proveedor de almacenamiento de claves de software se proporciona e implementa mediante el sistema operativo Windows, que almacena las claves como un archivo en el directorio del usuario. Cuando el servicio de sincronización de perfiles de usuario de la VDI en capas sincroniza el directorio del usuario, se sincronizan todas las claves del usuario guardadas en el almacén de claves de software. Consulte la documentación sobre almacenamiento de claves de Microsoft para obtener más información.
Credencial de Okta Verify
Okta Verify almacena una credencial de aplicación en el administrador de credenciales de Windows, que se utiliza para proteger los recursos de la aplicación. Okta Verify solía configurar siempre la propiedad Persist de la credencial como CRED_PERSIST_LOCAL_MACHINE, lo que hacía que la credencial persistiera en la máquina local. Okta Verify no puede acceder a una credencial persistente a nivel local en una máquina virtual diferente.
Nuestra solución fue configurar la propiedad Persist en CRED_PERSIST_ENTERPRISE para permitir que la credencial se desplace con el perfil del usuario entre máquinas virtuales en un entorno de VDI en capas.
Información del dispositivo
Okta Verify recopila dos datos de identificación del dispositivo que se remiten al backend de Okta:
- El nombre del dispositivo.
- El identificador de seguridad (SID) del dispositivo.
En entornos de VDI en capas, ambos identificadores de dispositivo pueden cambiar entre sesiones, lo que podría provocar un comportamiento inesperado (por ejemplo, una autenticación fallida).
Nuestra solución para remitir identificadores de dispositivos coherentes en entornos de VDI en capas fue usar el SID del usuario como identificador básico, ya que no cambia entre sesiones. A partir de él, derivamos un nombre de dispositivo y lo remitimos directamente como SID del dispositivo.
Después de que abordamos cada uno de estos elementos, Okta Verify estaba listo para entornos virtuales. Sin embargo, FastPass todavía no lo estaba. Los usuarios seguían sin poder completar la verificación de usuario, por lo que todavía teníamos trabajo por hacer.
Verificación de usuario (UV) en entornos virtuales
La verificación de usuario es el proceso por el cual un autenticador (p. ej., Okta FastPass) verifica que el usuario está presente y es quien dice ser.
FastPass utiliza Windows Hello para la verificación de usuario, lo que le permite al usuario comprobar su identidad con un PIN o verificación biométrica. Sin embargo, la mayoría de las máquinas virtuales no tienen Windows Hello. Para permitir a los usuarios completar la autenticación de dos factores con la verificación de usuario en entornos virtuales, presentamos la función Okta Verify Passcode.
Inscripción en FastPass
Durante la inscripción en FastPass, se le pide al usuario que cree un código de acceso de ocho dígitos dentro de Okta Verify.
Cuando Okta Verify crea el par de claves criptográficas de verificación de usuario, utilizamos las mismas API Win32 para configurar la propiedad NCRYPT_PIN_PROPERTY en el identificador de la clave, y damos el código de acceso del usuario como valor. Esto significa que solo se puede acceder a la clave de verificación de usuario cuando se proporciona el código de acceso del usuario. Okta Verify no almacena el código de acceso del usuario. Simplemente lo transmite al sistema operativo a través de las API Win32.
Autenticación con FastPass
Durante la autenticación, Okta Verify le pide al usuario que ingrese su código de acceso para completar la verificación de usuario.
Cuando Okta Verify carga la clave de verificación de usuario para firmar el JWT del desafío de autenticación, volvemos a configurar la propiedad NCRYPT_PIN_PROPERTY en el identificador de la clave, y damos el código de acceso que proporcionó el usuario. El sistema operativo gestiona la verificación para garantizar que el usuario haya proporcionado el código de acceso correcto.
Código incorrecto
Si el usuario ingresa un código de acceso incorrecto, se le permite un máximo de dos intentos más antes de que ocurra un error en la solicitud de autenticación.
Dado que Okta Verify no almacena el código de acceso del usuario, no puede detectar directamente un código de acceso incorrecto. En cambio, gestiona los errores del proveedor de almacenamiento de claves para determinar cuándo el código de acceso ingresado por el usuario es incorrecto y, luego, le muestra al usuario el error de código de acceso incorrecto. El desafío radica en que el error que aparece varía en función del proveedor de almacenamiento de claves.
Cuando la clave se almacena en el proveedor de software, el código de error NTE_INCORRECT_PASSWORD (0x80090033) aparece cuando abrimos la clave y configuramos un valor incorrecto de NCRYPT_PIN_PROPERTY en el identificador de la clave. Esto nos permite detectar fácilmente cuando el usuario ingresa un código incorrecto.
Sin embargo, el comportamiento del TPM es diferente. Primero, no aparece ningún código de error cuando se abre la clave y se configura un valor incorrecto en la propiedad NCRYPT_PIN_PROPERTY en el identificador de la clave. En cambio, aparece un código de error después, cuando se utiliza el identificador de la clave (por ejemplo, para realizar el hash de algunos datos). Segundo, el código de error que aparece no es NTE_INCORRECT_PASSWORD, sino NTE_PERM (es decir, acceso denegado, 0x80090010).
Dado que el error de acceso denegado es un error genérico que puede surgir en una variedad de otros contextos, no podemos simplemente manejar todos los errores de acceso denegado como intentos de contraseña incorrecta por parte del usuario. Más bien, tenemos que manejar los errores de acceso denegado según el contexto de la operación. Si recibimos el error de acceso denegado al intentar usar una clave de verificación de usuario que sabemos que está protegida por un código de acceso proporcionado por el usuario, manejamos el error como un error de código de acceso incorrecto y permitimos que el usuario vuelva a ingresar su código de acceso.
Compatibilidad con VDI estáticas
La compatibilidad con las VDI estáticas fue mucho más sencilla, pues funcionan de manera muy similar a las máquinas físicas. Una vez que resolvimos los desafíos de compatibilidad con las VDI en capas, pudimos reutilizar algunas de las soluciones para ofrecer compatibilidad con las VDI estáticas. El principal desafío de compatibilidad con una VDI estática es la verificación de usuario. Para resolver esto, utilizamos el código de acceso de Okta Verify para la verificación de usuario en las VDI estáticas.
Acerca de la compatibilidad con VDI no persistentes
Okta Verify no es compatible con las VDI no persistentes, ya que no se conserva ningún dato del usuario entre sesiones, incluidos los datos de Okta Verify. Si un usuario intentara inscribirse en FastPass en una VDI no persistente, su inscripción se perdería después de cerrar sesión y volver a abrirla.
Configuración de Okta Verify para entornos virtuales
A fin de permitir que los administradores configuren Okta Verify para entornos virtuales, agregamos un nuevo indicador de configuración llamado AuthenticatorOperationMode. Tiene tres valores:
- Normal
- VirtualDesktopStatic
- VirtualDesktopLayered
Consulte nuestra documentación para obtener más información sobre cómo configurar Okta Verify para entornos virtuales.
A fin de permitir que los administradores configuren Okta Verify para usar el código de acceso de Okta Verify en la verificación de usuario, agregamos un nuevo indicador de instalación llamado UserVerificationType. Tiene dos valores:
- Windows Hello
- OktaVerifyPasscode
Para facilitar la vida de los administradores, ajustamos el valor predeterminado del indicador UserVerificationType según el valor proporcionado para el indicador AuthenticatorOperationMode.
- Cuando el modo es Normal, el valor predeterminado de UserVerificationType es WindowsHello.
- Cuando el modo es VirtualDesktopStatic o VirtualDesktopLayered, el valor predeterminado de UserVerificationType es OktaVerifyPasscode.
Si desea configurar Okta Verify para que se ejecute en un entorno virtual y usar el código de acceso de Okta Verify para la verificación de usuario, el administrador solo necesita configurar correctamente AuthenticatorOperationMode, y UserVerificationType se configurará automáticamente como OktaVerifyPasscode.
Consulte nuestra documentación para obtener más información sobre cómo configurar el tipo de verificación de usuario en Okta Verify.
Acerca de los nuevos indicadores de instalación
Dado que los indicadores de instalación AuthenticatorOperationMode y UserVerificationType modifican la funcionalidad básica de Okta Verify, sus valores se configuran una sola vez durante la instalación. Cualquier cambio en sus valores después de la instalación no surte efecto. Esto se hace para evitar que Okta Verify funcione incorrectamente. Sin embargo, algunos clientes han manifestado recientemente un interés por migrar a sus usuarios de un tipo de verificación de usuario a otro después de la instalación.
El código de acceso de Okta Verify en lugar de Windows Hello para máquinas físicas
A veces, los administradores no quieren que sus usuarios utilicen Windows Hello, o a veces los usuarios no pueden utilizar Windows Hello, incluso en máquinas físicas. Por eso, diseñamos la función de código de acceso de Okta Verify para que funcione también en máquinas físicas. El parámetro UserVerificationType se puede configurar de manera independiente de AuthenticatorOperationMode para habilitar la verificación de usuario con el código de acceso de Okta Verify en máquinas físicas.
Consulte nuestra documentación para obtener más información.
Realice una prueba
¿Le interesa probar esta funcionalidad? Puede descargar la última versión de Okta Verify para Windows desde el panel de administración. Asegúrese de seguir nuestras instrucciones sobre cómo configurar Okta Verify para entornos virtuales y cómo configurar el tipo de verificación de usuario.
¿Tiene preguntas sobre esta publicación de blog? Comuníquese con nosotros a eng_blogs@okta.com.
Explore más blogs de ingeniería con información útil de Okta para ampliar sus conocimientos.
¿Tiene lo necesario para unirse a nuestro apasionado equipo de ingenieros excepcionales? Visite nuestra página de empleos.
Aproveche el potencial de la gestión de identidades moderna y sofisticada para su organización. Comuníquese con el equipo de ventas para obtener más información.
