Passwords in the wild, part IV: the future

July 30th, 2010 at 17:58 UTC by Joseph Bonneau

This is the fourth and final part in a series on password implementations at real websites, based on my paper at WEIS 2010 with Sören Preibusch.

Given the problems associated with passwords on the web outlined in the past few days, for years academics have searched for new technology to replace passwords. This thinking can at times be counter-productive, as no silver bullets have yet materialised and this has distracted attention away from fixing the most pressing problems associated with passwords. Currently, the trendiest proposed solution is to use federated identity protocols to greatly reduce the number of websites which must collect passwords (as we’ve argued would be a very positive step). Much focus has been given to OpenID, yet it is still struggling to gain widespread adoption. OpenID was deployed at less than 3% of websites we observed, with only Mixx and LiveJournal giving it much prominence.

Nevertheless, we optimistically feel that real changes will happen in the next few years, as password authentication on the web seems to be becoming increasingly unsustainable due to the increasing scale and interconnectivity of websites collecting passwords. We actually think we are already in the early stages of a password revolution, just not of the type predicted by academia.

The question of why passwords still dominate was discussed at a panel 18 months ago at Financial Crypto 2009, and already several of the major stumbling blocks to password replacement are quickly fading:

  • Reluctance to deploy new technology-While few websites have replaced passwords as a primary means of authentication, there has been considerable innovation by large authentication services in the past year, mostly in backup authentication. Google has rolled out SMS-based password recovery, Microsoft is planning to do the same for one-time use at untrusted terminals, Facebook has rolled out backup authentication by identifying friends tagged in photographs, and Amazon has quietly introduced its novel Payphrases system.
  • Lack of public evidence of risk-There have been a few high publicity password incidents in the last year, notably the RockYou hack and Twitter account compromises which led to forced reset of past users. These attacks are larger in scale than previous hacks but not qualitatively different (consider the now all-but-forgotten Reddit password compromise of 2007). Twitter is proving to be an interesting driver of change, however. While there have been  high-profile account takeovers of other celebrity accounts, such as Sarah Palin’s email, or Paris Hilton’s mobile phone, celebrity Twitter account hacks have become routine, happening to basketball player Ray Allen, singer Jason Mraz, astronauts with NASA, and even President Barack Obama (of course, some claims of account takeover are quite dubious). The most interesting thing about these attacks is that they increasingly seem to be financially motivated, as a high-audience compromised account is used to insert spam advertising. If account takeover becomes industrialised (along the lines of phishing and spam), it will put real pressure on changes to web authentication.
  • No organisation with sufficient leverage to move the market-With the meteoric rise of Facebook, this assumption is increasingly dated. Facebook is increasingly gaining the power to impose its preferred identity solution, Facebook Connect, with some large identity providers getting on board.

This leaves one major problem in place, competing stakeholders in the market, to which our study provides valuable data. Why do small websites, particularly news websites, still collect their own passwords instead of relying on a federated identity provider? There seems to be little security reason for doing so, as reliance on email providers for backup authentication is already nearly universal. Excluding webmail providers themselves, over 97% of websites we studied used external email addresses as login identifiers and performed password reset using email as a trusted channel.

Considering newspaper websites as the prime example of password deployments with questionable utility, we found that they were significantly more likely than other websites to collect marketing data at the time of password collection. They also nearly universally, with only a single exception, insist on verifying the validity of a user’s email address as a pre-requisite for an account (this was equally true at sites which also require CAPTCHAs, so we don’t think false account prevention is the primary reason). At this point, users may be trained to accept the idea of inputting personal data along with a password. A password input field may serve as a ceremonial cue that entering personal data into a form is safe (verifying this with behavioural experiments is an important future research question).

Thus, collecting passwords provides cover for collecting personal data, which provides tangible benefits to a site operator. The costs of password collection, however, aren’t primarily borne by the server. As discussed Wednesday, the costs of insecurity are largely borne by higher-security websites. The usability costs, in contrast are borne by users themselves. Users have a limited capability to remember and manage multiple passwords securely, which deteriorates as each additional website which requests a password, but each of those websites gains unilaterally from collection. Thus, over-collection can be viewed as a tragedy of the commons, as each website races to capitalise on users’ limited resources. As a result, 85% of the 500 most popular websites collect passwords, and the average web user has over 25 password-protected accounts.

OpenID may be being held back by market forces. For users, removing the requirement of registering personal information with the site is an advantage, but for many websites, removing the ability to collect personal data eliminates a major justification for deploying passwords at all. This may explain why we saw over twice as many websites in our study which accepted Facebook Connect, a proprietary protocol which is very similar to OpenID. In addition to being simpler for users to understand, Facebook Connect allows relying websites to send data to and from the user’s Facebook profile, more than replacing the previous motivation for collecting passwords. Tapping into Facebook’s unique arsenal of user data has proved irresistible even to large websites like Amazon.

Of all places on the web though, I think the American gossip website TMZ may be the clearest picture of the future. Authentication on the site is seamless, just as OpenID advocates hope it can be. Objects on the site can be dragged and dropped into one of several external identity providers (Facebook, Google, Twitter, and Yahoo), each with heavy customisation and use of OAuth to share data, but no option to use other OpenID providers. Whether OpenID is used or similar protocols, the future may be dominated by a small oligopoly of identity providers with large amounts of personal data, in contrast to the design goals of OpenID. The economics make it inevitable, however, that most sites don’t really care about who you are, but what they can gain from who you are.

http://www.tmz.com/

Entry filed under: Academic papers, Authentication, Protocols, Security economics, Security engineering

2 comments Add your own

  • 1. Sebastian Kübeck  |  August 1st, 2010 at 15:28 UTC

    Thank you!
    I am through all four parts and the paper and I think that’s probably the best I have read in years about web security.

    Keep up the good work!

    P.S.: Is there any research on the security of single sign on systems such as OpenID?

  • 2. muhammad afzal  |  January 7th, 2013 at 17:48 UTC

    all is well

Leave a Comment

Required

Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Subscribe to the comments via RSS Feed


Calendar

July 2010
M T W T F S S
« Jun   Aug »
 1234
567891011
12131415161718
19202122232425
262728293031