Security and risk professionals know what to do with security vulnerabilities: we mitigate the risk directly as best we can, and put in place compensating controls when we can't change the underlying dynamic. But in the age of the customer, upping our game in authentication strategies has forced us to take a harder look at an area that, generally speaking, is not our specialty at all.
Last summer, Forrester published a Customer Authentication Assessment Framework that leveraged some exciting academic research called “The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes” out of the University of Cambridge Computer Laboratory. (Gunnar Peterson has a recent post highlighting the arc and nature of these researchers' work, and even has a nice back-and-forth in the comments with contributor Cormac Herley of Microsoft Research.)
If you ever need a belly laugh, visit the site DamnYouAutocorrect.com (warning: it’s often not safe for work). It’s also a great illustration of why you shouldn’t just force users through the same exact login procedure when they use mobile apps versus full-fledged browser windows: hitting all the right tiny keys is hard work, and often the software behind the scenes is helpfully trying to “correct” everything you type.
Responsive design is all the rage in consumer web app design, and for good reason: users can put down one device, pick up another, and change the screen orientation in mere moments, and app developers can’t afford to miss a trick in optimizing the user experience. Similarly, in researching current authentication methods and trends, we’ve come to believe more strongly than ever in adapting your user authentication methods to your population, the interaction channel they’re using, your business goal, your risk, and your ability to pick up on contextual clues about the user’s legitimacy or lack thereof. Call it responsive design for authentication.
When we published our recent Customer Authentication Assessment Framework research (the report comes with a spreadsheet tool), we deliberately focused on onboarding, login, step-up authentication, and account recovery for – yes – customers, most particularly consumers. Why? Because the framework takes into account usability characteristics just as much as security characteristics, and security pros delivering solutions to Marketing had better have good answers when they propose adding friction to the login experience.
Social sign-in has become a powerful force for marketers and consumers, validating the notion of federated identity in consumer-facing contexts. (Ironic that consumerization of IT is successfully tackling even the single sign-on problem that has bedeviled IT, showing how identity for the top line of the business can overcome resistance in ways that business-to-employee scenarios typically can't.)
But not all consumer-facing federated SSO is social. When I was with PayPal, our team worked on the underpinnings of what eventually turned into Log In with PayPal, which is strictly about federated identity flows for commercial purposes. And today Amazon has come out with Login with Amazon, a powerful statement of Amazon-as-identity-provider. They've been testing this with their own web properties Zappos and Woot; now they're enabling third-party merchants and other sites to use Amazon for authentication of people who already have active Amazon accounts, along with learning a few selected user attributes: name, email, and optionally the zip code of the default shipping addresses. No huge social graphs here, just data that partner eCommerce sites need to function (and make money).
I had the chance once again to do a podcast with Mike Gualtieri as part of his wonderful Forrester TechnoPolitics series, talking about the usability affordances of passwords that make them natural targets for consensual impersonation. As Mike memorably puts it, is this behavior frisky, or risky? Just like in our last podcast together, I found myself confessing deep dark authentication secrets. Take a listen and let me know your thoughts.
A couple of months back, I advocated killing your password policies and applying some other techniques instead to make existing use of passwords more effective (including my hobby horse: take the user-experience sting out of rotating ordinary static passwords by pushing them out to users on an alternate channel, à la activation codes and other OTPs). But adding factors is still a great idea, and the barriers to doing so are falling fast.
It has finally become hip not just to predict the demise of passwords, but to call for their elimination. The recent Wired article makes an eloquent case about the vulnerabilities that even "strong" passwords are subject to, such as social engineering and outright theft. And strength is, of course, relative and subject to degradation: The latest computer hardware can make short work of cracking more-complex secrets.
It's true: Static shared secrets are sitting ducks. But passwords are too useful to go away entirely, both because it's handy to be able to synchronize authenticator data between cooperating systems (and people), and because people find using passwords to be less invasive, fiddly, or personally identifying than a lot of other options. So I don't buy the whole "the era of passwords is over" thing. They will be at least one important element of authentication strategies for the foreseeable future -- it's a rare multi-factor authentication strategy that doesn't include a password or PIN somewhere along the line as one of the "things you know."
So, if that's our reality, let's think outside the box in using them. In talking with Mike Gualtieri recently as part of his TechnoPolitics podcast series, I mentioned a few ideas. I had thought of these as pet password peeves, but on the cusp of 2013, why not be positive and think of them as resolutions?
Cloud providers and many federated IAM practitioners are excited about OAuth, a new(ish) security technology on the scene. I’ve written about OAuth in Protecting Enterprise APIs With A Light Touch. The cheat-sheet list I keep of major OAuth product support announcements already includes items from Apigee, Covisint, Google, IBM, Layer 7, Microsoft, Ping Identity, and salesforce.com. (Did I miss yours? Let me know.)
OAuth specializes in securing API/web service access by a uniquely identified client app on behalf of a uniquely identified user. It has flows for letting the user explicitly consent to (authorize) this connection, but generally relies on authorizing the actions of the calling application itself through simple authentication. So does the auth part of the name stand for authentication, authorization, or what? Let’s go with “all of the above.”
However, OAuth is merely plumbing of a sort similar to the WS-Security standard (or, for that matter, HTTP Basic Authentication). It doesn’t solve every auth* problem known to humankind, not by a long shot. What other IAM solutions are popping up in the API-economy universe? Two standards communities are building solutions on top of OAuth to round out the picture:
In approaching the research for my recently published TechRadar™ on strong authentication, at first I struggled a bit with overlapping concepts and terminology (as can be seen in the lively discussion that took place over in the Security & Risk community a few months back). The research ultimately revealed that form factor matters a lot -- smartcards in actual card form, for example, have some properties and use cases distinct from smart chips in other devices. So smartcards became one of the 14 categories we included.
The category that quickly became my favorite was "bring-your-own-token." BYOT is Forrester's term for the various methods (sometimes called "tokenless") that leverage the devices, applications, and communications channels users already have. The classic example is a one-time password that gets sent in an SMS message to a pre-registered phone, but we see emerging vendors doing a lot of innovation in this space. You can get a surprising amount of risk mitigation value from this lightweight approach, in which you can treat provisioning not as an expensive snail-mail package, but as a mere self-registration exercise. In a world where hard tokens and smartcards prove themselves to be, shall we say, imperfectly invulnerable, lightweightness can have a value all its own. In fact, BYOT showed up just behind these two venerable methods in the "significant success" trajectory on the TechRadar.