事实上，它在相反的方向上更有效。要登录您自己的 PC，请使用您指示您的 PC 识别的密码。当您将您的 PC 配置为接受“Microsoft 帐户”时，您实际上是在指示您的 PC 将您的 Microsoft 帐户密码识别为“本地密码”——并且相同的密码将用于访问 Microsoft 的服务器以进行所有自动同步和他们吹捧的应用程序优点。

确切的细节可能很复杂，但原理保持不变：身份验证首先是本地的，然后（只有这样）凭据也用于与 Microsoft 的服务器通信。

结果是，如果有人设法从 Microsoft 的服务器获取您的帐户密码（假设他们存储它而不仅仅是哈希，这不是一个好主意），那么他将获得您本地计算机的密码，这不会把他带到很远的地方，直到他可以物理访问计算机，此时他可以简单地抓住它并运行，密码或无密码。

DNS 中毒被 SSL 打败了。SSL 的重点是抽象出传输介质，包括 DNS 和 IP 地址。客户端肯定会与正确的服务器通信，因为它验证了服务器证书并使用基于该证书中的公钥的加密。据推测，Microsoft 工程师注意使用正确的证书验证和验证（他们确实可以这样做，因为当您通过银行的 HTTPS 支持的网站访问您的银行帐户时使用相同的代码）。

Windows 使用凭据提供程序和 SSPI 来提供功能。SSPI 通过 Web 服务与 Microsoft 端点进行通信。通过将端点存储在通过 Windows 更新下推的代码签名 DLL 中来配置端点。SSPI 将加载 DLL，验证其由 Microsoft 签名的代码，并解析出必要的端点。

当 SSPI 连接到端点时，它将 SSL 证书与存储在配置 DLL 中的值进行比较。不确定它是否只是主题比较或者他们是否进行了关键比较，但如果比较失败，无论出于何种原因，请求都会被拒绝。

此外，该过程受到客户端机密的保护。发送到端点的凭据使用 Microsoft 端点知道的本地机密进行加密。不确定它是对称密钥还是非对称密钥。不过，非对称密钥可能更有可能。此密钥在您将计算机注册为启用 Live ID 时发生的引导过程中共享。

作为补充措施，它在启用 Live 的站点中执行 SSO 的方式是为其中一个 Live ID 域存储一个带有短期令牌的 cookie。一旦用户通过 SSPI 身份验证，就会向另一个 Web 服务发送请求以获取设备令牌。该服务由对 Live ID 的联合信任进行身份验证。如果您有一个来自 Live ID 的令牌，该令牌已发给您的设备，您可以调用此服务来获取另一个令牌。此设备令牌被序列化为某种特定格式并写入用户 Windows 会话中的 cookie。下次用户浏览 Live ID 站点时，cookie 将出现并经过验证，并且不会提示您输入凭据。还有比这更多的东西，但这是该过程的要点。

因此，在欺骗或篡改方面，微软使用证书锁定来防止 MITM，并使用共享机密来防止未经授权的客户端发出身份验证请求。

编辑：如果正确的证书不在 DLL 中，则请求将失败。管理员可以欺骗 DLL，但他们需要使用 Microsoft 的代码签名密钥对其进行签名，而且，如果他们能做到这一点，那就是更大的问题。如果管理员以某种方式获取了共享密钥，那么他们可以使用您的令牌来欺骗请求，但这意味着他们必须以某种方式获取令牌，鉴于证书固定，这变得更加困难。到那时，安装假凭据提供程序并收集凭据可能会更容易。