Yesterday, I started getting a bunch of warnings from the anti-virus program I’ve got installed on my Mac – F-Secure Mac Protection Technology Preview. Since I wasn’t doing anything out of the ordinary or perform any “suspicious” behavior, this was a surprise to me. (Especially considering I had only received one virus alert from the software in the last 3 months.) The below is a screenshot I grabbed shortly after this began.

Every time I loaded a web page in my browser, a bunch of files would be detected and be automatically removed by the software. If I restarted the Google Chrome browser, the anti-virus deleted a critical enough file to cause Chrome to crash. Within about 20 minutes I had disabled the software and then set about trying to report it as a problem. (Notably this software does not have an option in the user interface to disable the anti-virus capability. You must run a very obscure command: sudo launchctl unload -w /Library/LaunchDaemons/com.f-secure.fsavd.plist)

What happened in this case is that the F-Secure beta software had a false-positive error, causing most if not all files to be flagged as having a virus. The F-Secure software automatically sends files to the trash when a virus is encountered and only provides the above notification window. There is no quarantine, and there is no way to restore files that are deleted.

What is notable is that I didn’t follow standard procedure. Normally when a user encounters a virus warning, the first thing they do is to scan all their files.  Since I immediately had a hunch that it was just broken, and I disabled it, I saved myself a lot of trouble.  Take a look at the pain being experienced by some of the folks in the forum posts:

I scanned my whole system and now I’ve got 90 000 files in the trash. I’m really waiting for an automated solution for this… To me this is a critical situation.

As one of the forum members noted, this is the worst possible scenario for an anti-virus software maker. While F-Secure has posted a fix along with an apology they have not yet answered my fairly critical question in the forum – how do I tell the fix has been applied? They also don’t yet have any capability to help users restore their files accidentally deleted by this error. Based on my experience, I don’t think I’ll be able to give this software a second chance.  Can you suggest alternatives?

If you’re interested in online security, you’ve probably heard about HBGary.

If you haven’t, here’s a brief rundown with a few links:
A security firm, HBGary (or, more accurately, HBGary’s subsidiary HBGary Federal) announced that they had discovered the names of some of the supposed ringleaders of the “hacktivist” organization Anonymous.
This “angered the hive” and – rather than the generally low-risk and unsophisticated DDOS attacks for which Anonymous is better known – Anonymous used a combination of social engineering, SQL Exploits, and password cracking to compromise one of HBGary’s servers. They leveraged that to get into multiple servers, ultimately gaining access to HBGary’s email and no few internal documents – including business plans and proposals to potential clients.
Anonymous then published the information they found – all of it. This embarrassed and scared off most, if all, of HBGary’s potential clients, ruined ongoing negotiations, and exposed activities which indicated questionable ethics and which might be illegal.
HBGary’s actions after this compromise might charitably be called “unfocussed” or possibly “unplanned”. “Foolish” or “Crazy” would possibly be more accurate. The HBGary CEO even engaged with some Anonymous members via IRC, to dubious results. Perhaps the best testament to this incident is the current state of HBGary Federal’s website.

Remarkably, there aren’t any new lessons to be learned here.
HBGary Federal’s first mistake was in taunting Anonymous: no matter how secure you think you are, you’re better off WITHOUT people trying to break down the gates.

The second mistake was in underestimating the enemy. Although Anonymous as a group has mostly engaged in DDOS attacks, they did so using a modified version of a professional load-testing tool: clearly some of their members have always had access to such tools and the ability to modify them. In other words, at least some of Anonymous are clearly highly capable.

The third mistake – or rather, set of mistakes – was likely the most common. HBGary’s infrastructure wasn’t properly secured. They were vulnerable to social engineering, and an important server could be compromised with an SQL injection exploit, and – worst of all – the attackers were able to use that one compromise to access nearly everything else. This is not a very good security posture, especially for a security firm.

Lastly, they didn’t have a recovery strategy. While this sort of compromise is one of the worst-case scenarios, it clearly behooves a company to plan for it, at least in a general fashion, and respond in an organized fashion which helps rebuild client trust and reduce the damage.

While these aren’t new lessons, it’s still worthwhile to look them over again: don’t encourage attacks, maintain a realistic awareness of the attackers you’re facing, harden your infrastructure, and have a recovery plan. Remember that it CAN happen to you, and act accordingly.

One of the primary weapons in a developer’s arsenal for stopping cross-site scripting (XSS) is output escaping. If an attacker can insert special characters into a page (such as < and >), they can potentially add new HTML or JavaScript and wreak havoc. By escaping data rendered by a page, you can change < to &lt; – the latter still gets rendered by the browser as < without creating a new HTML element.

However, it’s important to understand that this defensive strategy must include the concept of contextual escaping. That is, what characters you escape and how you handle them depends on the context of the output.

For instance, simply escaping or filtering every < and > is generally not enough to protect a web application. I’ve seen mainstream sites that escaped these characters, but then left quotation marks unchanged. When a parameter is rendered as HTML, " or ' may seem rather harmless. But consider this bit of code:

<script>var x = "parameter value";</script>

If the parameter value rendered here included a quotation mark, it would complete the variable definition and the rest of the parameter could be executed as JavaScript. I was reminded of contextual escaping’s importance just this week when I read this example of an XSS vulnerability in the password manager LastPass. In this case, the application properly escaped quotation marks in a script context, but still allowed characters that could close the script element and add a new one.

The OWASP XSS Prevention Cheat Sheet includes more details on characters to watch for in several common web app contexts. And remember that XSS in a JSON interface or iframe widget can be just as dangerous as obvious XSS in a search results page. Take note of where your application outputs data and make sure your XSS defenses match each context.

Stop and think about what an attacker could do if they gained control of your e-mail account. Many web sites let you reset your password via an e-mailed link. Poorly designed services may even send a copy of the password to your inbox. Much of your personal information is likely reflected in conversations you’ve had via e-mail, and services such as Gmail can store copies of all your messages.

With all this in mind, protecting access to your e-mail has become an important priority. Using strong passwords is a great starting point, but that’s only one level of security. Many companies use another system, known as two-factor authentication, to protect sensitive data, but it hasn’t been widely deployed for consumer services.

Today, however, Google is making two-factor authentication available to users of Gmail – or any other service that involves a Google account. That means that instead of logging in by simply providing information you know (your password), you also have to prove you have something: your mobile phone. Whenever you login at a particular computer/browser for the first time, you’ll be prompted for a secondary code that’s either sent to you as a text message or generated with an app on your iPhone, Blackberry, or Android device. This gives you another layer of defense against phishers and hackers trying to access your inbox.

The new feature is not enabled by default, since it requires a phone and will likely be unfamiliar to most users. But you can enable it on your Google Accounts by visiting the Account Settings page and look for “Using 2-step verification” under Personal Settings. More information is available at the Google blog.

Although we’ve made many posts about the importance of password security, have you ever wondered just how long it would take for a well-equipped attacker (having access to clusters or supercomputers) to brute force your password? Or how much more protection you gain from adding some special characters?

If you’re not inclined to crank out the numbers yourself, you might find the answers you’re looking for here.

Here are some basic stats:

• With access to super-computing-like power (trying over 1 billion per second), it only takes about 84 days to crack the common 8 character password (alphanumeric mixed case, including special characters).
• With access to a less powerful class of attack machines (10k per second), without including special symbols, an 8 character mixed-case alphanumeric password would need 692 years to brute force completely.
• Numeric-only passwords are low-hanging fruit.

The data only takes into account the maximum time it would take to brute force a password by exhausting the key space. It does not include tricks or techniques someone might use to optimize an attack. The most significant factor in the success of this approach is the use of the hardware. The price, availability, and power of hardware have a direct bearing on the protection offered by the typical single-factor password authentication scheme. In addition, as technology improves, the barrier to entry for brute forcing will drop, potentially allowing more would-be attackers to try their hand at it. Also, botnets dedicated to brute forcing passwords will get faster as the hosts (typically infected PCs) that comprise their processing power become faster. The golden standard “8 character alphanumeric+special” password is already within reach of a well-funded attacker (and has been for a while).

If you haven’t already, it may be time to start picking longer passwords for important accounts.

I just got a rather interesting email in my inbox. It’s from a travel document service. The email was about an order I had just made regarding a lost passport. Which is a bit of a trick, seeing as I’ve never done business with this company, I know exactly where my passport is, and I am not traveling internationally in the immediate future. So, at first I thought it was spam; I get emails like that all the time for services I didn’t request. Usually the spam filter catches them, but one or two do get through.

But, you know, I’d never seen this one before. I had to read it to see what the scam was. And that made it far more interesting. There’s no scam. The company is perfectly legitimate, and they’re not trying to sell me anything. It’s a real order confirmation for a real order. Benjamin Hartley really did make this request.

Just, you know, not me. My name isn’t common, but there’s at least one other person with that name. And he’s not at all careful about email addresses. I’ve had email from him in the past – or, rather, from organizations to whom he’s given my email address. I feel as if I know him. I know where he went to school; I know who he works for. I know who he donates money to. I think I even saw his birthday in one of the emails. And now I know he lost his passport. I know when he’s leaving the country. Oh, and I have all the confirmation information to get his replacement passport sent wherever I please, so if I really wanted I could have, well, quite a bit more.

I’m not going to do this of course. But I obviously could. This is potentially very damaging information. And it was just emailed to me. Not even signed or encrypted – just emailed. I’ve not been stalking this guy; I’d be happier to not be receiving this information, but it keeps coming. And, ironically, the one piece of personal information I don’t have about him is his contact information. Actually, that’s not true. I called the company, and – even though I was entirely clear to them that I was not the person who made the order – they still gave me his phone number, which is a whole different security failure.

This is really rather disturbing for two reasons. First off, my nominative doppelganger needs to be far more careful with his information. I don’t know why he doesn’t worry that he never receives the emails he’s expecting; maybe he forgets about them, or checks his email so infrequently that it doesn’t matter. But he’s not getting information which he clearly should be receiving, including some potentially compromising information. Second, the travel document service needs to be far, far more careful. They should have asked me to confirm my identity before discussing the order – at minimum a birthday, but a passport number or social security number would have been better. Of course, given that I told them beforehand that I was not the person who made the order, confirmation is the least of the problems there.

In technology, we’re generally good about confirming the destination for data. Our medium may not be secure, but the technology usually knows if it has connected to the right destination. But that’s because computers do it for us. Out here in meatspace, we’re not so careful. Like this other Benjamin, we generally just assume that our data will go to the right place – or if we don’t get it, then it’s not a problem, it just got lost. And like the travel document service, we simply assume that anyone asking about specifics must be allowed to know about them, and we don’t confirm. And that’s really all that needs to be done here – get a little confirmation that data is going to the right source before sending sensitive information. If that had been the case here, I wouldn’t have been handed this man’s personal information this way. As it is, though, it makes you wonder what other information might have gone astray. The other Benjamin is lucky; his personal information went to someone without ill intent. Others may not be so fortunate.

Many information security blogs, including this one, have discussed the recent data breach of gossip site Gawker and problems associated with leaked passwords. The story has demonstrated some of the risks associated with password storage. Gawker did store passwords using a form of encryption, but it was a weak algorithm and thus the encrypted data could be cracked. It’s important to remember that you should never simply rely on “encryption” to protect information – that’s sort of like say a bicycle is protected with a combination lock. Some locks are easier to open than others, and if the lock is attached to a weak cable or not properly looped through the frame of the bike, its strength doesn’t even matter.

With passwords, though, another option is available: one-way hashes. A hash function takes an input of data, such as a password, and outputs a value that’s always the same length and format. The algorithm is designed so that it’s easy to calculate a hash, but essentially impossible to reverse the process. Also, slight adjustments to the input drastically change the output value, and the chances of two values leading to the same hash are extremely unlikely. To use another analogy, think of a person’s fingerprint. It’s easy to capture a fingerprint using an ink pad and paper. But if you start with a fingerprint and want to identify the person it came from, you’re at a loss without a database of records to check. And once again, finding two identical fingerprints from two different people would probably never happen.

If an application stores the hash of a password instead of the actual password or a value generated by reversible encryption, then theoretically, the password would remain safe if the database were ever breached. When a user tries to log in, the application simply generates a hash of the supplied password (remember, generating hashes is easy) and compares it against the stored hash. If they match, the user has given the right password. If not, the password is wrong.

Just as people have built databases of human fingerprints, however, databases of hashes exist for common values, so only using a hash would not protect users with simple passwords. Weaknesses have also been found in older hash algorithms, such as MD5. Better options include SHA-1 and the various versions of SHA-2, but they are still not sufficient on their own. Extra protection comes from adding “salt.”

In this context, salt refers to an extra string of random information that’s unique for each saved record. This salt is then concatenated with the password and a hash is generated for the entire new string. The salt needs to be saved along with the hash in the database so that login passwords can still be verified, but it should still be kept secret as much as possible. When a user logs in, their supplied password is concatenated with the salt, hashed, then checked against the stored hash.

With this system, an attacker who manages to break in to the database will only recover salted hashes instead of actual passwords. The nature of hash algorithms means that even if a user had a simple password, the salt helps ensure that their hash won’t match any found in common hash databases. To figure out each password, an attacker would have to compute all possible values with each individual salt, vastly multiplying the amount of computation required.

Of course, just as toothpaste manufacturers remind buyers that their products are only one component of good dental health, salted hashes are only one part of a secure application. In fact, with technologies such as OpenID, OAuth, and Facebook Connect, many sites really don’t even need to handle user passwords any more. But if your application does require its own authentication, a robust implementation of salted hashes ought to be a baseline for password security.

For a while, it looked like the crypto wars had been won. Strong encryption was available, and governments were even encouraging the development of better encryption standards like AES and 3DES. Implementation is – and will likely always remain – an issue. But it was there, it was possible, and there weren’t any legal barriers to using it. And it couldn’t have happened sooner: more and more business processes are moving online, from nigh-ubiquitous email, to rolling out VoIP to save on telephony costs, to increasing outsourcing to the cloud.

The victory in the crypto wars didn’t last long. Today, there are a slew of laws in place in various countries controlling the use of strong encryption. Some, like the UK’s “Regulation of Investigatory Powers” Act allows encryption but allows law enforcement to require that information be decrypted. Others, like France, require the use of trusted third parties in case law enforcement desires the keys. Still others, like the Communications Assistance for Law Enforcement Act (CALEA) in the US require other forms of encryption backdoors be in place. In a few places, certain forms of encryption are simply illegal.

There’s good news here, after a fashion. If ever we needed independent confirmation that the current level of cryptographic technology is pretty good, here it is. Governments, in the form of law enforcement, espionage, and military are all concluding that it’s not practical to break existing encryption. (Of course, this doesn’t mean they can’t, just that they either don’t think they can do so fast enough, or that it’s too costly). Still, this is a good sign for the quality of the encryption.

The bad news, however, is that complying with the law may make your data insecure. Notwithstanding how you feel about a given government reading your files and intercepting your communication, it’s a given that if a backdoor exists for one party, it exists for anyone sufficiently motivated to find it. So what are your options?

Well, pretty much the typical ones. First of all, learn the relevant laws about cryptography wherever you’re doing business. This is actually pretty hard, as there doesn’t seem to be any authoritative list, even just for the US, and it’s pretty hard to figure out who would even know. But once you do, it’s time for some hard decisions. You may decide that you can be sufficiently secure within the limits imposed on you. You may choose to keep truly sensitive information off the network, maybe keep something in-house that you’d rather outsource. In some cases, you might even decide you can’t do business, though that’s a pretty extreme measure.

Cloud services are becoming ubiquitous, common, and more useful every day. What do I mean by cloud services? Google Apps, Dropbox, or basecamp are all cloud services. Many people (including me) use them to manage their productivity work flow. I’m a big fan of Dropbox to sync my to-do list (Things) and 1Password file between my office machine, my desktop at home, and my laptop. It just works. I also use MobileMe to take care of my calendar syncing.

But, I’m careful about what I put in my calendar, or my to-do list. Those things can tell a great deal about information that should be kept confidential – who I’m having meetings with about what can give away who our clients are and some information about them – completely unintentionally. What’s on my to-do list can give an indication of my (or my client’s) priorities.

There’s two ways of approaching the problem: control what you put into the “cloud”, or protect it before it goes into the cloud. I do a mix of both. My calendar information is limited as MobileMe won’t allow me to send an encrypted file to their caldav servers. My to-do list (and 1password file) are encrypted in an encrypted disk image in my dropbox folder. 1password does its own encryption. And if I do use dropbox to sync files, all of those files are in an encrypted disk image. I may be paranoid, but I haven’t audited these services to see what their security levels are, so I choose not to trust them. Our clients expect us to take good care of their data and protect it as well (or better) than they do, so I default to not trusting them.

Be aware of the information you are storing in the “cloud”, even if it seems silly to you. At least be aware of what data is getting pushed to someone else’s servers.

If you haven’t heard of Firesheep yet, I’ll let you go read those details for a bit. When you come back, I want to talk about why SSL is generally not used in these situations – the title gives a hint – it’s all about economics.

SSL is still quite expensive in terms of computing power. Sure, not for your computer when you’re browsing, but for a server which is handling thousands if not millions of requests per second? That’s a lot of the CPU (and RAM) being dedicated to just SSL, not counting whatever service the server is providing. There are hardware SSL accelerators, but they are also fairly limited: this one claims up to 14,000 transactions per second. What is twitter’s estimated usage? I’m not sure, I can’t find out, but with an estimated 14 million users in 2009, I’m guessing that it’s pretty high.

Now, imagine computers handling over 14 million HTTPS transactions (even within one day) – that’s a lot of transactions. That’s a lot of transactions even without SSL, but SSL brings in computational and bandwidth overhead, and those are things that these companies are paying for. Bandwidth is generally charged on a fixed fee for a certain amount, and then a per-bit rate after that.

By reducing the number of SSL sessions, they’re reducing bandwidth – and thus costs. They are also reducing the computational power needed for each of those sessions.

Should they offer SSL? Of course! Should people take advantage of it – I think so. Should they be villainized for thinking about their bottom line? Not more than any other company. But when you’ve got a user base basically paying nothing and wanting them to spend significant amounts of money on infrastructure costs, it’s not exactly fair.