This is the second part in a series on password implementations at real websites, based on my paper at WEIS 2010 with Sören Preibusch.
As we discussed yesterday, dubious practices abound within real sites’ password implementations. Password insecurity isn’t only due to random implementation mistakes, though. When we scored sites’ passwords implementations on a 10-point aggregate scale it became clear that a wide spectrum of implementation quality exists. Many web authentication giants (Amazon, eBay, Facebook, Google, LiveJournal, Microsoft, MySpace, Yahoo!) scored near the top, joined by a few unlikely standouts (IKEA, CNBC). At the opposite end were a slew of lesser-known merchants and news websites. Exploring the factors which lead to better security confirms the basic tenets of security economics: sites with more at stake tend to do better. However, doing better isn’t enough. Given users’ well-documented tendency to re-use passwords, the varying levels of security may represent a serious market failure which is undermining the security of password-based authentication.
For websites, popularity (measured by Alexa traffic data), maturity (measured by years of existence), and technical skill and expenditure (measured by low average server latency) all positively correlate with better security. The simplest explanation is that global sites can afford more (and more skilled) developers to work out the details of their password implementation than local players like the The Nashville Scene can. Controlling for this influence though, we still see sharp differences between market segments. We studied three major use-cases for passwords online: content websites like newspapers, which use them to customise content for frequent readers and speed up commenting (sometimes making them mandatory), e-commerce websites which use passwords to protect shipping and payment data and allow for order-tracking, and “identity” websites like email and social networks which use passwords to protect persistent online identities. Below is a plot of password scores showing both traffic rank and market category for each site:
Many significant trends emerged between categories. E-commerce websites are significantly more likely to deploy TLS and notify users of changes to their account. Identity websites are significantly more likely to prevent brute-forcing of users and passwords, to block the use of dictionary words as passwords, and to require CAPTCHAs to make account changes. These differences probably relate to the core implementation skills required to succeed in the two segments: social networks and webmail providers have to block automated interaction to prevent spam and false account creation while e-commerce sites have to use encryption to protect payment details. The sites we studied which store payment card details (not only e-commerce sites, but many social networking and email sites) we see significant improvement across the board. Such sites bear a direct risk of fraud if passwords are compromised, so this isn’t surprising.News websites, unfortunately, fare worse than average in every measurable aspect of security, and indeed represented most of the worst practices we found. Interestingly, news sites offering premium content behind pay-walls didn’t fare significantly better despite having a revenue stream from limiting access. They even managed to take some very simple measures less often, like opting-out of the Bugmenot database to prevent users sharing subscriptions.
We only studied websites offering free accounts, so we missed a few important segments. Falk et al. studied bank websites specifically in 2008, and found problems at a rate comparable to the e-commerce websites we studied. Flôrencio and Herley recently compared the password policies at government and university websites to commercial ones and found that commercial websites impose less strict password strength requirements because usability is more critical to their business. This was confirmed by our data-we found no significant variation in password strength requirements between the segments we studied (all commercial).
It’s not surprising that sites with different security motivations perform differently. Password security is not an isolated phenomenon though and bad practices at one site can affect unrelated websites because users reuse passwords. It’s long been said in the security community that password re-use is dangerous because it enables attackers to compromise an account at a low-security site and gain access to a higher-security one. This is increasingly true as most websites today use email addresses as identifiers (87% in our study), meaning an email/password combination can unlock many online accounts. The RockYou hacker indicated that 10% of the email/password combinations registered at RockYou were also PayPal accounts (external compromise isn’t the only threat here: a malicious insider could certainly try to profit from a database at sites like this). This very attack scenario played out earlier this year at Twitter, which forced many users to change their accounts after a torrent website’s database of email/password pairs was hacked and used to take over Twitter accounts en masse.
News websites may have very little to lose through poor password security, but they can undermine the efforts made by other sites. This is a classic negative externality; with few corrective mechanisms the market is failing as news websites are doing a shoddy job with password security. Removing these externalities is hard; it requires putting a real price tag on hosting an insecure password deployment. RockYou may have endured a public shaming on tech blogs, but its gaming business has continued along fine. One approach would be strict punitive laws for websites if user passwords are compromised due to negligence, modeled on data breach notification laws. This is problematic, as aside from public, large-scale attacks, the public may not know when passwords have been compromised (tracer accounts might be useful here). A second approach would be to raise the price of collecting passwords at all, for example by requiring sites to submit to outside auditing or to send users written annual reports about their password security. It would be a successful outcome if fewer sites chose to register passwords in the first place-currently many sites are doing so which are unable to do so securely. In the meantime, technical aids like PwdHash to generate site-specific passwords automatically, or Bugmenot to re-use credentials at very low-security sites may be the best way to alleviate the problem.
Rather ironically, that PwdHash URL asks me to verify and install an out-of-date certificate.