A little knowledge is a dangerous thing

Last week the Washington Post reported that a web site belonging to the Virginia Department of Health Professions was broken into, and that millions of records regarding use of controlled drugs had been at least potentially accessed by an attacker. The attacker claims to have encrypted the records with a key only s/he knows, and will not release the key without being paid a ransom.

Clearly this was a bad thing.

But here's where we get into "a little knowledge". The Washington Post reports that "Del. Joe May, an electrical engineer by profession and the House's resident expert on technology issues, wanted to know what security measures the hacker had to overcome to access the records." So far, so good. They then quote May as saying "It doesn't sound like the proper firewalls, the proper backing up, the proper security measures were in place, ... and the question is why didn't we go ahead and have VITA do it."

Unfortunately, the problem almost certainly wasn't an issue of firewalls or similar security measures - it's much more subtle than that, probably an application security flaw.

I served with Del May on a state commission on electronic voting issues some years ago, and learned that he's got a great understanding of the big picture, but doesn't understand the details. As an example, he insisted that it was impossible for someone to break into a voting machine because there's no source code that's publicly available. I'm sure that will come as a great surprise to the black hats who routinely reverse engineer products to find vulnerabilities and develop attacks, to the white hats at companies like Symantec and McAfee who reverse engineer the attacks to come up with protections, and the hundreds of millions of users who have to install patches to protect against the vulnerabilities that, in Del May's mind, cannot exist.

It's great that the legislature has technical members - this is very much in keeping with Thomas Jefferson's view of a citizen legislature. However, those members need to be aware enough of their breadth of knowledge to understand when it's time to call an expert. You don't ask an oncologist for an expert opinion on brain surgery, or vice versa. Del. May and the legislature need to ask for help when they need it.

Ironically, the article concludes "Paquette [the state technology director] said DHP had one of the most secure systems in state government, and that firewall systems and backups were operational at the time of the attack". If this is one of the "most secure" systems, I'd hate to see the others....

Too much information (for too little value)

I rarely go to the movies - I usually just wait until whatever I want to see comes out on DVD. But recently I wanted to see the This American Life live simulcast. When I bought my tickets, I was disappointed that I had to register in order to make the purchase - and very surprised that a required field in the registration is a birthdate.

I can see where if I were under 18 they might want a birthdate to verify what types of movies I'm allowed to see (although it should really control admission, not ticket purchase). But for those of us over 18, it's only useful for marketing purposes - and it's an unnecessary piece of personal information for them to have. Just another bit of data to put identities at risk...

The privacy policy says "Through customer surveys, subscriptions, and newsletter registration, our site may request users to give us contact, demographic and/or financial information (such as
their name, locale, gender, age, income level and email address). The demographic information is used, among other things, to enhance user experience so we can be more content specific." I guess they consider the birthdate to be demographic, although IMHO if that were the case they could do just fine with the year alone.

I've filed a complaint with their customer service department. Not surprisingly, I haven't heard back. I may file a complaint with their privacy person next.

How to guarantee bad passwords (part 2)

As I described in a recent post, overly complex password rules lead to hard-to-remember passwords that get written down. Well, I tried not to write it down, and promptly forgot it. So I called the helpful help desk person, who reset it for me to a random value, and had me reset the password. Other than the cost to the organization of having to have a person involved in password resets, so far so good.

But then the kicker: your new password can't have any two character sequence the same as any of your previous 9 passwords. Makes sense to some extent - you shouldn't be able to switch from "myDOGspot!!" to "myDOGspot??". However, it means that in order to do this check, they're almost certainly not storing one-way hashes of the passwords (as good security engineers do), but rather the original passwords. The help desk person assured me that the passwords are encrypted, so there's nothing to worry about. So even if someone breaks into their site, all they'd get is the encrypted passwords.... Of course, if someone figures out how to get in below the level of encryption, then game over.

Moral of the story: "improving" security by strong passwords can backfire in many ways, by causing users to write them down, having servers that store the original passwords, etc.

Disaster recovery

Bruce Perens has an excellent analysis of the recent California bay area telecom outage, which showed the level of interdependency among systems. Anyone who thinks cloud computing is a panacea, especially for government services (some of which are needed in emergencies) needs to understand the implications of this outage, and what attackers may have learned from it.

Well worth reading.