Last month, I focused on the enterprise version of cloud identity, in which the identity provider—the place that has all the user IDs, passwords, and other interesting identity information—is generally the company where you work. For 93 percent of the Fortune 1000, identity information is stored in Active Directory (AD). The driving technology in enterprise cloud identity is federation, which lets you securely extend your identity information to cloud-based services without exposing passwords over the Internet. This month, I want to give you an overview of consumer identity, which adheres to the same basic principles as federation and has similar security requirements, but is a very different configuration and has different use cases.
Why should you—the enterprise identity professional—care about consumer identity? One reason is that the back end of consumer identity is also a type of enterprise identity; after all, consumers are connecting to a business on the other end of your web browser. If your business reaches out to customers who use your company’s websites, you need to have some degree of awareness or involvement in consumer identity. How do your customers authenticate to your websites? Is it easy? Is it secure?
Another reason you should have some understanding of consumer identity is that you, too, are a consumer. And you aren’t just a consumer; as a card-carrying IT pro, you’re also IT support for your relatives and friends. (Why else is ThinkGeek’s No, I will not fix your computer T-shirt perennially popular?) Not only do you need to understand the strengths and weaknesses of consumer identity security; you also need to evangelize good practices and tools to your own user community.
The biggest difference between enterprise identity and consumer identity is that in consumer identity, there’s no single identity provider. In other words, there’s no single authoritative identity store such as AD. Rather, every consumer service or website provides its own identity store—a bad situation in many ways. The first and most obvious repercussion is that users must remember a lot of passwords. (My current count is around 210.) Many of these passwords are also being transmitted in clear text over the Internet. Next time you log on to a consumer website, take a look: Have you noticed how many of them are SSL-encrypted? Many sites encrypt the page where users provide credit card information, but they might not encrypt your account logon page. If the logon page doesn’t start with https, the HTTP payload packet containing the clear-text password is visible to anyone who can monitor the traffic.
Creating a strong password is obviously important. Remembering it is a pretty good idea, too. Now, repeat that for all your other websites, making sure every one is both strong and unique. It takes about three websites before password fatigue sets in, and you start repeating passwords.
Then there’s the security of the identify provider to consider. It’s almost impossible to know how secure your account data is with any web identity provider. The Gawker hack in December revealed information about more than 1 million users. It also revealed that users’ passwords are as weak as we feared: The most common passwords for logging on to a Gawker Media site were “123456” and “password.” Come on, people.
We can’t be too hard on the consumer, though. It’s unfair to ask the average web surfer to maintain strong, unique passwords across literally hundreds of sites, four major browser types, and probably multiple computers. I can’t keep up with it, and you probably can’t either!
LastPass, a browser add-in for all major browsers, is a clever solution to this problem. It captures the user ID and password you enter at a website, encrypts it locally with a one-way salted hash, and saves it to a 256-bit encrypted store on the company’s servers. You have the decryption key locally on your computer, so only you can read your data. LastPass also has the ability to take care of the “don’t reuse your passwords” principle by generating unique, strong (and completely unrememberable) passwords for every website, but I haven’t quite given in to that yet.
The consumer web-authentication situation isn’t all doom and gloom, however. Although there isn’t a single, overarching identity provider (frankly, no one wants one), there are several large, secure consumer identity providers such as eBay, Facebook, Google, Microsoft Live, PayPal, and Yahoo! The practice of re-using your existing credentials on these identity providers to log on to consumer web services (rather than creating a new set of credentials for every service) is rapidly gaining popularity. The benefits are obvious: The user no longer has to remember hundreds of passwords—just the passwords of the identity providers. There’s no password to be hacked at the service provider. And the provider can get out of the identity provider business (which is secondary to its main business). Is this Single Sign-On (SSO)? Yes, but in practice, it’s only SSO for the websites and services that use these technologies. The most widely adopted standards for providing this kind of consumer SSO are OpenID and OAuth.
Open ID
OpenID (openid.net) is an open standard that uses browser redirection to accomplish this sign-on process. According to its website, since its creation in 2005, more than 50,000 websites now accept OpenID for logons (which makes them OpenID consumers) and more than 1 billion accounts across the web have the ability to use it (because their accounts reside on OpenID providers). How does it work? When a web user attempts to log on to an OpenID consumer (also known as a relying party because they rely on identity information from the identity provider), they’ll see the option to log on using an existing account at one of several OpenID providers listed on the logon page. When they click the provider’s logo, they’re directed to the provider’s website, which asks them if they want to allow certain information (usually listed) to be provided to the website they’re trying to log on to. All that’s left is to click OK. For example, Bob wants to log on to the stackoverflow.com website. The logon page asks, “Do you already have an account on one of these sites?” and presents him with an array of identity-provider logo buttons to choose from. (This is also known as the “NASCAR page,” as it resembles a wall of corporate logos you might find on a NASCAR race car.) He chooses Google and is redirected to a Google Accounts page, where he’s asked whether he wants to allow sharing of his Google email account with Stackoverflow. (This consent step only happens once.) Clicking Allow, he’s sent back to Stackoverflow, where he’s now authenticated with no more action on his part. Pretty easy.
OAuth
OAuth (oauth.net) isn’t strictly about authentication, but it can do it. OAuth is currently being used mainly for web service authorization. However, two websites you might have heard of—Facebook and Twitter—use OAuth for authentication. Facebook uses it for Facebook Connect, which lets you use your Facebook account to log on to other websites, and Twitter requires it for all applications that wish to access Twitter data. Therefore, even though OAuth isn’t widely adopted for authentication, it’s heavily used. In the future, OAuth is expected to become very popular for authentication on mobile devices because its authentication process doesn’t require a browser.
That said, given a choice of identity providers, I’m more comfortable with some than with others. On one hand, every place where you can log on to Google is encrypted, and so are all Gmail transactions. Facebook’s default logon, on the other hand, is unencrypted. Did you know there’s an SSL sign-in page for Facebook? Just add an “s” to the “http” in the Facebook URL. Facebook doesn’t advertise this fact, however. Without SSL encryption, all your Facebook transactions are visible on the network, which allows exploits such as Firesheep to capture and use your session cookies to hijack your account. And Facebook’s somewhat laissez faire approach to privacy isn’t encouraging.
Then there’s the consideration of identity quality. An identity is created at an identity provider, but how “real” is it? Is a real person behind it, with real information, or has it been generated by a spambot? If this is something you’re concerned about as a service provider, a financial services identity provider such as Verisign or PayPal jumps to the top of your preferred list because they have more stringent verification requirements.
Looking forward, cloud identity gurus are looking at the use case in which some identity providers have many parts of your online identity (but no one has all of it), and your full online consumer digital identity is an aggregate of identity bits from many identity providers. Google might contain your email address, PayPal your bank account number, Facebook your friends and your birthday (if you aren’t careful), and Windows Live your gaming information and Kinect visual profile. How can you securely provide just the right amount of these different sets of identity data to, for example, a mobile device? And how do you easily control access to the data? This step involves federation between the identity providers themselves.
Interim Solution
The web is moving toward fewer passwords, using standards such as OpenID and OAuth. Until then, utilities like LastPass can programmatically handle the multiple-password problem for you. If you work for a consumer-facing service, you should be evangelizing OpenID or Oauth to eliminate the overhead and vulnerability of maintaining your own identity store. And you should be encouraging your user community to log on with their existing identity providers when they can, try SSL logons if they can’t and it’s available, and use LastPass to increase their personal security.
Sean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.
