Two-Step Verification Will End Consensual Impersonation

 

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.

 

The latest big company to get into the act is Apple, joining Dropbox, Facebook, Google, World of Warcraft, and other companies that manage valuable consumer information. Apple IDs have now gotten a two-step verification option, meaning that users can enable a second authentication factor (which leverages their mobile devices) for logging in to iCloud, iTunes, and so on.

 

Social networking providers and eCommerce sites still aren’t yet forcing consumers to go through extra login steps for security reasons (though some banks are); they perceive it as adding too much friction. But the writing is on the wall. What was once anathema is going to be unilaterally required by online service providers -- and accepted by users -- within a couple of years, at least for especially sensitive operations. The only type of security education that really works is the school of hard knocks. Breaches that expose passwords are massive, frequent, and newsmaking events these days. Once enough “low-information” consumers find themselves undergoing account recovery and password change processes due to breaches, strong auth will seem like a much better idea.

 

There’s a side benefit that password-only authentication has given users all this time, though, and we’re going to run smack into a problem when it goes away: consensual impersonation. When you share your password with someone else so they can do stuff in your account as if they were you, that’s consensual impersonation. Some examples: a dad asking his kid to go online and do the annual school soccer signup on the dad’s behalf, an adult daughter of an elderly mom taking care of bill-paying on her behalf, and even (oh dear) girlfriends and boyfriends sharing email and Facebook passwords as a sign of affection and trust.

 

If your service demands a second factor, even one as simple as SMSing an OTP, the friction in account access sharing goes way up unless the two people are already in the same room, with their mobile devices present and accounted for, at the moment when the account owner would normally have handed out his or her password like candy. IT security pros are typically delighted to do away with employees’ option for consensual impersonation, and indeed, privileged identity management systems work really hard to make it impossible for those with superuser powers to do. But I suspect the consumer world isn’t quite ready for widespread two-step verification that cuts off this option. (Not that Juliet should have been giving Romeo her password anyway.)

 

Online apps will feel pressure to solve this problem. We may see cookies and access tokens with longer and longer validity periods to leverage the investment in that initial authentication. But here’s the right way to do it: make it easier to delegate constrained account access to other people. We don’t have good solutions for secure, auditable, Internet-scale person-to-person sharing of access in online apps today. In fact, they kind of stink -- my go-to example is Flickr, which makes selective sharing of photo albums ridiculously complicated -- which is why some people take the easy-if-insecure way out. The solution needs to be friendly and functional, and it needs to enable revocation, so that at least Juliet can kick Romeo out of her digital life as well as her real one when the time comes.

 

Solving person-to-person access authorization is a key use case for the OAuth-based web standard that I work on in my copious spare time, User-Managed Access (UMA). Once enough online services start to demand two-step verification, apps will need to enable UMA or something like it -- just to give people back the feature that consensual impersonation used to “solve.”

Comments

User Managed Access - that's the ticket!

Very important insights on how User Managed Access (UMA) can make our systems more secure. This is not just an issue in e-commerce and cloud based services. How many of our COTS or custom developed applications address UMA?

Faced with an all-or-nothing choice about allowing someone to access their accounts, users will often, out of necessity, choose "all." To make matters worse, many folks use the same password in many places (we made them change their passwords every 90 days and told them not to write them down, didn't we?), so giving access to one application hands over a master key.

Proxy access requirements (or UMA) are now a standard item for our requirements analysis for application purchase and build. We don't always get the proxy access functionality we need in the case of COTS. And we don't always build the ideal UMA scheme into our custom applications due to time, cost, and complexity challenges.

Any advancement in standards, guidelines, toolkits, and frameworks to support UMA will be most welcome!