Year End Link Clearance – Password Edition

I’m not good at letting go.  If I were doing this right,  I’d just list the links and be done with it.  But no, I have to blather about each one, because I found each of these interesting and worth saving saving to comment on for some reason.

Light Blue Touchpaper is a fairly technical blog focusing on security (“Security Research, Computer Laboratory, University of Cambridge”).  A certain subset of my readers will find the archives interesting.  Their recent series on passwords forms the backbone of this post.

Bottom line: many websites store passwords.  Most are doing it wrong.

…but we believe ours was the first large study into how Internet sites actually implement them. We studied 150 sites, including the most visited overall sites plus a random sample of mid-level sites. We signed up for free accounts with each site, and using a mixture of scripting and patience, captured all visible aspects of password deployment, from enrolment and login to reset and attacks.

They link to this paper exploring the economic reasons why users may be wise to ignore security advice.  (it probably says something about you if you find it as interesting as I did.)

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.

Even the big boys often get it wrong.  The greatest sinner I’ve seen is (or perhaps was) Charles Schwab.  Due to an unhappy serendipity, I discovered that my password was not only inexcusably short, but also case insensitive.  If my calculations are correct, this reduces the size of the password space by a factor of 67,108,864.  I also wonder about Fidelity.  When I call them, they want me to key in my “pin” on the phone.  This is supposed to be the same as the “password” I use online.  If that really works, then my complex online password is mapped to a much simpler one on the phone.  If not, then they expect me to use a numeric password online.  Both cases are security flaws.

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).

News websites may have very little to lose through poor password security, but they can undermine the efforts made by other sites.

“Gawker” was recently hacked, and their user/password database was used to hack into millions of accounts on other sites such as twitter.  Light Blue Touchpaper and CodingHorror both have good analyses.

For security purposes, it would be better to use some kind of central identity protocol (an Internet Driver’s License).

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.

Unfortunately, security is not the primary goal for many sites. (my emphasis)

Why do small websites, particularly news websites, still collect their own passwords instead of relying on a federated identity provider?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.

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.

Sometimes, the programmers are not at fault.  Management or Marketing is.  They insist that information be collected for all users, and don’t seem to care that 80% of their users are named “Barney Rubble.” (That comes from a blog entry I cannot find – fill me in if you know who wrote it first.) This requirement comes at a cost.  If you require registration to participate on your site, users will leave.  If you require personal information, users will leave or lie.

I have an example.  I like to listen to MP3 books in my 2008 RAV4.  I have found that the CD player cuts off the last couple seconds of each track.  Some audio books have track breaks every minute for my convenience – and these are unusable in the car.  I spent way too long searching online for a solution, and found exactly one match at

The OEM MP3 player on my 2008 Toyota RAV4 cuts off the last few seconds of each MP3 file.I have started burning MP3 files onto CDs to play on the CD/MP3 player in my 2008 RAV4 Limited (JBL sound system).

The last few seconds of every MP3 file are cut off abruptly, although when I use the CD on my computer the files are fine, so the problem is not with the CD.

I cannot find anything about this issue in the Owner’s Manual or on the internet, and nobody at the Toyota dealership knows anything about this. Does anyone know why this is happening and how I can correct it?

It’s an exact match, so I thought I’d add a “me too” comment with some additional information.  Edmunds requires me to create a registration.  I don’t want an account on, so I just left.  Not worth the trouble, no thanks edmunds.

If you happen to have a solution, or a way to add 2 seconds of padding to an MP3/WMA file, please comment.

2 Responses to “Year End Link Clearance – Password Edition”

  1. […] week I dumped a bunch of information about the sorry state of passwords and the internet, mostly from Light Blue Touchpaper.  As usual, I soon ran across more information […]

  2. […] can’t seem to wrap up this security jag.  Stuff keeps […]