With Windows 8 released to manufacturing and available for download from MSDN, this is a good time to complete the post on using cloud identity in a traditional PC operating system. As MSFT announced on the Building Windows blog almost a year ago, Windows 8 will support signing in with Windows Live ID, now rebranded as Microsoft ID. Instead of creating local accounts, users can now authenticate to a Windows 8 machine using their existing cloud account.
Of course such integration is far from novel, with many examples of familiar consumer devices that had tight integration with a cloud authentication service, in some cases requiring that users authenticate with such an account to setup the device in the first place:
- iOS and its use of an Apple account on iPod/iPhone/iPad
- Android and its integration with Google accounts systems. In fact Android has an extensible account manager concept: it allows defining additional cloud identity providers by having installed applications act as account authenticators, which can be invoked by any other app. (Looked another way, Android re-invented SSPI model that Windows supported since NT4 but never quite at the level of interchangeability its designers hoped– no new ideas under the sun.)
- More recently Chrome OS and similar integration with Google accounts
In all cases, this identity becomes an integral part of device functionality when accessing cloud-based functionality: for example it is used to backup settings, migrate to new device, download email and calendar entries, make purchases in the respective app markets. This requires a level of integration between the OS and applications, such that after logging into the OS once, the user is automatically also logged into cloud services without having to explicitly type their password again. Without such automatic transfer of authentication state, the initial login would become pure window dressing that only grants access to local system resources. Luckily such seamless integration exists in Windows 8: after logging in, the mail application transparently downloads mail from Hotmail, Sky Drive can access saved files, Messenger can display presence information for contacts and Internet Explorer can open web pages requiring Live ID as already authenticated. In fact since as long as the functionality is implemented as standard SSP, it becomes available to third-party applications to use for creating apps that access user-data stored in the MSFT cloud.
There are also differences: first one is that Windows supports local accounts and the user may be upgrading a Windows 7 box– because nobody is running Vista– already configured with one. This introduces a requirement to retroactively associate an existing account with a cloud identity. Mobile devices started out with the assumption of cloud connectivity, and a clean slate to define their identity scheme. Second the user experience is different: for mobile devices user authentication is rare for good reasons: phones have awful virtual keyboards that make typing plain English painful, much less a strong password that containing random mixture of symbols and digits. (While Android screen-lock can be configured with a passphrase, this is logically not the same as the Google account password.) With Windows 8 and Chrome OS even unlocking the screen locally can involve some type of authentication, making this ritual more frequent. That also creates a challenge in having to support offline mode: since the device may not have network connectivity at all times, it still has to authenticate the user’s cloud identity without the benefit of reaching the cloud.
Offline mode is not a new problem, as similar issues existed for the bread-and-butter protocols Windows supported before (NTLM and Kerberos) and can be solved by locally caching password hashes, at the well-known risk of introducing brute-force attacks against these cached copies. But some credentials can not be checked offline: an example is the one-time password or OTP codes used for Google 2-step verification: since these are meant to be dynamically generated each time, caching is not applicable and only Google knows what the next code in the sequence is. MSFT has a different concept called single-use codes for Live ID, which is not a secondary factor but replaces the password. It is unclear if these still work for login in connected state; they will likely not work for offline mode.
Stepping back, such tight-coupling between the OS and a particular cloud-identity provider also creates a natural “nudge” for users to favor cloud services authenticated by that identity, since the applications “just work” naturally without additional setup. Consider the difference between having to sign-in to a third-party email or instant-email service, verses going with the path of least resistance using the built-in variant that is automatically signed in. Granted most applications “solve” this problem with a strong bias for saving passwords (as well as annoying opt-out settings to automatically launch as soon as the user logs in) This may level the playing field for user experience at the expense of security: instead of refreshing credentials over time, they rely on a password or long-lived token to create the illusion of automatic sign-in. Of course in the case of Windows 8, those cached credentials are already at the mercy of Live ID if the user enables one of the highly touted-features: synchronization of saved passwords across multiple machines, as long as the user is signing in with the same Live ID, similar to Chrome synchronizing website passwords.