How does Windows 8's Microsoft Account authentication work?

Question

One of the new features to Windows 8 is the ability to log in to your PC using your credentials from a Microsoft Account. How is this implemented, and what steps are taken to prevent hijacking of credentials in transit, falsified authentication or other such MITM attacks?

I'm presuming SSL or another encryption & authentication scheme used, but I can't find any details about what that includes, and how far MS have gone to prevent (for example) SSL & DNS poisoning.

Edit: RE SSL - what's to stop a SysAdmin adding a fake certificate for live.com to Windows' trusted public keys, running a server with the matching fake private key, and using DNS to redirect authentication requests?

Answer 1

In fact it more works in the opposite direction. To sign in your own PC, you use a password that you instructed your PC to recognize. When you configure your PC to accept a "Microsoft account" you in fact instruct your PC to recognize your Microsoft account password as the "local password" -- and the same password will be used to access Microsoft's servers for all the auto-syncing and app goodness that they tout.

The exact details can be intricate but the principle remains the same: the authentication is first local, and then (only then) the credentials are also used to talk to Microsoft's servers.

A consequence is that if someone manages to obtain your account password from Microsoft's servers (assuming that they store it and not just a hash, which would not be a good idea), then he would get the password for your local computer, which would not bring him far until he can access the computer physically, at which point he could simply grab it and run, password or no password.

---

DNS poisoning is defeated by SSL. The point of SSL is to abstract away the transport medium, including the DNS and IP address. The client is sure to talk to the right server because it validated the server certificate and uses cryptography based on the public key found in that certificate. Presumably, Microsoft engineers took care to use proper certificate validation and verifications (they sure can do it because the same code is used when you access your bank account through the HTTPS-powered Web site of your bank).

Answer 2

Windows uses a Credential Provider and a SSPI to provide the functionality. The SSPI communicates via web service to the Microsoft endpoints. The endpoints are configured by storing them in a code-signed DLL that gets pushed down via Windows Update. The SSPI will load up the DLL, verify its code signed by Microsoft, and parse out the necessary endpoints.

When the SSPI connects to the endpoints it compares the SSL certificate to a value stored in the configuration DLL. Not sure if its just subject comparison or if they've doing key comparisons, but if the comparison fails for whatever reason the request is rejected.

Further, the process is protected by a client secret. The credentials sent to the endpoint are encrypted using a local secret that the Microsoft endpoints know. Not sure if its a symmetric key or an asymmetric key. Asymmetric key might be more likely though. This key is shared during the bootstrapping process that occurs when you register the computer as Live ID enabled.

For added measure, the way it does SSO into Live-enabled sites is by storing a cookie with a short lived token in it for one of the Live ID domains. Once a user has been authenticated by the SSPI, a request is sent to another web service to get a device token. The service is authenticated by a federated trust to Live ID. If you have a token from Live ID that is issued to your device, you can call this service to get another token. This device token is serialized to some particular format and written to a cookie within the users Windows session. Next time the user browses to a Live ID site the cookie will be present, validated, and you won't be prompted for credentials. There's a bit more to it than this, but that's the gist of the process.

So with regard to spoofing or tampering, Microsoft uses the certificate pinning to prevent MITM, and uses a shared secret to prevent unauthorized clients from making authentication requests.

Edit: If the proper certificate is not in the DLL then the request will fail. An admin could spoof the DLL but they'd need to sign it with Microsoft's code signing keys, and well, bigger issues and all that if they could do that. If the admin acquires the shared key somehow then they could spoof a request using your token, but that means they have to acquire the token some how, which is made significantly more difficult given the certificate pinning. At that point it might just be easier to install a fake Credential Provider and collect the credentials.