Yes, the stories are true, and no, this isn’t The Onion. People are, once again, displaying their affinity for tweeting photos of things that should never be tweeted.

Let’s set the scene and put you in the shoes of a number of today’s (possibly young, possibly naïve) Twitter users: you get your first debit card, you’re excited, you want to tell your friends. But who calls or even texts in private anymore? So you take a quick picture of your newfound glory and power, then tweet about it to not just your friends, but the world—credit card number, your name, and the card’s expiration date; the works.

Don’t believe me? A new Twitter bot, @NeedADebitCard, has been retweeting these posts, and plenty of them.

The card that you see at right was posted publicly to Twitter. Note that I’m the one who actually took the precaution of blurring the number, name, and other details. In the original tweet and the many others like it, all of those are fully visible.

Considering that credit card details (along with verification codes, and billing addresses) can be bought on the black market for about one US dollar a piece if you buy in bulk, posting these really isn’t going to be tragic. Most people’s credit card details have been stolen a dozen times over (mostly through breaches of traditional merchants). But tweeting these certainly reflects some bad habits. For the record, the AgileBits store does not keep a copy of your full credit card numbers when you purchase through us. And when you purchase through iTunes or the Apple Mac Store, then we get no information about you or your purchase at all.

I laughed, but I shouldn’t have

I must confess that I laughed when Stu, my colleague here at AgileBits, pointed these out. If we want to stop people from making poor security decisions (and we certainly do), then we need to understand why people make them in the first place. Of course, some people don’t fully understand the public nature of Twitter, and that certainly plans a role in many cases. But there are other aspects of human nature at play.

There are times, and I think this is one of them, when we can’t blame the users. Instead, the blame falls with the designers of the systems that people must use. But before I talk about credit and debit cards, let me talk about Social Security numbers.

Social Security numbers and identity

For those of you outside of the United States who aren’t familiar with US Social Security numbers, they very roughly correspond to national insurance numbers or national identity numbers. They are officially used as tax payer identification numbers, among other things.

When the system was first set up, Social Security numbers were not at all secret. They were used both by banks and by employers so that income could be reported to the tax authorities. Indeed, like many people, I included my Social Security number on a résumé back in the 1980s as a courtesy to prospective employers. These numbers were used for identification in the same way that a name is, except that there are plenty of people who share my name, while I should be the only one with my Social Security number. Knowing my Social Security numbers was never intended to prove my identity. In other words: knowledge of the number was not supposed to be used for authentication.

Let’s consider this distinction between “identification” and “authentication”. Identification is how you figure out who you are talking about. Authentication is how you test whether someone really is that person. For a typical website, your username (or email address) serves to identify you, while your password is used to authenticate that identity. You may or may not wish to make your username public, but you certainly don’t want to make your password public.

Through a convoluted history that I won’t go into (in short, blame the banks), Social Security numbers switched away from being used merely for identification; the came to be used for authentication as well. They got used in a way that they were never designed for. This led to various problems, a number of new laws, and simply helped to muddle the distinction between identification and authentication.

Credit cards are more confusing

When credit cards and debit cards were originally designed, the numbers were pretty much for used only for identification, though there were exceptions. People would authenticate themselves by having physical possession of the card and by a producing a signature with a pen on a piece of paper. Certainly there was a lot of scope for fraud which meant some care was needed in not making the identity numbers all too public, but still the card numbers were not designed as authentication.

But then we started using credit cards remotely, first by making payments over the telephone and later for use over computer networks. Neither physical possession of the cards nor a signature on paper could be used for authentication any more. So the card numbers themselves, along with the three digit security (CVV), codes became the means of authentication. As with Social Security numbers, we ended up using a piece of information for authentication that was never designed to be used that way.

Here we go again. This time with checks

Over the past few years I found that when I telephone my bank, and after they have identified me, they request my checking account number. It appears that knowledge of my checking account number is now being used as part of their authentication system. Again, account numbers were never meant for this purpose. Indeed my checking account number is printed on every check I write. These are not secret.

The system that we all use has been giving people mixed messages about what is and isn’t secret. Or it’s been trying to use non-secret information in ways that are only appropriate for secrets. On one hand we are told to keep our credit card numbers secret, while on the other hand we are conditioned to toss over those numbers to any hotel, clerk, or waiter.

Helping people get things right

This misuse of Social Security and credit card numbers evolved through a process of changing scenarios and needs at the time, making due with what was available. It’s not a surprise that the system is far from what we would expect if we designed in intelligently from scratch, so of course our existing, incoherent system is going to cause confusion.

When we do have the opportunity to design something from the ground up, we have the responsibility to ensure that it is easy for people to behave securely. We may not always be able to fully succeed in that attempt, but it must be a guiding design principle for anyone who wants security systems to work for people.

Finally, when we observe people systematically behaving insecurely, we have to ask not “how can people be so stupid” but instead “how is the system leading them to behave insecurely.” Maintaining a clear distinction between non-secret identification information and secret authentication information would be one place to start.

Join the discussion in our forums

I’ve created a forum topic to discuss this article. Please join us there.

Having a Microsoft code signing certificate is the Holy Grail of malware writers. This has now happened.—Mikko Hypponen

Unless you are a system administrator for a government institution in or around the Middle East you do not need to worry about Flame infecting your computer. Flame (also known as “Flamer” and “skywiper”) itself is not a security concern except to a very narrow, targeted group. Quite simply you don’t need to worry about being infected by Flame, and antivirus vendors who suggest otherwise may be engaging in fear mongering.

With so few people in danger of Flame, why am I writing about it? Good question. I’m writing about it because one of the methods used in Flame has the potential of undermining a crucial part of computer security. The authors of Flame have the ability to subvert the Windows Update process. Whatever Flame itself does or doesn’t do, the fact that its authors acquired the capability to distribute fake updates to Microsoft Windows is cause for serious concern.

Putting trust to the flame

The authors of Flame have acquired the ability to digitally sign their own updates to Microsoft Windows as if they were (almost) Microsoft. They have been able to create digital signatures in a way that will successfully fool the Windows Update process. Microsoft made a series of mostly innocent blunders in creating some intermediate Certification Authorities that are used by customers to creating individual licenses for a particular product. However, in combination those blunders on something that was not supposed to be part of the critical system turned out the have major consequences.

Microsoft has issued a security update, which you get via – you guessed it – Windows Update. It is not clear (to me, at this point) whether these updates fix the long term problem or just fix the Flame-specific signatures. In a notice on June 4 they state that the June 3 update was the first of a series of actions in a phased mitigation strategy. So there will be more to come.

But the most interesting thing (to me) in their notice is

The Flame malware used a cryptographic collision attack in combination with the terminal server licensing service certificates to sign code as if it came from Microsoft. [Emphasis added]

And this gives me the opportunity to discuss an important concept in cryptography that I haven’t talked about before.

Hashes and Collisions

In the article about Gatekeeper I talked a bit about some of the mathematical magic behind digital signatures, but I left many pieces out. The digital signature of a file is not actually a signature of the file directly. For a number of technical reasons it is too unwieldily to directly construct a signature of a large chunk of data; the file itself would need to be treated is a single enormous number that is then used as an exponent of some other large number. If the file were just 10 kilobytes, its number would be on the order of 281920 (about 25,000 digits long). We deal with some really big numbers in cryptography, but we would like to just deal with numbers about the size of 2256 (around 77 digits).

To create a digital signature of a file we first need to do is reduce the file (no matter how big it is) to a number in the range we can deal with. We create a cryptographic hash (sometimes called a message digest of a file) and then digitally sign that hash. If a hash function (something that takes all the data in a file and produces a smaller number) is to be useful for digital signatures it must have a number of security properties. The security property we are interested in today is called (strong) collision resistance.

Collision resistance

It must be infeasible to find or create two distinct files that have the same hash.

Any time you have two distinct files with the same hash you have a collision. In principle collisions are inevitable because there are more possible files than there are hashes, after all, the point of the hash to turn a really big chunk of data (a file) into a smaller (though still big) number. Instead the security of hash functions relies on how difficult it is to find or create collisions.

In a recent article, I talked about another security requirement of a cryptographic hash. It must be infeasible to calculate anything about the original file from the hash. That is called pre-image resistance, but today’s topic is collision resistance.

Danger: Collision ahead!

Now let’s look at why collision resistance is important for digital signatures. Suppose that Patty, one of my dogs, creates two files. One of them says, “Molly is the cleverest and prettiest dog ever, and Molly gets to rule.” The other file that Patty creates says, “Patty will get all of Molly’s dog treats.” Patty, of course, is the clever one. She is able to create these two files so that they produce the same hash. Patty has created these to files in such as way that their hashes collide. Patty asks Molly to digitally sign the “Molly rules” file, and Molly is happy to comply. Molly, using her secret key, creates a signature for the “Molly rules” file. The digital signature is actually a signature of the hash of the file, and so that signature will also work as a signature for the “Patty gets all the treats” file.

Patty will then bring me the “Patty gets all of Molly’s treats” file along with Molly’s signature. I calculate the hash of the file and verify that the hash really is signed using Molly’s secret key. Nobody but Molly knows that secret key, and so I figure that Molly must have signed that file. I give all of Molly’s treats to Patty. Molly may like to collide with Patty on walks, but this is one collision that Molly is not at all happy about.

It’s more than just dog treats that are at stake here. As I described in the Gatekeeper article, it’s not just ordinary files that can be signed (or more correctly, have their hashes signed), but certificates and Certificate Authorities are also just data that can be signed. The signature on a certificate helps our computer determine whether it can trust that certificate. If Molly controls a Certification Authority (CA) Patty can ask Molly’s CA to sign a certificate for Patty that Molly is happy to sign. But if Patty has another, trickier, certificate that produces the same hash as the one that Molly signed, Patty can simply add Molly’s signature to the bogus certificate.

The solution is to make sure that the hash function that is used for signing certificates (or files related to dog treats) is collision resistant. In particular this means that the MD5 hash algorithm should not be used. Unfortunately some of Microsoft’s Certification Authorities use the MD5 hash system. The MD5 hash system is badly broken, and it is very possible to generate collisions.

The downfall of MD5

Cryptographers don’t talk about “impossible” or “possible”; they talk about “feasible” and “infeasible”. An infeasible task usually means something like “if you used all the computing power on Earth now and for the next decades, would still have only a negligible chance of successfully completing the task.” With MD5 we’ve witnessed the progression from “secure” to “weaknesses that are infeasible to exploit” and eventually to “practical exploits” in the space of about 10 years.

MD5 (Message Digest 5) was shown in 1995 to have theoretical weaknesses. From there the history is remarkably interesting (if you are into that sort of thing). There was one group of people who were saying “don’t use MD5 any new software or systems; use SHA1 instead.” There was another group saying that the weaknesses in MD5 don’t pose an actual threat to how it is actually used. By 2005 it became absolutely clear that the weaknesses in MD5 had been expanded and could be leveraged into real attacks, and in 2008 there was a spectacular demonstration to create a rogue Certification Authority. An important side note is that while the advice to use SHA1 instead of MD5 was very good advice in 1995; today that advice is to use SHA2 instead of SHA1.

As we all watched MD5 go from secure to completely broken with respect to collision resistance in the space of ten years, we also saw that its use continued. I think that many of us failed to understand just how easily collisions could be exploited. It was tough to steer a course between people panicking on one side who were saying that anything involving MD5 was tainted and those on the other side who always seemed to think, “sure MD5 has its weaknesses, but those weaknesses don’t affect my application.”

Microsoft using MD5 in 2009

People continued to use MD5 for a number of purposes that they didn’t see as critical. The intermediate certification authority that Microsoft set up for signing Terminal Services licenses was, presumably, thought to be not critical enough to worry about. The worst (they thought) that could happen is that customers could create a few extra licenses for themselves if they went through the effort to create collisions. So as even as late as 2009 Microsoft created CAs that used MD5 as its hashing algorithm. They turned out to be wrong about “the worst that could happen”. Other blunders allowed a weak CA created in 2007 to sign certificates for other CAs.

Using the same trick that Patty pulled on Molly, an attacker could get a signature for an acceptable CA to work on a malicious one. The malicious one could then be used to sign false updates to Windows. Thus, the attacker would have the ability to sign things that would look like legitimate updates to Windows.

Microsoft has recently (June 6) provided more details, which confirm that what I’ve described above did play a role in the creation of the signatures for the bogus updates.

Lessons

Follow early warnings

When we, the technology community, were advised in 1995 to stop relying on MD5 we should have been quicker to make the transition to SHA-1, even though at the time it wasn’t clear how those weaknesses could be exploited. Likewise, we should follow the same warnings about SHA-1 today. We shouldn’t panic every time a theoretical weakness is found, but we should remember that these can often be leveraged in ways we can’t predict.

Hash algorithms are hard. MD5, as you’ve seen deteriorated rapidly. SHA-1 has been shown to be less than ideal (not yet exploitable in practice), and even its replacement, SHA-2 isn’t all we would hope it to be. Cryptographers and the NIST are working on finding a system to become SHA3. If you have a high tolerance for geeks singing out of key, you may wish to sing along to the SHA-3 song.
The refrain is

SHA-2 will soon retire
Because NIST is learning and SHA-1 is burning
SHA-2 will soon retire
No we didn’t light it but tried to fight it.

The trust infrastructure is fragile

There are a large number of Root Certification Authorities and an even larger number of intermediate CAs. As we’ve seen here, the chain of trust can be compromised through some poorly designed CAs. As we saw last summer, in the case of DigiNotar, a Root CA can have their computer systems compromised allowing an attacker to gain accesses to the secret key needed to sign certificates. A third possibility is that the operators of CA may simply go rogue.

Charles Dudley once noted that “everybody complains about the weather, but nobody does anything about it.” The same can be said about the trust infrastructure that so much of our security relies on. Fortunately there are a few talented people who are working on serious proposals that, while they won’t completely fix the system, will mitigate some of the problems. I won’t review them here.

Are governments friends or foes of computer security?

Flame is almost certainly the creation of a “Western intelligence agency”. A few weeks ago, I would have guessed that it was an Israeli creation, but recent news about the creation of Stuxnet leads me to suspect that Flame, like Stuxnet, was primarily created by the United States. Parts of the US government have done and continue to do a great deal of important work in promoting good security. But we now have an example where the government has undermined a crucial part of computer security.

So far the victims of state-sponsored attacks on the certificate trust infrastructure have been in Iran. Last summer the government of Iran used certificates from a compromised Root Certification Authority, DigiNotar, to interest “secure” connections between individuals in Iran and Gmail. Now it looks like like the US (or possibly Israeli) government has been using poorly constructed Microsoft Intermediate CAs to target specific entities in Iran.

The good news, I suppose, is that these governments still had to exploit vulnerabilities instead of, say, compelling Microsoft to sign bogus updates. Of course, we cannot rule out that government agencies asked Microsoft to include those vulnerabilities. I suspect that Microsoft’s errors were innocent because they are the kinds of errors that people and organizations do make, but I can’t entirely rule out the more paranoid interpretation.

Security has a lot of moving parts

Each of the mistakes that Microsoft made were probably harmless on their own. No doubt they were made by different people who weren’t aware of the decisions that others had made. In combination, the mistakes add up to several ways of generating “good” signatures for bad Microsoft Updates, something with potentially catastrophic consequences.

A few closing remarks

Truth and speculation

I have speculated about how Microsoft made the errors that they did, and I have speculated about what the creators of Flame have done with that. What we do know is the bogus certificates for signing Windows Updates were created, and we know what Microsoft has said about it. We know that CAs using MD5 in their digital signatures are vulnerable in the way discussed, and we know that that the bogus certificates were signed by those weak CAs.

We also have a rapidly changing situation. It shouldn’t be too surprising if much of what I say about the specifics of the case today is out of date by tomorrow. Still, it gave me the chance to talk about hash functions and attacks based on collisions, along with the problems of using MD5 for digital signatures. Furthermore, Patty and Molly are always seeking attention, so they appreciate that I’ve mentioned them here.

Continuing the discussion

Updates

This article was out of date before it was finished, and I expected that there would be more news to come. And so to avoid a continues series of updates, I will be adding updates to the forum thread set up for the purpose.

However, the news that came out right after this article was posted is so jaw dropping that I will repeat it here.

People have always speculated about how far ahead in cryptanalysis agencies like the NSA or GCHQ are compared to what is known by the academic community. The assumption is that the gap has been narrowing over the decades as there is more open work in cryptography done outside of intelligence agencies. We don’t often get data to help pin anything down with our speculation, but this definitely is interesting.

The Ars Technica article linked to above has a terrific diagram outlining the nature of the general technique used to create MD5 collisions.

I am not giving anyone health advice. Instead, I’m going to use the example of the recent LinkedIn breach to talk about hashes and salt. Not the food, but the cryptology. Before you dive into this article, you should certainly review the practical advice that Kelly has posted first. Also Kelly’s article has more information about the specific incident.

I’m writing for people who saw security people talking about “salt” and want to know more.
You may have seen things like this, that appeared in an article at The Verge.

It’s worth noting that the passwords are stored as unsalted SHA-1 hashes. SHA-1 is a secure algorithm, but is not foolproof. LinkedIn could have made the passwords more secure by ‘salting’ the hashes.

If you would like to know what that means, read on.

What we know

We know that a data set of about 6 million password hashes has been released. We also know that this does include LinkedIn passwords (more on how we know that later). The data made public does not include the usernames (email addresses), but it is almost certain that the people who got this data from LinkedIn have that. By the end of this article, you will understand why people who broke in would release only the hashes.

Hashing passwords

Websites and most login systems hash passwords so that they only have to store the hash and not the password itself. I have been writing about the importance of hash functions for a forthcoming article, but here I will try to keep things simple. A hash function such as SHA-1 converts a password like Password123 to “b2e98ad6f6eb8508dd6a14cfa704bad7f05f6fb1″. A good hash function will make it unfeasible to calculate what the password was if you only know the hash, but the hash function has to make easy to go from the password to the hash.

A hash function always produces the same hash from the same input. It will always convert “Password1″ to that same thing. If both Alice and Bob use Password123, their passwords will be hashed to the same thing.

Let’s put rainbows on the table

Even if Bob and Alice use the same password (and so have the same hash of their passwords) they don’t have to worry about each other. Who they need to worry about is Charlie the Cracker. Charlie may have spent months running software that picks passwords and generates the hashes of those passwords. He will store those millions of passwords and their hashes in a database called a “Rainbow Table.”

A small portion of Charlie’s table may look like this

Password

SHA-1 Hash

123456

7c4a8d09ca3762af61e59520943dc26494f8941b

abc123

6367c48dd193d56ea7b0baad25b19455e529f5ee

Password123

b2e98ad6f6eb8508dd6a14cfa704bad7f05f6fb1

…

…

(Rainbow tables are structured to allow for more efficient storing and lookup for large databases. They don’t actually look anything like my example.)

When the hashed passwords for millions of accounts are leaked, Charlie can simply look up the hashes from the site and see which ones match what he has in his tables. This way he can instantly discover the passwords for any hash that is in his database.

Of course, if you have been using 1Password’s Strong Password Generator to create your passwords for each site, then it is very unlikely that the hash of your password would be in Charlie’s table. But we know that not everyone does that.

Charlie also has a lot of friends (well, maybe not a lot, but he does have some) who have built up their own tables using different ways of generating passwords. This is why Charlie, who has both the usernames and the hashed passwords, may wish to just circulate the hashes. He is asking his friends to help lookup some of these hashes in their own tables.

I also promised to tell you how we know that the leaked hashes are indeed of LinkedIn passwords. If someone has a strong unique password for their LinkedIn account it is very unlikely that it was ever used elsewhere. So if the hash for that strong and unique password turns up on the leaked list, we can know it is from LinkedIn. This is presumably what Robert Graham did when determined that this is the LinkedIn list.

Salting the hash

More than 30 years ago, people realized the problem of pre-computed lookup tables, and so they developed a solution. The solution was to add some salt to password.

Here is how salting can work. Before the system creates a hash of the password it adds some random stuff (called “salt”) to the beginning of password. Let’s say it adds four characters. So when Alice uses the Password123 the system might add “MqZz” as the salt to the beginning to make the password MqZzPassword123. We then calculate the hash of that more unique password. When storing the hash, we also use store the salt with it. The salt is not secret, it just has to be random. Using this method, the salted hash that would be stored for Alice’s password would be “MqZz1b504173d594fd43c0b2e70022886501f30aee16″.

Bob’s password will get a different random salt, say “fgNZ”, which will make the salted hash of his password “fgNZ2ec6fa506fa9048d231b765559e2f3c79bdee5a1″. This is completely different than Alice’s, and – more importantly – it is completely different from anything Charlie has in his rainbow tables. Charlie can’t just build a table with passwords like Password123, instead he would have to build a table that contained Password123 prefixed by all of the two million possible salts we get using a four character salt.

Beyond salt

Salting is an old technology, yet a surprising number of web services don’t seem to be using it. This is probably because many of the tool kits for building websites didn’t include salting by default. The situation should improve as newer toolkits encourage more secure design, and also as these issues make the news.

But just as we are getting people up to speed with a 30 year old technology, salting may no longer be enough. And mere salting certainly isn’t good for the passwords that require the most security. To defend against determined and resourceful password crackers you should use both strong passwords and a password based key derivation function likePBKDF2, which 1Password does use when encryption your Master Password.

Today it was reported LinkedIn had a password breach. This is the most frustrating sort of security problem, because even if you’re using all the security available on the longest most complex password you can generate, that doesn’t help if someone else gets ahold of it. As more and more services are offered online, and then connected to other logins you already have, it’s not just a minor password change when something happens to, for example, your Facebook password. Now you have to worry that whoever got access to Facebook now has access to all those other things. Do you even remember what ALL those other things are?

As part of the “security is a process, not a product” philosophy we use here at AgileBits, there are a variety of things to consider when you want to secure your online activity. One such thing is what I mentioned above: those other apps and services you authorized to use your login on Facebook or Twitter, or in today’s current example, LinkedIn. It’s a good idea to review those permissions periodically, and one handy way to do that is with a site called MyPermissions.

You can think of MyPermissions as a dashboard for reviewing and controlling your preferences across many of these sites at once. It’s like cleaning out your closet and getting rid of all those things you have no more use for. Hopefully you won’t have too many “I authorized THAT!?” moments, but if you do, revoking access is usually pretty easy.

On the upside, one of the nice things about 1Password is the extra layer of security it provides with the Strong Password Generator. As long as we see that “Password1″ is still one of the most popular passwords in use, you, dear 1Password and Strong Password Generator user, are already way ahead of most people when it comes to securing your data.

If you still have friends, family, or coworkers who just don’t get why strong passwords are more important than ever, here’s an analogy that might help: Using a really common easy password (password, Password1, 123456, etc) is the equivalent of leaving the windows down and the keys in the car. Using 1Password is locking the car, rolling up the windows, and having an excellent alarm system. Why would a thief bother with your car when there’s one right next to it just begging to be stolen? Particularly when we are talking about logins that store credit card data (Amazon 1-click, anyone?), a nefarious person will be happier with the hundreds of numbers they can snag in less time than it would take to crack your password.

I know it’s frustrating to have to keep track of all of this, but it’s really no different than real life. I always think of the Public Service Announcement on television where a guy walks up to people in a coffee shop and starts trying to convince them to let him use their bank account for a wire transfer. Everyone turns him down and the ad says “If you wouldn’t fall for it in real life, why fall for it online?” It seems like more work because most of us haven’t been doing this our whole lives, so it’s not second nature like “don’t wave around the money you just got from the ATM” and other life tips we now consider common sense.

Having said all that, here are some useful information and steps to find your weakest links and strengthen them.

You can start by opening 1Password for Mac and selecting View > Layout > Traditional. Once there, then go to View > Columns > Password Strength, and make sure it’s enabled. Now you can see, and sort by, the security of all your passwords. If you want to collect the weakest passwords, create a Smart Folder to show those. Go to File > New Smart Folder, and a search dialog will pop up in the top of your window. Make sure you set the search criteria in the bar at the top to search “Everywhere” and “Everything,” and below that select the following:

All of the following are true:

Password Strength

is less than or equal to

Select a number here. It doesn’t matter what number you use. Start with 40 and if that looks overwhelming, switch to 20. Once 20 is done, then go back to 40. This is your first pass at updating passwords.

Click Save, and retitle your New Saved Search something else (Mine is just called Weakest).

When you have time to devote to updating these weaker passwords, you can use the Password Generator within 1Password to update them. As you increase the strength, they will no longer show in your Smart Folder.

Now you’ve updated all of the ones that were the weakest. Hooray! Now right-click (or ctrl-click) on your empty Smart Folder and choose Edit Smart Folder… and bump up that number. Now if you have a few more showing, get those updated too.

Of course, I don’t expect you to drop everything and blow your weekend on the exhilarating task of updating your passwords. But when you have a little time to spare, knock off a few here and there. The next thing you know, your weak passwords are history.

The Flashback Removal Security tool is now available for Leopard users on Intel Macs. Leopard Security Update doesn’t actually fix any weaknesses in the operating system; its only job is to disable old versions of Adobe Flash Player and encourage people to upgrade to more recent versions of the Flash Player.

Beyond the ordinary

I am hesitant, without doing more research, to call this kind of security update “unprecedented” from Apple, but I am more than willing to call it “extraordinary”. Providing an security update to systems that have long fallen off the “supported” versions is highly unusual. I can only speculate that Apple has examined which systems have been most effected by Flashback and it taking extraordinary steps to help clear that up where it needs to.

Leopard users are still not covered

I have been pleading with people to keep their systems up to date. If you must run OS X Leopard then you should take extra care to keep your web browsers up to date, and (if you use it at all) Adobe’s Flash player up to date. Adobe’s Flash about page will let you know what version you are currently running.

Apple’s two extraordinary updates do only two things. They provide the Flashback removal tool for Leopard users and they prevent Leopard users from using outdated versions of Adobe Flash. They do nothing whatsoever to bring the enormous security enhancements and fixes that have been brought to Snow Leopard and Lion.

I’ve been talking a lot lately about the importance of keeping systems up to date and the role this plays in keeping malware at bay. I even suggested that Mac users are particularly good at keeping there systems up to date. So if you’re on OS X 10.6 Snow Leopard or 10.7 Lion, please help prove me right by running Software Update now.

Apple has released a big update from OS X 10.7.3 to 10.7.4, which includes many important security fixes, among them a fix for the the FileVault issue we talked about a few days ago. The security update is also available for those running 10.6.8 (Snow Leopard). Among the many important security updates are fixes for Safari, WebKit (used by Safari and much, much more), Bluetooth, and QuickTime.

Unsupported systems are unsupported

If, for some reason, you are using an older, unsupported, version of Mac OS X such as Leopard (OS X 10.5) or Tiger (10.4), your system is unprotected. As I explained last week, the large majority of security flaws that get exploited by malware are things that people could have avoided if only they kept their systems up to date.

On a similar note, Mozilla, the makers of Firefox, stopped support for Firefox 3.6 in April. Running the updater from within Firefox 3.6 should bring you to the current version, Firefox 12. Our modern 1Password extension for Firefox uses the same powerful and flexible design that we have for Safari and Chrome; and it makes future browser upgrades a breeze.

Home Folders, FileVault, and passwords

One of the things that the OS X update fixes is the aforementioned FileVault problem. If your system was set up in such a way that your login password was needed for your Home Folder to get loaded by the system, your login password may have been written to system logs in plain text. The most typical way for this to happen is if you had configured FileVault to encrypt your Home Folder back before OS X 10.7 (Lion) and upgraded your way to 10.7.3.

The same problem may also occur if your Home Folder is mounted from a network server. This is because, even under these circumstances, the actual bug was not in FileVault itself, but in the system that handles using login passwords for mounting Home Folders. Anyone with administrator powers on affected Macs could simply read everyone’s login password.

You might think that, if someone has administrative powers, it doesn’t matter if they also have your login password for your Mac. As usual, things are not that simple. It does matter if others get ahold of your login password, even if they already have administrative power on the Mac you use. First, there is the fact that many people reuse passwords like this (so they could compromise your other accounts), but your login password is also used to encrypt your OS X keychain. This includes things like passwords that Mail.app, iCloud, iChat, Safari, and many other apps may store in your OS X login keychain. An attacker with administrative powers, but without your login password, can not get at that information. But they can if they have your login password.

Remove old system logs that contain the old password by following the instructions in Apple’s support document on removing sensitive information from system logs.

It’s great that Apple was able to fix this quickly. The error really was an embarrassing blunder. But while this particular fix may be getting the headlines, there are many other important security fixes. Don’t for a moment think that you can skip it just because you aren’t affected by that specific bug.

In Part 1 of this series I discussed how your 1Password data may (or may not) be threatened if your computer gets infected with some kind of malware, particularly Flashback. In Part 2, I reviewed the few simple things everyone should do to keep their systems safe. In this part, I will discuss ideas about the relative threats of malware on Mac and Windows, and what has been changing.

I have a nearly perfect record of making incorrect predictions about malware on the Mac, putting my prognostication skills on par with DigiTimes. For many years I’ve been saying that malware will become a serious issue on OS X “in the next year or two”. I have been consistently wrong with those predictions. So about a year ago, I took a different approach. I tried to understand why I had been wrong, and listed a few new reasons why there hasn’t been a real malware problem on OS X. What I offer here – instead of anything resembling predictions – are some things to keep in mind when trying to understand the relative frequency of malware on OS X versus Windows.

It isn’t 2002 any more

Bob and Charlie are out camping when a bear attacks their campsite and comes menacingly toward them. Bob puts on his running shoes. Charlie asks, “why are you putting on your running shoes? You can’t out run the bear.” Bob answers, “I don’t need to out run the bear. I only need to out run you.”

When OS X was first introduced, it was perfectly correct for people to be pleased that Apple had “brought the security of Unix” to the Mac. In comparison to the competition, and especially in comparison to Mac OS 9, the Unix security architecture was a great improvement. Unix had been designed from the outset to be a multiuser system. A single Unix computer was designed so that several different people could use the computer (and at the same time). This meant that not everyone using to computer was supposed be be master of everything that is on it. Individual users needed to be protected from things done deliberately or accidentally by other users, and the system as a whole needed to be protected from its users.

Unix, then, had important security features built into it from the beginning. Operating systems that were designed for personal computers didn’t initially have these kinds of protections. For the most part, the user, and any program that they ran, could do anything with the system. Over time, Microsoft added more protections into Windows, but it still was hampered by its legacy. Macintosh operating systems, up to and including Mac OS 9, offered no protections against the damage that a single user program could do. In the years immediately after OS X was introduced it was perfectly correct to say that it has better security because OS X rests on secure Unix foundations. Some of you may recall the “I’m a Mac” adverts that highlighted the fact that Macs were far less prone to malware than Windows systems were. Apple’s relatively low market share, and the relative security strength of OS X at the time, meant that few malware developers targeted the Mac.

But a lot has changed since those days. Not only has the number of Mac users increased enormously since OS X was introduced, but Windows operating systems became much more secure. Between the time that Windows Vista was introduced in January 2007 and OS X 10.7 (Lion) was introduced in July 2011, it is very reasonable to say that Windows had the more secure design. (People may legitimately argue that Windows was stronger during other periods as well, but I want to specify a time that pretty much everyone will agree on.) It should be noted that it was near the time that Vista came out that Apple toned down its claims of relative security in its advertising.

Last summer I had the pleasure of visiting the Grizzly and Wolf Discovery Center in West Yellowstone, Montana. Among other things, they test containers for “bear resistance”. It is clear that bears will take the easier approach. If the carefully designed bear proof lid is too much trouble for them, they will look for something less secure. If bears understand that relative security is what matters, I think we should learn this lesson from them. Returning to Bob and Charlie we see that when running away from an angry bear,you don’t need to be faster than the bear itself; you only need to be faster than others that the bear might be after.

OS X has been consistently improved over the last five years, but by many measures it had a poorer security architecture than what was available from Microsoft during that time. When malware developers are looking what targets to put effort into, they are looking at the relative payoffs and ease of attack. Andy Greenberg, over at Forbes, discusses the importance of looking at strengths and weaknesses in relative terms.

The increasing number of Macs and the shifts in the relative strength of the security architecture led me to make my spectacularly incorrect predictions about Mac malware during the past decade. (Fortunately for any reputation I might have, I only made those predictions on Usenet, which – I suppose – almost keeps those statements protected by stegenography.)

Although my predictions turned out wrong, I don’t think it was because I misevaluated the relative security of the systems. Nor do I think that I was wrong about the importance of relative security. After all, I should be smarter than the average bear. Instead my error was that I failed to look at other things that kept malware developers focused on Windows. Let’s look at those now.

Malware development toolkits were Windows specific

When a malware developer finds a way into a system, they need to be able to do something once they are inside. Returning to the Trojan wars analogy from the previous article, when Ulysses and his army were finally inside the gates of Troy, they needed to have swords and spears to complete the job. Pea-shooters would not have done them much good, even though they did breach the defenses. Over the decades, malware developers have assembled a large arsenal of tools they can use once they’ve found a way to sneak in.

Because malware developers have a huge set of tools and knowledge developed over decades from exploiting Windows systems, it is easier for them to get results attacking Windows systems. If they attacked Macs, they would need to develop many of those tools from scratch. Economists call this “asset specificity.” If you manufacture trucks, but see a potential for more profit in selling motorcycles, you will be reluctant to make the move because you would have to retool your factories and develop entirely new sales and distribution networks. That is: you already have a system (assets) in place for manufacturing and selling trucks, and you would need to acquire new (costly) assets to shift to the motorcycle business.

My biggest worry for malware on the Mac is that the bad guys have developed the specific assets needed to make going after the Mac profitable for them. The (still developing) history of Flashback illustrates that toolkits are now being developed for the Mac. When Flashback was first discovered in September 2011, it was delivered as a Trojan; in fact, it masqueraded as an Adobe Flash installer. It got into a system because people downloaded and installed software that they thought was legitimate but turned out to be malicious. But Flashback didn’t spread very much that way. This history, by the way, is why Flashback is still described as “Flashback Trojan”—the label it received first.

Flashback really got going after its delivery mechanism was changed to exploit a vulnerability in Java. The guts of Flashback could be reused in light of a new way into someone’s computer. Now that the version of Java installed on Macs has been fixed (for those who keep their systems up to date), there is yet a new version which makes use of a (patched) vulnerability in MS Office 2011 for Mac. Microsoft has issued a fix for this vulnerability, but if people aren’t keeping MS Office up to date on their systems, Flashback can get in this way.

Flashback has been something new in a number of ways, and so it isn’t clear whether it will remain an exception or whether it does signal that things are changing. Either way, I don’t think that Mac users can rely much longer on malware developers lacking the toolkits to go after Macs. Fortunately, there are other things that may still keep Mac users relatively safe.

Different update habits

I’ve described at great length in Part 2 the importance of keeping systems and software up to date to prevent infection. As I explained there (complete with a slick chart), the majority of bugs that get exploited on Windows are things that have already been fixed, and users would have been protected from those if they kept their software up to date.

Flashback was an exception to this. The Java bug that Flashback exploited to get into people’s system remained unpatched for several weeks after it was known to be leveraged by Flashback. It is interesting that, while most Windows exploits take advantage of patched vulnerabilities, the one substantial OS X exploit grew through an unpatched vulnerability.

This difference illustrates my point in why Mac users may have been safer than Windows users. Mac users may simply be better at keeping their systems and software up to date. There may be a number of reasons for this, and I would like to speculate about some of them. Let me be clear that I do not have evidence that Mac users are better about updates than Windows users, although there is some suggestive evidence.

For example, more than 40% of all Windows users are still using Windows XP (superseded by Windows Vista in January 2007), while fewer than 10% of Mac users are using Leopard (superseded by Snow Leopard in August 2009). However, we can’t say that this is because of better update habits. First, the numbers I reported were collected in different ways, so they might not be directly comparable. More importantly, Apple has maintained for years that around 50 percent of its quarterly Mac sales are to new customers—also known as “switchers”—so they have more recent systems, and therefore current versions of Apple’s OS by default. Still, I am going to offer ideas about why Mac users may be better with updates.

More of the software that people use on OS X comes from a single source (Apple) than is typical on Windows. Other than the operating system and Microsoft Office, the software that Windows users regularly use comes from a variety of different places. Where a Windows user will be using Adobe Reader for reading PDFs, a Mac user will be using Apple’s Preview; where a Windows user might be using Photoshop Elements, the Mac user will be using Apple’s iPhoto or Aperture; where a Windows user may be using iTunes to organize music for the iPods and iOS devices, the Mac user will be using, well, iTunes. For the Mac user, all of these come from the same place and are updated via tools Apple built into its OS, which have long been configured out of the box to run once a week.

Mac users know where their hardware and operating system comes from. Windows, like OS X, is typically purchased with the computer hardware. But while the Mac user will typically be making their purchase from Apple, a Windows user is not making their purchase from Microsoft. Instead, they are purchasing from an Original Equipment Manufacturer (OEM). The OEM—such as Gateway, Dell, or Hewlett-Packard—also add a bunch of stuff to the Windows systems that get distributed. Among these will be items that highlight the brand of the OEM. As a result, many Windows users are left confused about their operating system and where to go for updates. Many times when I’ve asked a Windows user what version of Windows they are running, I would get an answer like “Dell” or “Hewlett-Packard.” Whatever complaints people may legitimately have about Apple’s control over both the software and hardware, it does avoid confusion for the user.

Where you get your software

I discussed Trojan horses extensively in Part 2 of this series, and as with keeping systems up to date, there may be behavioral differences between Mac and Windows users that make Mac users less vulnerable.

One recent difference is that Mac users have the Mac App Store. Apps sold there have been reviewed by Apple. Although some anomalies may occasionally slip through that review process (though, to date, I am not aware of any), it dramatically reduces the chances of anything installed from the Mac App Store containing a Trojan. And in the future, the use of Gatekeeper in Mountain Lion will provide additional ways for Mac users to see who their software is coming from and that it hasn’t been tampered with along the way. The Windows 7 installer, though, already checks the digital signature attached to distributed software.

But those differences are too recent (or yet-to-arrive) to offer any explanation of what has happened over the past decade. It is possible that there are, to some extent, differences in people’s willingness to acquire software through less than reputable third parties. I have no evidence to back this up, other than the (surprising to me) relative lack of Mac infections due to Trojans over the past decade.

About the future

Given my abysmal track record on predicting malware on the Mac, I will hedge and qualify any predictions that I hint at here. I will note that Flashback did overcome some of the things that I’ve said protect the Mac environment. It suggests that malware creators are developing toolkits for use against OS X. This is what I see as the most worrying sign for Mac users.

On the other hand, I am confident that Apple learned a great deal about getting things patched quickly; they are already being very proactive in reducing the threats of Trojans, and Mac users may continue to be relatively good about keeping systems up to date.

If you have been using Apple’s FileVault to encrypt your home folder on OS X, read on. There is an important security bug and action you should take. This is an Apple security issue that does not affect 1Password 3 or Knox for Mac, but it is an important enough issue that I’m announcing it here.

This only affects those who had set up FileVault to encrypt their Home Folders (not the entire disk) prior to OS 10.7 (Lion) and have since upgraded to Lion 10.7.3. If you don’t use FileVault, or if you use FileVault to encrypt your entire disk, all is fine on your system.

Very simply, if you use FileVault on your Home Folder (something that can only be set up prior to OS X 10.7) then a bug in OS X 10.7.3 is logging your OS X login password in system logs. This is described in an article on ZDNet’s Zero Day Blog.

If you are among the affected users, then you should

Go to System Preferences > Security > FileVault and change your settings to encrypt the entire disk. That is, you should use the much improved FileVault in OS X Lion.

Change your OS X Login Password through account preferences

There will be other concerns as well, as your old password (usable for decrypting Time Machine backups) may still be available to other administrator users on your system. This typically isn’t a concern for home users, but it can be important for Mac in an office environment.

carefully built crypto has a unfortunate tendency to consist of three thick impregnable walls and a picket fence in the back with the gate left open … Nobody breaks encryption by climbing the high walls in front when the garden gate is open for millions of machines.

Just the place for a Snark! I have said it twice:That alone should encourage the crew.Just the place for a Snark! I have said it thrice:What I tell you three times is true.

—Lewis Carroll “The Hunting of the Snark”

In Part 1 of this series I discussed how your 1Password data may (or may not) be threatened if your computer gets infected with some kind of malware, particularly Flashback. Of course, it is better for your computer to not be infected in the first place, so in this article I focus on a few tips to help keep your computer safe from malware. Part 3 will outline a way of thinking about the differences and similarities in the threats from malware on Mac and Windows.

Before I get into the list of tips that you can do to help keep your computer malware free, I’d like to say a few words about a few words. I hate the word “malware”; it’s awkward and ugly. Unfortunately that is the word we have. Words like “virus”, “worm”, “trojan”, “drive-by” and so on refer to how the particular piece of malicious software spreads. It tells us nothing about what they do. I will use the term “infected” to refer to a computer system that has some malware installed and functional on it.

As I said twice before in Part 1 (and, really, as we’ve always said), the most important thing you can do to specifically protect your 1Password data is to use a good Master Password. The proof is complete if only I’ve stated it thrice.

1. Keep your software up to date

The single most important thing you can do to protect against malware is to keep your software up to date.

The large majority of system compromises are through vulnerabilities that the software vender has already released a fix for. Flashback was unusual is that the Java vulnerability that was exploited had not already been patched (although it had been public for a while).

Let me introduce a few terms. A “vulnerability” is a flaw in a system (either a bug or a design error) that allows something to breach security. A “patched vulnerability” is a vulnerability that has been fixed by the supplier and the fixed version is available to users. An “unpatched vulnerability” is one for which there is no fix from the vendor yet. This distinction is important because research shows that when computers are compromised through these sorts of vulnerabilities, the large majority of them are through patched vulnerabilities. That is, if the user had kept their software up to date, they would not have become a victim.

Some people use these terms a bit differently. You will sometimes hear “zero day” to refer to what I am calling an unpatched vulnerability. But I reserve that term to refer to vulnerabilities that the software provider isn’t even aware of.

Flashback did not exploit a vulnerability that Apple didn’t know about. The particular bug in Java had been done for months before Flashback started to exploit it. Instead, Flashback exploited a vulnerability that Apple was well aware of, but had not yet fixed. Flashback, then, is an exception to my claim that keeping your software up to date will keep your computer malware free. I’ll come back to this in the third article in the series.

So if Flashback actually goes against my point, why do I insist that keeping systems and software up-to-date is the most important thing you can do to prevent infection? I’m basing my claim on a great deal of research on this question, but I will draw most of my examples from Microsoft Security Intelligence Report volume 11 (PDF). It contains the clearest arguments and data.

The Microsoft report offers the example of the number of new infected Windows systems through a particular vulnerability in Adobe’s Flash Player and Adobe Reader. The red part of the graph covers the time between when the malware was exploiting the vulnerability and the time that Adobe first issued a fix for it. As you see, there is a decline in infection rates shortly after Adobe issued updates for Flash on April 15, 2011 and for Reader on April 21 a week later.

But as you look at what happened two months after Adobe fixed the vulnerability (the green part of the graph), there is an enormous resurgence of the malware. The number of systems infected before Adobe fixed the vulnerability is tiny compared the infections that happened much later. This particular example illustrates the general pattern. Most system compromises through vulnerabilities could have easily been avoided if people kept their software up to date.

That particular infection is just one example to illustrate what is a very common infection pattern. Indeed, what may be the most widely spread malware on Windows—Conficker—is still infecting Windows systems more than five years after the vulnerabilities that it exploits have been fixed by Microsoft. Keep in mind that, once it gets onto a corporate network in the first place, much of Conficker’s ability to spread is to just find users on the network with weak passwords. Still, it does help illustrate the problem of people not keeping their software up to date, as the password guessing tactic only works after Conficker makes it onto the local network by some other means.

How to keep things up to date

On the Mac, Leopard and Tiger are no longer being updated. If you are using one of those systems, please move to Snow Leopard or Lion quickly. And if history is much of a guide, Snow Leopard will lose support within a few months after the release of Mountain Lion, which Apple has scheduled for summer 2012. As of this week, Mozilla has discontinued support for Firefox 3.6. In short: don’t use unsupported operating systems or web browsers. Just don’t.

On Windows, Microsoft still provides security updates for Windows XP (Server Pack 2), but they do so only reluctantly. They had wanted to end support in 2010, but are now continuing it through April 2014. If you are using Windows XP, you shouldn’t wait until 2014. The security changes between XP (released over a decade ago) and Vista are enormous, not to mention Windows 7 came out in 2009, and Windows 8 is almost upon us.

The operating systems are probably the easiest thing to keep up to date because they are typically configured to periodically check for available updates. But the software you install later can, traditionally, come from many different places, so it is usually harder to maintain. An increasing amount of software will automatically update itself, though, and Google Chrome is one notable example, with more browsers following suit. Some software will periodically check whether it needs to be updated and alert you, but new software delivery services like Apple’s App Store and Microsoft’s upcoming Windows Store can do all that heavy lifting for you.

For your most important software, it is vital to have some sort of easy or automatic way of checking for and install updates. In terms of security, here is an ordered list of what I think are the most important things to keep up to date:

Web browsers. In each web browser, you will be able to configure its updating habits in its preferences.

Web browser plug-ins. These are the programs – such as Adobe Flash Player, Adobe Reader (on Windows), Java, and Silverlight – that are used to open certain kinds “in the browser” that the browser itself can’t handle natively.

Email software. If you are using the email software that comes with your operating system (Mail.app or Outlook), then they will be updated with the operating system. But if you use a third party mail program, then you need to make sure that that is kept up to date.

Anything that opens files that you did not create yourself. Whatever software you use to look at pictures, read word processor documents, work with spreadsheets, or listen to music files must be kept up to date.

1Password. Well, really any software that has to do with your security. 1Password automatically checks for updates after it is launched and will only check periodically in case you are like me and never relaunch it because you never close it. You can configure 1Password’s updating behavior in Preferences > Updates. You should also keep the 1Password browser extensions up to date, which is typically done automatically right within the browser.

That’s a lot of work to keep up with, but fortunately an increasing number of application developers are making updates easier and automatic. Tools like the Mac App Store make it even easier for people to see what needs to be updated. There will be some more discussion of that in Part 3.

2. Back up your data

Backing up your data won’t actually do anything to prevent infection, but it will put you in a much better position to recover from one. Most malware tries to remain undetected so it won’t deliberately crash or destroy your system, but it can still introduce instabilities. Furthermore, there is a form of malware, known as ransomware, which encrypts your data and requires that you pay to get the decryption key.

3. Pay attention to where your software comes from.

Even if the software and operating system you are using has no technical vulnerabilities that allow an attacker to get malicious software running on your computer, there is still a very simple way that they can get their software installed and running. They can ask you to install and launch it for them.

Of course they don’t say, “Hey, here is some malicious software. Please download, install, and run it.” Instead, they say, “Hey, here’s a free horse riding game! No strings attached!” You can download and install it. Perhaps you enter your administrator password during the installation process. The download may even include a more or less working copy of the horse software.

Lurking inside the harmless game you brought in through your defenses could be enemies. They break out at night, kill your guards, and open the gates so their whole army can rush in.

The horse, standing high on the ramparts, pours out warriors,
and Sinon the conqueror exultantly stirs the flames.
Others are at the wide-open gates, as many thousands
as ever came from great Mycenae: more have blocked
the narrow streets with hostile weapons:
a line of standing steel with naked flickering blades
is ready for the slaughter

It should not come as a surprise that malware of this sort is called a “Trojan horse,” or just “Trojan.”

I am not for a moment suggesting that you shun all geeks bearing gifts. After all, making great things for people is what we geeks love to do. But along with not keeping software up to date, this a leading way that malicious software can be installed and run on your system.

This is one of the reasons why I’m excited by Gatekeeper, coming in OS X 10.8 Mountain Lion. It won’t be an entire solution to the problem of Trojans, but it may play a substantial part. In short, Gatekeeper will give you control over what apps run on your computer depending on who or where they come from.

4. Virus Scanning?

I’ve left anti-virus scanning for last on my list because I think it plays a distant third to keeping software and systems up to date and paying attention to where you get your software from. As one security researcher quipped, “anti-virus vendors have solved the malware problem so well on Windows that they are now bringing the same magic to the Mac.” On the other hand, it is useful to occasionally (or even regularly) run a scan of files on the system.

There are two ways that anti-virus software can operate. In one mode, they will search through most of the files on your system looking for malware, either periodically or at a time you specify. In the more active mode, they inspect (almost) every file as it gets opened, but this mode can often slow down a system substantially or even make it less stable. (“Less stable” is a euphemism for crashing more.) Opinions about these vary widely (and heatedly). In both modes, the database that the anti-virus software uses needs to be kept very much up-to-date.

One thing to keep in mind is that, although Mac users should probably be more concerned about malware than they are used to (more on that below), they should be wary of reacting to the most alarming headlines, particularly when they are produced by by anti-virus vendors. While some vendors have kept a level head in their discussions, others have engaged in egregious fear mongering based on extremely misleading numbers. It is unfortunate that the least useful information with the most alarming headline is the one that gets the attention.

In any case, with Flashback, everyone should run one of the many free detection and removal tools that have been issued by reputable anti-virus vendors. One of the first was developed by Intego. Even if you have updated your software to fix the vulnerability that Flashback has been exploiting, once your computer is infected it will remain infected until the malware is explicitly removed.

Other tips?

There are load of other things you can do to improve system security. For example, I am a big advocate of not having your main user account be an administrator account. More steps to consider include adjusting firewall settings and using various blockers in web browsers. But the large majority of problems will be avoided simply by keeping software up to date and paying attention to where you get software from. We get diminishing gains in security from the more advanced techniques, particularly in comparison to the gains we get from the basic things that everyone should do.

In Part 3 of this series, I will offer some thoughts on the developing malware situation on the Mac, with a look at what might keep Macs relatively safe or not.

Over the last couple weeks, a topic in tech news has been Flashback, malware that seems to have gotten itself installed on (at least) about 600,000 Macs running OS X. Although there has been malware for Mac OS X for a long while, Flashback is the first to reportedly affect a substantial number of users. In at least one respect, it does represent an important change in the kinds of security threats facing Mac users.

This article is the first installment of a three-part series about the state of Mac malware and what all this means to you as a Mac and 1Password user. In today’s first part, I’ll discuss what kind of threat malware like Flashback does or does not pose to your password data. Part 2 will talk about malware more generally, with concrete tips about keeping yourself safe. Part 3 will talk about changes in threat landscape, and provide some ways of understanding the differences and similarities between the threats that Mac and Windows users face.

First things first

If you haven’t tested whether your system has been infected with Flashback, you should. By installing the latest security updates to Lion and Snow Leopard, you will get Apple’s Flashback removal tool. Just use Software Update on your Mac. I write more about keeping your system up to date in Part 2 of this series.

Apple, to say the least, has not been the most fleet of foot in addressing the threat, so you may be tempted to look elsewhere for detection and remove tools. Every anti-virus vendor offers free (or free trial) tools that will detect and remove Flashback. I’ll talk a bit more about anti-virus software in Part 2, but for now let me just point out that they have an incentive in scaring people and publishing hyperbolic claims. I haven’t (and won’t) evaluate the various products they have to offer, but personally I would be more trusting of those companies who provide useful, level headed information over those that try to scare you.

The quick answer

We do not see the Flashback infection as a significant threat to your 1Password data. But the single best thing you can do to protect your 1Password data if your machine is infected in any way is to have a good Master Password.

The encryption on your 1Password data has been designed from the outset to withstand concerted attack if it gets captured. Whether it is captured through your computer being stolen, a compromise of a syncing service, or through a compromise of your computer through malware, it can’t be decrypted without your Master Password.

The second thing about 1Password’s design is that it only decrypts the smallest amount of information needed at any one time. Even when your 1Password data is unlocked, all of the information is encrypted except for the particular item you are dealing with at the time. This means that there are no decrypted temporary files. This is an important – and often overlooked – security feature. 1Password never decrypted usernames and passwords while just sitting around.

Of course, when it comes to security questions, there really are no quick answers. So the rest of this article goes into more detail.

Theory and Practice

It’s a wonderful day when I can meaningfully quote Yogi Berra:

In theory there is no difference between theory and practice. In practice, there is.

In principle, once your computer is compromised it is no longer “your” computer. In some juvenile jargon your system is owned. In theory, if malicious software is running (with sufficient privileges) on your computer, then everything you do and see belongs to the attacker. This could, in principle, involve modifying all of the software (including the Operating System) that you use. So in theory, once your computer is taken over, there is pretty much nothing that can protect you. Fortunately, practice is much different than theory.

In practice, malware tries to remain small. It makes only the minimal changes to your system that are required for its specific job, and most of those changes are attempts to cover its tracks. Because we know the kinds of things that malware–in practice–does, we have been able to design 1Password to protect your data against those sorts of attacks.

Flashback, for the most part, opens a back door that allows its operator to install or modify things on the infected computers later. That is, computers that are infected become part of what is called a botnet. These are often used to relay or to launch certain attacks on more high-value targets. By using machines in a botnet, the attackers can cover their tracks and leverage huge numbers of machines to make their attacks more powerful.

Because machines in a botnet are awaiting commands from those who control the botnet, it is hard to answer the question “what does Flashback do?” Symantec has just published a fascinating analysis of how Flashback has made money for its operators. It inserts itself into web browsers to hijack certain advertisements and clicks, so ad revenue that would otherwise go to Google goes to the operators of Flashback.

Even with our better understanding of what the Flashback operators were after, we still have to ask what the operators of a botnet could, in practice, do with an infected computer. Here I will focus on two things that malware can do that pose a risk to password data, even if this isn’t primarily what Flashback was after. One thing is that malware can install software that would scan your computer for lists of passwords. The other point of concern is that is can install malicious software into browsers that try to capture passwords as you use them.

Hunting for lists of passwords

One thing that can be installed through the backdoor is a system that searches your computer for lists of passwords. There is a history of this in Windows malware, so we should assume that those who have a back door into your computer have the same capabilities and interests.
The good news for 1Password users is that such malware goes after “home-grown” password management systems. They are not at all prepared for a well-designed system like 1Password.

Many people, faced with the problem of remembering lots of passwords, develop their own password management system. Often people will simply list their passwords in a word processor document, such as Microsoft Word, or in a spread-sheet. It is those files that this sort of malware goes after. Even when people encrypt those files, the password that they use to encrypt that data is often not protected by measures to resist automatic password cracking tools. Furthermore, when people decrypt those files to work with them, often temporary files are created with the data decrypted. Password collecting malware goes after those too.

1Password’s design resists those sorts of attacks. We use PBKDF2 to make it much much harder for an attacker to run a program that tries to guess your Master Password. We’ve also been beefing up this defense to keep ahead of developing threats.

We are also very careful to only decrypt small amounts of data at a time instead of decrypting everything. This means that (with the exception of file attachments) decrypted data is never written to disk. This means that there are no temporary or cache files that could be picked up by an attacker on your system. These are some of the behind-the-scenes considerations that go into 1Password, but are rarely considered in home-grown systems, which makes them such ripe target for malware.

Target of the DevilRobber

Poorly designed, home-grown, systems are the typical targets of malware data collection, but does that mean no malware would ever include 1Password data among its targets? Not at all. Indeed, I wrote about a case like that last November involving DevilRobber, another piece of malware. DevilRobber didn’t get much attention because it didn’t get very far, but it did collect a great deal of information from the few machines that were infected.

Whoever collected that data would still need to guess someone’s 1Password Master Password to get encrypted information out of the file. But once we learned that people were actively going after 1Password data files, we made some changes with some more to come.

Password collection in Safari

Some versions of Flashback are reported to have added things into Safari to capture password you might enter for sites in the browser. If your browser had been infected this way, then passwords that you typed or pasted into web pages are likely to have been captured. This does not include your 1Password Master Password.

Passwords that were filled by 1Password (not pasted or manually typed) are unlikely to have been captured, but I can’t be absolutely certain of that. Although it may seem that 1Password is just pasting in or typing in your usernames and passwords for you, that’s not what is really going on. 1Password’s form filling mechanism works much closer to the bone, thus reducing the chances that something could intercept the data that 1Password fills in.

Still, because you may have pasted passwords instead of having 1Password fill everything, if your system has been infected, you should use Apple’s aforementioned Flashback removal tool and change some of your passwords. Start with your more important and frequently used ones. Passwords for email services are the first thing that attackers like to go after. After that, it’s banking and popular on-line retailers.

Even if your system was infected, there are a lot of unknowns that all act in your favor: whether you had a Flashback variant that monkeyed with Safari; whether passwords were entered in a way that the malicious software could capture; whether the people gathering that data have the resources to exploit it. One of the biggest unknowns is that many infected Macs have not been able to communicate with the command centers—the systems on the network that are set up to give instructions to infected Macs or collect data from them. Network operators and security companies substantially disrupted communication with the command centers.

Complacency or panic

Frightened people make poor security decisions, just as people who are overly complacent do. Flashback poses a non-negligible threat to your 1Password data, but “non-negligible” doesn’t mean “large”. It doesn’t even mean “significant” in this case, but it does mean that we shouldn’t ignore it. So let me repeat the advice I gave above that if your machine was, in fact, infected with Flashback, after you get it removed and your system up to date, do change your most important and frequently used passwords.