¿Cómo funciona la autenticación de la Cuenta Microsoft de Windows 8?

14

Una de las nuevas características de Windows 8 es la capacidad de iniciar sesión en su PC utilizando sus credenciales de una cuenta de Microsoft . ¿Cómo se implementa esto y qué pasos se toman para evitar el secuestro de credenciales en tránsito, autenticación falsificada u otros ataques MITM similares?

Supongo que SSL u otro cifrado & esquema de autenticación utilizado, pero no puedo encontrar ningún detalle sobre lo que incluye, y hasta qué punto ha avanzado MS para prevenir (por ejemplo) SSL y amp; Envenenamiento de DNS.

Edite: RE SSL: ¿qué puede hacer para que un SysAdmin agregue un certificado falso para live.com a las claves públicas de confianza de Windows, ejecute un servidor con la clave privada falsa correspondiente y utilice DNS para redirigir las solicitudes de autenticación?

    
pregunta jackweirdy 30.01.2014 - 18:39
fuente

2 respuestas

6

De hecho, más funciona en la dirección opuesta. Para iniciar sesión en su propia PC, use una contraseña que le indicó a su PC que reconozca. Cuando configura su PC para aceptar una "cuenta de Microsoft", de hecho le indica a su PC que reconozca la contraseña de su cuenta de Microsoft como la "contraseña local" - y la misma contraseña se usará para acceder a los servidores de Microsoft por toda la sincronización automática y la bondad de la aplicación que ofrecen.

Los detalles exactos pueden ser complejos, pero el principio sigue siendo el mismo: la autenticación es primero local, y luego (solo entonces) las credenciales también se usan para hablar con los servidores de Microsoft.

Una consecuencia es que si alguien logra obtener la contraseña de su cuenta de los servidores de Microsoft (suponiendo que la almacenen y no solo un hash, lo que no sería una buena idea), entonces obtendría la contraseña para su computadora local. lo cual no lo llevaría lejos hasta que pueda acceder físicamente a la computadora, en cuyo momento simplemente podría agarrarlo y correr, con contraseña o sin contraseña.

El envenenamiento de DNS es derrotado por SSL. El punto de SSL es abstraer el medio de transporte, incluidos el DNS y la dirección IP. El cliente está seguro de hablar con el servidor correcto porque validó el certificado del servidor y utiliza la criptografía en función de la clave pública que se encuentra en ese certificado. Es de suponer que los ingenieros de Microsoft se encargaron de usar la validación y las verificaciones adecuadas de los certificados (seguro que pueden hacerlo porque se utiliza el mismo código cuando accede a su cuenta bancaria a través del sitio web con tecnología HTTPS de su banco).

    
respondido por el Thomas Pornin 30.01.2014 - 19:21
fuente
6

Windows usa un proveedor de credenciales y un SSPI para proporcionar la funcionalidad. La SSPI se comunica a través de un servicio web a los puntos finales de Microsoft. Los puntos finales se configuran almacenándolos en una DLL firmada por el código que se inserta a través de Windows Update. La SSPI cargará la DLL, verificará su código firmado por Microsoft y analizará los puntos finales necesarios.

Cuando el SSPI se conecta a los puntos finales, compara el certificado SSL con un valor almacenado en la DLL de configuración. No estoy seguro de si es solo una comparación temática o si están haciendo comparaciones clave, pero si la comparación falla por cualquier motivo, se rechaza la solicitud.

Además, el proceso está protegido por un secreto de cliente. Las credenciales enviadas al punto final se cifran utilizando un secreto local que los puntos finales de Microsoft conocen. No estoy seguro si es una clave simétrica o una clave asimétrica. Sin embargo, la clave asimétrica podría ser más probable. Esta clave se comparte durante el proceso de arranque que se produce cuando registra la computadora como Live ID habilitado.

Para una medida adicional, la forma en que realiza el inicio de sesión único en los sitios habilitados para Live es mediante el almacenamiento de una cookie con un token de corta duración en uno de los dominios de Live ID. Una vez que la SSPI ha autenticado a un usuario, se envía una solicitud a otro servicio web para obtener un token de dispositivo. El servicio está autenticado por una confianza federada a Live ID. Si tiene un token de Live ID que se emite a su dispositivo, puede llamar a este servicio para obtener otro token. Este token de dispositivo se serializa a algún formato particular y se escribe en una cookie dentro de la sesión de Windows del usuario. La próxima vez que el usuario navegue a un sitio de Live ID, la cookie estará presente, validada y no se le solicitarán las credenciales. Hay algo más que esto, pero eso es lo esencial del proceso.

Por lo tanto, con respecto a la falsificación o la manipulación, Microsoft utiliza la fijación de certificados para evitar MITM, y utiliza un secreto compartido para evitar que los clientes no autorizados realicen solicitudes de autenticación.

Editar: Si el certificado adecuado no está en la DLL, la solicitud fallará. Un administrador podría falsificar la DLL pero necesitaría firmarla con las claves de firma de código de Microsoft, y bueno, problemas más grandes y todo eso si pudieran hacer eso. Si el administrador adquiere la clave compartida de alguna manera, podría falsificar una solicitud usando su token, pero eso significa que tienen que adquirir el token de alguna manera, lo que se hace mucho más difícil dado el anclaje del certificado. En ese momento, podría ser más fácil instalar un proveedor de credenciales falso y recopilar las credenciales.

    
respondido por el Steve 30.01.2014 - 19:17
fuente

Lea otras preguntas en las etiquetas