Blizzard offers a One Time Password device for it’s European customers but not the North American or Asia Pacific customers? Blizzard is using a One Time Password device (it appears to be event based) to allow for strong authentication to it’s EU servers. There’s no indication on what manufacturer they’re using, or if it’s OATH compliant, but it is still a “real” two factor authentication, as users will need to have their device with them to log into the account management web pages or to the game servers.

It’s optional, and available for 6 euros to EU customers.

There are three things that makes this interesting:
1) real two factor authentication is available in a game before it’s available in some banks
2) Someone at Blizzard feels that users will appreciate the extra authentication (for a game!)
3) It’s not available in North America

I’d get one just to play with it – not that I think my WoW account needs that kind of protection – but it’d be fun to see what it’s like and how they implemented it. Unfortunately, I have a North American account (although, I can play on EU servers, so maybe?). The EU is a smaller market than North America, so perhaps this is a “pilot” program that may eventually make it to the US?

What I still find incredulous is that while banks and financial companies (which do have information I’d like to protect with strong authentication) are using a fake two factor login while a video game is using real two factor authentication. The contents of a WoW account are (arguably) worth less than my bank account – depends on your feelings of the game – my account is certainly worth a lot less to me than my bank account.

UPDATE 7-1-08: Blizzard seems to be offering them for NA servers as well (at least they claim that it can only be shipped to the US).

RFIDs can switch off equipment used in hospitals. Researchers tested several types of devices used to save lives in close proximity to RFIDs and found that the devices, in a number of instances, interfered with the equipment’s functioning.

A total of 123 tests, three on each machine, were carried out, and 34 produced an “incident” in which the RFID appeared to have an effect – 24 of which were deemed either “significant” or “hazardous”.

The use of RFIDs in hospitals has begun to grow. The devices are being used for tasks such as patient identification, inventory management, and allowing only relevant hospital staff to view a patient’s medical records.

Hospitals will need to consider the new findings as they continue to employ this kind of technology. Families will find little consolation in the fact that their medical records were kept safe by the same gadget that mistakenly turned off their loved one’s ventilator. They may also take legal action, and there’s too much of that going around already.

Jeff over at Coding Horror lashed out at the MENSA web site today, after discovering that their web site uses a presumably weak password storage mechanism that stores passwords in a recoverable format. The main point is that because the passwords can be retrieved by the application and sent back to the users, then they must be stored in a way that would allow an attacker to obtain a list of all (or some) of the passwords in the system.

One primary reason that this is seen as a bad thing is that many users use the same password for all of their various accounts, and therefore if the password is compromised in one place, it’s compromised everywhere. Apparently, according to this argument, every web site should have bulletproof security regardless of what it is that the web site does, in order to protect its users other accounts with other web sites. While this is a noble sentiment, and it would be great if this would happen, it’s a silly argument.

Security costs money, in terms of development, support, maintenance, training, etc. Therefore, security is built into an application as much as is reasonable for what the application does. If I’m designing a web site that lets you register your e-mail address, and all my web site does is associate your e-mail address with your home address so you can order a pizza online (let’s forgo the concept of credit cards for the moment and assume this is all handled with cash), why in the world should I need to have my site armed to the teeth with SSL, salted password hashes, password complexity requirements, and password expiration periods?

Since I’m not a member of MENSA, I don’t know what sort of services are available through their web site. If they aren’t performing anything that requires a high amount of non-repudiation and authentication, then why should anyone care if they’re storing passwords weakly? If you get your E*Trade account hacked because it had the same password as your MENSA account, that is not MENSA’s fault, because you shouldn’t be sharing passwords between any two systems, let alone two systems with vastly different security requirements. Don’t use the same password for your bank account as you do for your local pizza delivery place, and you’ll have a lot less to worry about.

The Markle Foundation has just helped launch what can best be described as the first REAL effort at designing a framework for organizing healthcare information online. This project is backed by some pretty heavy parties on both the tech side (Google, Microsoft, Intuit, WebMD, etc) and on the provider side (Aetna, BCBS, Department of Veteran Affairs, etc).

The framework is designed to establish a common set of “best practices” that should be followed by applications and services that handle, process, or store personal health-related data online.

According to Markle :

The framework …includes four overviews and 14 specific technology and policy approaches for consumers to access health services, to obtain and control copies of health information about them, to authorize the sharing of their information with others, and sound privacy and security practices.

I think this is a great step in the right direction. With the increase in instances of personal health records being stored electronically, a framework for keeping things as secure as possible is essential.

Microsoft HealthVault and Google Health drew some attention from the security industry when they were announced; consequently, issues of privacy and security were raised. As more and more providers and insurance companies are experimenting with making health records available to both doctors and patients via the Internet, these same issues will become more and more important.

It is good that they are getting together to lay down some “ground rules.”

This is probably off-topic for this blog. You’d probably expect this on Schneier’s blog instead.

If you have some time, go download and read this excellent paper: “I’ve Got Nothing to Hide” and Other Misunderstandings of Privacy written by Professor Daniel Solove of the George Washington University Law School.

[T]he problem with the nothing to hide argument is the underlying assumption that privacy is about hiding bad things. Agreeing with this assumption concedes far too much ground and leads to an unproductive discussion of information people would likely want or not want to hide. As Bruce Schneier aptly notes, the nothing to hide argument stems from a faulty “premise that privacy is about hiding a wrong.”

The deeper problem with the nothing to hide argument is that it myopically views privacy as a form of concealment or secrecy. But understanding privacy as a plurality of related problems demonstrates that concealment of bad things is just one among many problems caused by government programs such as the NSA surveillance and data mining.

Your government is working so hard to prevent terrorism that they are trampling your rights to privacy. I used to be in the ‘nothing to hide’ camp, but we are clearly slipping quickly down this slope into dangerous territory. Another quote from the paper:

The potential future uses of any piece of personal information are vast, and without limits or accountability on how that information is used, it is hard for people to assess the dangers of the data being in the government’s control.

Election day is coming, folks. Making changes in Washington is the only way to tell the government we are more afraid of losing our rights than we are of terrorism. Ben Franklin said “Those who desire to give up freedom in order to gain security will not have, nor do they deserve, either one.”

Endpoints can be almost anything – USB drives, iPods, laptop computers, cell phones, even digital cameras with SD cards. Billions of dollars have been spent making sure brilliant hackers can’t attack computers from across the globe. But firewalls generally don’t stop anyone from attaching a finger-size drive to a computer and stealing gigabytes worth of secrets from a company or government agency.

Oddly enough, security breaches or data leakage through this form is usually never intentional. It usually just ends up being a careless employee who’s trying to get their work done quicker. The network is slow, permissions are acting up, email file size limitations, whatever the reason, and it’s probably never intentional. With the size of USB thumb drives getting smaller and smaller, it’s not hard for these things to be misplaced, or even forgotten about.

The situation is serious, but not hopeless. Making sure you have solid policies in place is a good start. Protecting important documents with encryption is an even better start. There are many makers of thumb drives with built in encryption mechanisms. You can even opt for a full on encryption suite for you company that includes a form of removable storage encryption. There are some that include mini-software packages that will allow you to decrypt the data on a system that doesn’t have the master encryption suite installed.

But encryption isn’t the only answer. A simple process of purging thumb drives could eliminate left over documents that the user simply forgot to delete of the drive.

So let’s not forget that even with the most robust firewall protection and million dollar network security solutions. A single careless employee an easily circumvent all these, and nine times out of ten, it’s probably unintentional.

Throwing an application into production and performing vulnerability assessment is utterly useless. Not placing security controls into your software development life cycle (SDLC) is like rolling out a new car design without performing crash tests.

So what kinds of defenses does the average web application need? Here’s a good way to figure it out. Take a look at the common application security vulnerabilities and then list the security controls that developers need to prevent those holes.

You’ll end up with a list that includes authentication, session management, access control, input validation, canonicalization, output encoding, parameterized interfaces, encryption, hashing, random numbers, logging and error handling.

Many companies, especially smaller ones are reluctant to implement such controls or develop security policies. It’s an easy step to quickly improve the overall security of your organization, no matter how many employees you have.

• Plenty of freely available standards exist and can be adopted to improve the quality of your software security.
• Developing policies can be done internally and is cheap and will immediately improve the inherent security of your SDLC.

• You’ll have documented evidence that security controls are in place throughout the development process to show your partners, clients, and auditors.

The article suggests that the average organization requires about 100 methods across all of the security controls organized in a simple library.

More technical details can be found at this excellent piece at Matasano Chargen.

Tiger and Leopard shipped with the Apple Remote Desktop agent (ARDAgent) is set UID as root. To make it worse, it supports AppleScript, and one of the actions it supports is “do shell script”. You can see where this is leading. This type of vulnerability (root access through a SUID root program) is one that I would classify as ancient. Most SUID root programs really look at the code and make sure they’re not doing something this stupid.

The solution is easy: if you’re not using Apple Remote Desktop, remove it, or chmod u-s it (removes the SUID bit).

However, this vulnerability does need local access, so it’s somewhat difficult to exploit unless you regularly leave your mac logged in at a coffee shop while you use the facilities.

What it does bring up is how much Apple is investing in secure development and security? If this (quite old style) vulnerability got through, what else would. Of course, Apple may not have any security employees old enough to remember these types of vulnerabilities. History, even of old systems and old vulnerabilities, is still useful for teaching students.

In a recent survey, one-third of IT professionals asked admitted to viewing confidential information using administrative passwords. Even more admitted to looking into information that was not relevant to the task they were performing.

“All you need is access to the right passwords or privileged accounts and you’re privy to everything that’s going on within your company,” Mark Fullbrook, Cyber-Ark’s UK director, said in a statement released along with the survey results on Thursday.

Is that really all it takes to view others’ confidential information? A password? It shouldn’t be. Here are some ideas for making snooping a little less tempting:

• Separation of Privileges – If someone has access to an account that allows them to view or change anything and everything, it will be very tempting for them to do just that. By giving different accounts limited privileges, it will be easier to track when a particular incident occurred and harder for someone to pretend they are doing one thing while actually doing another.

• Overlapping Responsibilities – Have people work together on tasks. Snooping is far less likely if someone else is present.

• Use and Review Logs – Set up policies so that everyone knows that certain sensitive activities are logged and that those logs are regularly examined. It will make most people think twice about snooping, and that second thought will usually be, “I’d better not.”

Most people want to do the right thing, and the above suggestions are just a few ways to lessen the influence of the little devil on your shoulder.

Another lost laptop story, this time from the UK. The details of the theft aren’t too unique – laptops with sensitive patient data were stolen from a hospital and a doctor’s house, and while the files were supposed to be encrypted, they weren’t. This story, much like every other data leak story, brings up the same arguments for why it isn’t a big deal:

• “The data, which also cannot be accessed without passwords, contained patients’ names, postcodes, hospital numbers and dates of birth.” (Emphasis added)
  Passwords are ridiculously weak forms of security, and, if the files aren’t encrypted, chances are the statement that access is impossible without a password is most likely just flat-out wrong


• “However they insisted there was no reason to believe the computers had been targeted for the information they contained, merely for their monetary value.”
  Targeted or otherwise, the data is now freely accessible to the thief. There’s equally no reason to believe that this will not be exploited. While historically, thieves are just in it for the quick score, that’s not really a guarantee.


• “However he insisted that only someone with ‘specialist computer knowledge’ would be able to crack the passwords and access it.”
  It’s not too hard to find people who know their way around a computer. And, thanks to the internet, specialist-type information is ridiculously easy to find.


• “‘We believe the data will almost certainly be wiped by the thief so he can get a quick sale. “
  Without any evidence that this is the case, you can believe whatever you want. I’m sure that’s really comforting to the people whose data is at risk.


• “The hospital has stressed that the data was only a copy of information stored centrally, so no details of appointments or treatment have been irreparably lost.”
  Well, thank goodness the people responsible for the data didn’t get hurt.

Every story about a data leak, regardless of the source (hospital, bank, etc), always seems to contain the same PR spin. “Well, the files are password protected anyway, and the person who stole them probably isn’t even going to notice, and it doesn’t matter because they probably just want to wipe the hard drive and sell the machine anyway, so, no hard feelings, okay? We’re sorry we weren’t adhering to the applicable laws and data protection standards, but this probably isn’t a big deal anyway.”

I understand the desire to try to mitigate the problem and reassure customers that things will “be alright”. But, these arguments are at best wishful thinking and at worst outright lying. If someone’s data could have been compromised, they need to understand the steps they need to take to protect themselves, not be reassured that it’s probably not a big deal.