Just in Time Decryption

1Password for iOS icon supersized1Password only decrypts what you need at the time you need it. If Molly (one of my dogs) is using 1Password to log in to, only her SquirrelsAreEvil Login details are decrypted. Her RabbitRecipies Login, along with all her other hundreds of items, remain encrypted.

I’d like to explain why this is such an important security feature, as well as why it’s vital for Molly’s security tool to lock her 1Password data when she steps away from her computer. Limiting what is decrypted, and for how long, provides some concrete benefits, though it also raises some interesting questions. Read on to see what I mean.

Keeping secrets small

It is easier to keep sixteen bytes of data secret than it is to keep sixteen megabytes of data secret. Quite simply, it is much harder to handle and manage sixteen megabytes of data in a secure way than it is to keep just sixteen bytes secret. This is true for both people and for computer systems. You can manage your 1Password Master Password securely (in your head), but you could not do the same with all of your passwords and logins. After all, that’s why you use 1Password in the first place.

1Password enables you to turn a large secret—all of your various login information for services, secure notes, WiFi passwords, bank account details, credit cards, etc.—into a small one that you can manage—your 1Password Master Password. This is what I mean when I say that encryption allows you to turn big secrets into small ones.

Just as it is hard for a human brain to handle large secrets securely, it can also be difficult for computers. When computers are running short of working memory, they might have to make temporary notes of what is “in their heads” (writing to swap files). If a program crashes, it might write to disk some of what is in its memory (core dumps), and there are various other ways that a computer or computer program can accidentally mishandle secrets.


There are tools that systems and programmers can use to make it harder to accidentally reveal secrets, but these methods work best for little secrets. So it would be much better for a computer to only have to manage one little secret. Like you, the computer can be good at managing such secrets. Of course, a little secret (one that fits in sixteen or thirty-two bytes of data, for example) can be very very important. Note that, when I talk about “big” or “little” secrets here, I only mean the size of the data.

The way to turn big secrets into little secrets on a computer is to encrypt the big secrets with an encryption key. After that, the encryption key (or the password from which the key is derived) becomes the secret. The encrypted data, because it is encrypted, does not need to be kept secret. With the encrypted data and the key, there is no need to keep the unencrypted secret data around.

Throwing away the key

When you lock 1Password or it locks through auto-locking, 1Password throws away the key (the details are a bit more complicated as there are multiple keys and these are handled slightly differently in different versions and platforms. But let’s stick with this for now). Without the key, the encrypted data cannot be decrypted, nor is there any way to steal the key since it’s been destroyed.

The only way to decrypt data once the key has been destroyed is to make a new key, and making a new key requires your Master Password. Making keys from your Master Password is called “key derivation”. It is a subtle, but crucial, part of the design of any cryptographic system. For those interested, you may read the gory details of key derivation in 1Password 4.

When to throw away the key

When I’m working, I often get up and pace around the room. Too often I pace all the way to the refrigerator and grab a snack. This is not great for my health, but it also means that someone might walk over to my computer and take a look at the passwords I have stored in 1Password. If my computer account is accessible and if 1Password has the key, then an attacker can get at my data.


If I worked in a crowded office with people coming and going, that would be something I should be concerned about. In such a case, I would go to 1Password > Preferences > Security and set Auto-Lock to lock after only a few minutes of computer inactivity. I would also set these preferences to lock when the screensaver is activated or when the computer goes to sleep. This would mean that I might have to type my Master Password a few more times a day, but it will help immensely with keeping my secrets, well, secrets. Plus, typing my Master Password a few more times each day will help ensure that I never forget it.

Is Auto-Lock helpful?

An argument can be made that even the most aggressive auto-lock settings provide no meaningful security. I think that Auto-Lock is important, but let me first outline the argument against it.

Suppose Molly (one of my dogs) is working at her computer and runs off to chase a rabbit. She has set up auto-lock so that 1Password will be lock quickly. Molly knows that Patty (the other dog) is trying to find out where the bones are buried, a secret Molly keeps in a Secure Note in 1Password. When Molly is off chasing a rabbit, Patty goes up to Molly’s computer and sees that 1Password is locked. Patty cannot find out where the bones are buried.

But Patty came prepared. Patty doesn’t care that 1Password is locked because Patty replaces the copy of 1Password on Molly’s computer with a bogus copy of 1Password. After all, Patty has as much access to Molly’s computer as Molly would have, and that typically involves being able to install software. When Molly returns (without a rabbit) she sees what appears to be 1Password, nice and securely locked. She types in her Master Password, but the imposter version of 1Password sends that Master Password to Patty.

So the question remains, what good does locking 1Password do?

Auto-Lock *is* helpful

Even though it is possible for Patty to defeat Auto-Lock’s security, it is, in practice, much harder for her to do so than to simply read the data she wants when 1Password is unlocked. Even if Patty had a good imposter of 1Password at hand, and even if she could install it quickly and easily, she runs a much higher risk of getting caught because she has made large changes to Molly’s system.

There may also be barriers to installing an imposter 1Password on Molly’s machine (or otherwise changing the security system of the machine). An administrator password may be required for a normal software install. Something like Gatekeeper may detect that new software is running and ask for an administrator password. It is true that all of these can be worked around if Patty has enough time at Molly’s computer, but these all make it ever more difficult in practice for Patty to tamper with Molly’s computer in a way that will work, can be done quickly, and won’t be detected.

Raising the attack bar

We can never (well, … hardly ever) protect a computer against someone who has unsupervised physical access to it. It can be tampered with down to the boot loader. Suppose Molly is using full disk encryption (FDE) with Filevault 2 on the Mac, and she shuts down her computer completely. Patty might disguise herself as a maid (she is evil that way) and when cleaning Molly’s dog house physically replace the boot ROM on Molly’s computer. Patty can then ensure that the next time the machine boots up, it captures a copy of the disk encryption password and also installs whatever changes to the operating system and software that Patty wants.

In principle, there is little we can do practically to defend against such attacks. But it is far harder to execute an evil maid attack than to simply look at someone’s unlocked passwords. By locking 1Password, Molly makes Patty have to work that much harder (and increase her risk of getting caught) than if Molly didn’t lock 1Password.

Requiring a login password from the screensaver further increases the difficulty (and thus reduces the plausibility) of a successful attack. Using Full Disk Encryption raises the attack bar even higher.

These are cases where the good guys actually have the advantage. There are simple and relatively costless things we can do that very substantially raise the cost to the attacker.

Defending against practical attacks

We have to look not only at theoretical attacks, but the practical arsenal of attackers. We build defenses to increase the amount of work an attacker has to do. If the amount of work the an attacker has to do is beyond what that particular attacker can (or is willing to do), then we have successfully defended against that attack.

Auto-Lock features, like 1Password’s, can successfully defend against what might otherwise be common attacks. It may not defend you against a specially trained spy who has lots of time with your computer, but it will defend you against the nosy officemate who takes the opportunity to grab what she or he may when you briefly leave the room. The world has many more nosey officemates than trained spies.


We keep as little of your 1Password data decrypted as possible, and only for the shortest amount of time, because it is far easier to manage small secrets securely than large secrets. Features like Auto-Lock can’t always defend against everyone who gets access to your computer, but they do make the job of the attacker substantially more difficult. Indeed, it makes the difficulty of an attack prohibitive for the kinds of attackers we most often find for this category of threat.

Understanding Sharing

1Password 4.2 for iOS has been released with a really nifty sharing feature. This allows you to conveniently share items with other people and keep them updated. Before getting into the details, it is important to know that the data is well encrypted within 1Password, but it is not encrypted when it is not in 1Password. In other words: share over secure channels and be sure you can trust your recipients. More on that later.

The overview

share-transparentIn 1Password 4.2 for iOS you can share an item (a Login, a Credit Card, or anything else in 1Password) by tapping on the share icon. You can then share the item by Mail or by Message. The recipient will just have to tap on the link in the message or email to easily import or update the item into their own 1Password keychain. It’s remarkably easy and convenient. It’s great for families, whose members need to share certain Logins and other 1Password items.

Just be sure to share with care. When you send one of these messages, anyone with copy of 1Password can import the item into their own library. So you will need to find a “secure channel” that is sufficiently secure for your needs. More on this, and so many other things, in the somewhat roundabout article below.

Even dogs can learn to share

Login for NewBarkTimes

Patty (one of my dogs) and Molly (the other) have a subscription to the New Bark Times.Patty set up the account and put the Login Password into 1Password. She uses it when she wants to read up on the latest techniques of how to steal the human food without getting caught. Molly – as a member of the same household – is also entitled to read the online edition. She likes to sniff the comics, which are mostly just depictions of dead squirrels. They are funny because the squirrels are dead.

Ways of sharing

So how do Molly and Patty share the Login information for the New Bark Times? I’m going to run through some sharing options, starting with the most cumbersome and finishing with the most convenient.  You can jump ahead to the section on using the new feature in 1Password 4.2 for iOS, but it is easier to understand what is going on and find what works for you if you follow along.

(Pass)word of mouth

Patty can simply tell Molly the password, and Molly can use that information to create an entry into 1Password. Note that Patty telling Molly the password and account details while they are both hiding under the bed constitutes “sharing over a secure channel”. They do so where Mr Talk (my neighbor’s cat) can’t listen in.

The advantage of this method is that it is the most secure. It is easier to arrange a secure channel for whispering something into someone’s ear than for transferring a data file with sensitive information. At least it’s easier for members of the same pack or household.

Any time Patty updates the information, she’ll have to tell Molly, who in turn, will have to edit her data. Likewise if Molly makes changes, Patty will have to manually (“pawually”?) edit her own 1Password data.   Wouldn’t it be nice to avoid all of those manual edits?

1PIF, two PIF

Before they got their paws on 1Password 4.2, Molly and Patty had worked out another way to share the New Bark Times Login. They didn’t like all of the manual editing, so they managed to share the Login by exporting and importing a 1PIF (“1Password Interchange File”) file with that Login. 1PIF files can be imported and exported to and from 1Password on Mac and Windows.

Patty would select the item and  use  File > Export Selected …  >  1Password Interchange File from the menubar. All Molly needs to do is import that 1PIF into her 1Password data, and not worry about manual editing.

1PIF files are not encrypted, so Patty and Molly need to use a secure channel to exchange them if they don’t want Mr Talk getting that data. They might use some file sharing over their local network, and they should remember to securely erase the 1PIF after it is done.

Sharing updates: Unique in all the world

There is another nice features about using 1PIFs this way. Every item created by 1Password has a Universally Unique Identifier (UUID). If Patty and Molly each create their own separate Logins for the New Bark Times, they will have different UUIDs even if their content is identical. But if Patty creates the item and exports it as a 1PIF for Molly to import, they will end up having the same UUID.

Here is where the magic comes in. If you import an item with a UUID of something that already exists in your data, 1Password updates the existing item instead of just creating a new one in your keychain (I’ll save the explanation for how we make sure that the UUIDs really are unique as a birthday present). If Molly modifies the New Bark Times Login, she can export it it for Patty to import, which will update the item in Patty’s keychain.

1Password 4 makes sharing even more convenient

Exporting and importing 1PIFs is fine as far as it goes for 1Password 3 for Mac and 1Password for Windows, but until now, 1Password for iOS didn’t have an import or export mechanism.

1Password 4.2 for iOS gained just such a sharing system, and it is extremely convenient.

Sharing a Login by MessageWhen Patty looks at the Login item in 1Password for iOS, she can tap the Share icon, then select “Message” or “Mail”. After that she should select “Message Login” or “Mail Login”.  These options share the 1Password item in a form that isn’t fit for humans (or dogs) to read. Instead, it uses an obfuscated format that your recipient can easily import into 1Password.

But note again, even though it isn’t designed for humans to read, its contents are still exposed to anyone, including the nefarious Mr Talk, who has access to 1Password. This is another reminder that Patty and Molly need to find a secure channel for sharing 1Password items.

The alternative Mail and Message format, “Mail/Message Clear Text”, puts the Login’s details in a human readable format. And it’s not just Logins that can be mailed or messaged. You can Mail Software Licenses, Message Credit Cards. Almost everything in 1Password can be shared this way; attachments are the only thing that don’t make the trip.

NewBarkTimes-import2When Molly receives the email or the message, all she needs to do is tap on the included link. At right, you can see what this looks like if the Login was sent by Mail.

The import will add a new item if the received item has a UUID that isn’t already in the recipient’s keychain. All Molly needs to do is approve the import of the new Login.NewBarkTimes-import1

Sometime later, Patty may update the item. She might add in a Note to the Login with the answer to a security question (Q: “Favorite pet”, A: “Me”).  Though of course, Patty should know not to give predictable answers to security questions, either.


After Patty has made some changes, she can just send the item to Molly again.

This time, 1Password will see that an item with the same UUID already exists in Molly’s data, so it will prompt Molly to see if she wants to update the item. Molly, of course, can also make changes and send the updated item to Patty.

This makes it really easy for Patty and Molly to share these items between their iOS devices via iMessage, which can provide a sufficiently secure channel for most purposes.

Finding a secure channel

As with 1Password’s other sharing methods (including word of mouth), Patty and Molly need to make sure that they have a secure channel. That is, they need to know that the message is going to the right person (don’t accidentally send it to Mr Talk); they need to know that it is coming from the right person; they need to know that nobody can listen in on the channel; and they need to know that nobody can tamper with the channel.

iMessage probably provides a secure enough channel for most people for most cases, though it may not be sufficient if you are trying to keep secrets from Apple or from law enforcement agencies. Even if you don’t anticipate attacks from those sources, there are a few cautions:

  1. It’s not always clear when a message will be sent by iMessage or via the much less secure SMS. Unfortunately, we haven’t (yet) found a way to make it clear from within 1Password when a message is going out over iMessage or not.
  2. It is often a bit too easy to accidentally send a message to the wrong recipient. So please take care that you really are sending it to the correct address.
  3. After a message or email has been sent and received, you should look at ways to delete the messages. For email, this is particularly difficult to do thoroughly, as most email servers create backups.

Molly and Patty might be willing to use one channel for sending their New Bark Times Login that they wouldn’t be willing to use for sending their First Bank of Canis Major Login. These are choices that only Patty and Molly can make for themselves.

Doing the two-step until the end of time

Enigma machineIn my discussion of Dropbox’s new two-step authentication, I skimped on the cryptography. Because we had to move quickly, I wanted to focus at the time just on our recommendations, so I told a few fibs about how the way the six digit codes “get” to your phone. Now I want to explain how it really works.

Not only that, but I will sneak in a little introduction to Message Authentication Codes (MAC), which plays a major role in our newest version of the 1Password data format. This topic is also worth revisiting because our new release, 1Password4 for iOS, works well with Dropbox’s two-step verification.

Speaking of, let’s start with Dropbox’s two-step authentication system. I did try to warn readers that I was being less than forthcoming about the full truth when I suggested that a six digit code is sent from Dropbox (or Google) to your phone:

There are also some really cool things about how the protocols for two-factor authentication work, but I will bite my tongue and leave that discussion for another day. What this means, however, is that a great deal of what I say in describing the system below is a pack of lies.

Even my word “protocol” could be confusing, as it might imply some network activity. The magic of the system is that anything using this type of Time-based One Time Password (TOTP) tool will compute the same six digit code at a particular time with the initial set-up secret. Dropbox’s login system will calculate the six digit code on its own; and a tool that you use, such as Google Authenticator, will also calculate the six digit code on its own. No network connection is needed after the first time setup.  In my example below, I’ll use Google Authenticator, but it isn’t the only TOTP tool out there.

Initial set up

When you first set up something like the Google Authenticator you scan in a QR code. It might look something like this:Sample QR code for setting up authenticator

The code contains a label that will typically be “”, and it contains a secret that is randomly generated and unique for each account. The secret might look like “MQZDKZRZGBRWMMZXMI4TCMZUMYYDKYTC”. Putting this inside of a QR code just saves you a lot of typing. If you don’t have a camera that can be used to scan the code, there is even a link for getting the information that you should type in. Scanning this in is the only time that information will be transmitted (in this case, transmitted via your phone’s camera) from Dropbox to Google Authenticator.

Google Authenticator on your phone will keep a copy of the secret, and so will the Dropbox servers. That shared secret allows both Google Authenticator and Dropbox to calculate the same six digit codes when needed.

Counting on time

When you log into Dropbox with your username and password you will then be prompted for the six digit code if you have enabled two-step verification. You will then open Google Authenticator on your phone and you will see six digits. Those six digits are computed from a combination of the the shared secret and the current time. The current time is the number of seconds since the first instant of 1970. It is rounded down to the nearest half minute. This is why the number changes every thirty seconds.

Dropbox website prompting for security codeWhen you enter the six digit code during Dropbox’s login process, Dropbox will perform the same calculation. It has a copy of the secret that was first shared, and it too knows the current time. If what you enter matches what it has calculated, you’re in.

Your phone will not need any network connection as long as its clock is reasonably accurate. Fun fact: your phone actually makes minor adjustments to its clock pretty much every time it connects to any kind of network that allows it to check a time server on the internet. Today, most networked computers and devices know the current time to within less than one 10th of a second.

Because the code depends on both the time and on the shared secret, we end up with a different code during each 30 second period. This makes it a one time password.

Beyond the end of the world (January 19, 2038)

Ancient eunuchs foretold global catastrophe on January 19, 2038, as their long count calendar comes to an end and starts a new cycle from zero


Aztec sun stone (replica)

Replica of the Aztec sun stone. This has nothing to to with Unix or Mayan time keeping.

The number of seconds since the very beginning of 1970, known as Unix time, is often maintained in a single variable in the computer’s operating system. When Unix was first designed, this number was stored in 32 bit variable. That means that the number could range from 0 to 232. Zero corresponds to the midnight January 1, 1970 (UTC). So what time does 232 correspond to? That will be 3:14:07 (UTC) on January 19, 2038. Bad things will happen then to computers that still are still using 32 bit integers to store Unix time.

So will Google Authenticator stop working in 2038? No, it should be fine. Even though iOS devices – based on 32-bit ARM chips – do just use 32 bit “long” integers, Google Authentication doesn’t rely on that. It uses NSDate to get Unix time on iOS.

Indeed, the actual standard defining TOTP states:

The implementation of this algorithm MUST support a time value T larger than a 32-bit integer when it is beyond the year 2038.

Another wrinkle in time

Unix Time really is the number of seconds since the very beginning of 1970, but that number ignores leap seconds. Twisted clockLeap seconds are added (or subtracted) on occasion to account for the fact that the speed of the Earth’s rotation can change slightly due to earthquakes, other seismic activity, and even tidal activity (not only do I get to talk about a calendar system reaching its end and resetting, I get to talk about earthquakes and tidal waves in the same post!). A leap second was added at the end of June 2012, so noon (leap second adjusted) on July 1 was actually only 86399 seconds later (by Unix time) than June 30 instead of 86400 seconds later as you would normally get between two days.

The TOTP standard requires the use of Unix time, which is defined to ignore leap seconds. This way, everyone who follows the standard will be using the same clock and calendar. Also, keep in mind that Unix time isn’t just for Unix-based operating system like OS X, iOS, and Android. Windows has a similarly defined FILETIME, which differs in its start time and that it counts in nanoseconds instead of seconds, but it can be converted to Unix time easily enough for use in the TOTP protocol.

Time to meet MAC

Earlier, I said that the code, or one time password, is computed from the secret key and the time, but not just any old computation will do. For the system to work securely, we need the computation to meet some requirements which include:

  1. It must be easy to calculate the code from the key and the time, but it must be completely unfeasible to calculate the key from the code and the time.
  2. It must be unfeasible to predict without knowledge of the key what the code will be at some particular time even if you have observed what the code is at many other times.
  3. The calculation will always give the same result if given the same key and time (it is a function).

These look similar to some of the requirements we wanted for a good cryptographic hash function. And a cryptographic hash function will play a central role in how this is all done.

This also looks as if we are using a shared secret key to create a digital signature on the time. Digital signatures also involve hash functions. But “digital signature” isn’t really the right term here because those are based off of public/private key systems. With TOTP, we have a shared secret.

In place of a digital signature, we have a Message Authentication Code (MAC). This is not to be confused with “MAC” of “MAC address” that you see as hardware addresses for networking equipment, and certainly not to be confused with “Mac” (Apple’s family of computers) or “mac” (the mackintosh raincoat). Maybe this will help keep things clear:

A lowercase mac, for when you need wet wear
And an all-caps MAC is made by software
You’d be just as cool as the great Ry Cooder
If  you never confound these with a Mac computer

One of the ways to use a cryptographic hash to create a MAC is the HMAC. You will hear more about HMAC in the not-so-distant future.

Keeping time, time, time

One consequence of this sort of system is that it makes the computers’ knowledge of the time part of the security system. This isn’t anything new; this requirement has been part of the Kerberos system for decades. Indeed, one of my first roles in system administration was keeping clocks in sync with each other, specifically for Kerberos.


Unfortunately, this means that if someone can tamper with the time signals a computer receives from outside, then they can do damage to other aspects of security. We need systems to verify that the messages they get about the time are authentic, but the less-than-ideal state of secure time synchronization could be the subject for a new series of rant posts. Fortunately, I’ll spare you.

It is also not clear at this point what forms of time travel this or other security protocols can resist. I believe that there is a research paper in this question somewhere for an adventurous student and a flexible professor.

Six digits from 160 bits

Let’s now put all of these pieces together. Dropbox and Google Authenticator each have the shared secret from when you set up your two-step verification. And each know the correct time at the moment. So when each calculate the HMAC of the current time, using the shared secret as a key, they will calculate the same number. If they use SHA-1 for the hash function (as they do in the current system) the number that they calculate will 160 bits long, or roughly 48 digits. The final step is to compute a 6 digit number from that 160 bit number. But let’s save time and skip those final details.

Time for closing remarks

Dropbox’s two-step authentication is a great thing, and 1Password for iOS now works more smoothly with it. But it does the most good for people who are using weak or re-used passwords to log into Dropbox. Thankfully, 1Password users don’t really need to worry about that problem.

Hashing fast and slow: GPUs and 1Password

The net is atwitter with discussion of Jeremi Gosney’s specially crafted machine with 25 GPUs that can test hundreds of billions of passwords per second using hashcat, a password cracking system. Password crackers, like hashcat, look at the cryptographic hashes of user passwords and repeatedly make guesses to try to find a password that works. 1Password has been designed to resist automated password cracking attempts exactly because we anticipated developments like this.

Don’t get freaked out by the numbers

Windows XPFirst and foremost the reports of 348 billion passwords per second is specifically about passwords stored in the LM format used on Windows XP, exploiting the notorious design flaws and limitations LM hashes. (If you are still running Windows XP; and particularly if you are running NT, 2000 or 2003 domain controllers, please, please upgrade.) The hundreds of billions of  passwords per second reached against those hashes does not mean that passwords stored in other formats can be cracked that quickly.

By the way, this isn’t the only important news about password security to come out this year’s excellent Passwords12 conference. I couldn’t quite make it there this year, but I will talk about other developments from it in coming weeks. Today, all eyes are on GPUs guessing billions of passwords per second.

Slow and Fast Hashing

Typically when a password is “stored” on a system that you log into it is not the password itself, but instead it is a cryptographic hash of the password. I’ve written about some of the ways that password  can be hashed before. HashcatThese can roughly be divided into two categories: slow hashes and fast hashes. Slow hashes are specifically designed to slow down the kinds of attacks we are discussing.

Your 1Password Master Password is processed using the slow hashing system known as PBKDF2. 1Password’s use of PBKDF2 and your use of a good Master Password keep your data resistant from password crackers such as John the Ripper and hashcat if you chose a good Master Password.

Defending against future threats

There are several lessons from this. Gosney’s work does reflect real innovation and a breakthrough, but it isn’t an unexpected breakthrough. People who keep an eye on these things – and we do keep an eye on these things – expected something like this within the next couple of years.

We need to design systems that work against plausible future threats, not just against current threats. This is what we have always tried to do with 1Password.

Lessons and actions

  1. Your 1Password Master Password and your 1Password data remain safe, we designed the Agile Keychain format from the beginning to resist crackers like this. But it is also important for people to select strong, memorable, Master Passwords.
  2. It is more important than ever to have unique passwords for each site and service. As password cracking gets easier, the risks of using the same password on multiple sites increases. This is because if password hashes are stolen from one site, attackers have a better chance of discovering the password from the hash. Once they have that, they can try the same password on other sites.
  3. When using 1Password’s Strong Password Generator, try to create passwords that are at least 20 characters long.

Back to the Future

Gosney slow hash chartI’ve talked (well even boasted, I suppose) about how our earlier design decisions are protecting 1Password users today. But we have to look at what design decisions we make today will do for 1Password users half a decade from now.

Gosney’s machine can also be used against slow hashes, including PBKDF2 passwords. You can read more (and see cool pictures) of the design of Grosney’s hashcatting machine in the conference presentation slides (PDF).

Furthermore PBKDF2 was not designed to specifically impair parallel processing. But because GPUs have unusual and restricted ways of addressing memory, it is possible to design systems that make parallel processing using GPUs slower. This leaves a number of questions that we continue to look at.

  1. Do we need to change anything at all in anticipation of even more powerful machines tuned toward PBKDF2? (We don’t yet Password Based Key Derivation Function diagramhave estimates on how many passwords per second this system could try against a 1Password data file.)
  2. If we do need to change things, when do we need those changes need to be in place?
  3. Should we look at more parallel and GPU resistant alternatives to PBKDF2, such as scrypt?
  4. Should we look at tinkering with options within PBKDF2 to make it more resistant to GPUs working in parallel?

These are not new questions. We are always asking ourselves these and other questions in order to keep your 1Password data secure and protected, both now and in the future.

[Updated 2012-12-06 15:50 UTC. Updated to correctly explain that Gosney’s system is not limited to LM hashes. Thanks to Jeremi Grosney, Solar Designer, and others who pointed out my error. I have also taken the opportunity to add more clarifications and links to background throughout.]

More than just one password: Lessons from an epic hack

Mat Honan, a 1Password user and writer for Wired, did everything right. He had strong, unique passwords everywhere. Yet he was the victim of an “epic hack”, and had to put a great deal of effort into getting his digital life back.

A very brief account of this Homer-worthy hack is that someone talking to Amazon customer service got into Mat’s Amazon account, from which they were able to learn enough about him to then call Apple’s customer service to get a new password set. Once they had Mat Honan’s Apple ID and password they used Remote Wipe to erase his iOS devices and his Macs.  This has been written about extensively elsewhere, but I would like to talk about this in the context of whether there are useful lessons for 1Password users.

Mat described part of his recover process thusly:

I’m a heavy 1Password user. I use it for everything. That means most of my passwords are long, alphanumeric strings of gibberish with random symbols. It’s on my iPhone, iPad and Macbook. It syncs up across all those devices because I store the keychain in the cloud on Dropbox. Update a password on my phone, and the file is saved on Dropbox, where my computer will pull it down later, and vice versa.

But I didn’t have it on any of our other systems. So now I couldn’t get to my keychain. And so I was stuck in a catch-22. My Dropbox password was itself a 1password-generated litany of nonsense. Without access to Dropbox, I couldn’t get my keychain. Without my keychain, I couldn’t get into Dropbox.

Lesson 1: Some might need more than one password

I love the idea that 1Password allows me to just remember one password, my 1Password Master Password. But some of us may actually want to remember a couple more. Here are the strong, unique passwords that I choose to remember:1Password in Dropbox

  1. My 1Password Master Password for the desktop
  2. My 1Password Master Password on my iOS devices
  3. My Dropbox password
  4. The passcode for my iOS devices
  5. My computer login password
  6. Password for my primary email account

Not everyone will have the same list. Plus, if you use the same Master Password on iOS as you do on the desktop, then your list is of course a little shorter.

What is relevant here is number 3 on that list. I need my Dropbox password in circumstances where I may not have access to 1Password. For example, when I start using a new computer, the first thing I install is Dropbox and the second thing is 1Password. This way, I have all of my 1Password data available to me as I go about setting up subsequent things.

Of course if I always had my phone with me, I could get my Dropbox password from 1Password on my phone, but I didn’t want to count on always having my phone. I’m guessing that this is what Mat did, and he certainly didn’t count on having his phone maliciously obliterated—along with all his other devices—via iCloud’s remote wipe feature.

Fortunately, Mat found a way back into his Dropbox account—turn out he had set up Dropbox on a machine that had not been wiped. So he was able to get to his 1Password data there, and begin to recover his digital life.

Constructing strong, memorable passwords

How do I make good strong passwords that I can also remember? I try to follow my advice in Toward Better Master Passwords. I have yet to follow my own advice with everything, but I am slowly migrating the few passwords that I do need to remember to that system. Indeed, it makes sense to change these gradually so that you are sure to have solidly memorized one new password before creating another that you need to remember.

A few more things I remember

In addition to the passwords that I feel I have to remember, here are a few things that are very convenient for me to remember instead of always looking up in 1Password. I can look them up if I really needed to, but often I need them where I can’t easily get them from 1Password:

  1. My bank card PIN
  2. My bicycle lock combination
  3. My Apple ID password
  4. My SSH private key password

I simply  haven’t figured out a way to copy and paste my bike lock combination from 1Password to the lock.

Lesson 2: Become a backup believer

There are two kinds of computer users: Those who have experienced a catastrophic disk failure and those who will.
— Ancient wisdom, source unknown.

First of all, making backups is essential. Today most people have two options for a backup system. We can go with off-site backups, or we can back up to a local disk. Backing up off-site is great protection if your house burns down or is burgled. You have put your eggs in different baskets. Backup to a local disk has the advantage that you aren’t depending on a remote service that you may not be able to access in an emergency. It is hard to make a case that one strategy is better than the other in general.

Here is something that Mat learned in the process.

I’m certainly a backup believer now. When you control your data locally, and have it stored redundantly, no one can take it from you. Not permanently, at least. I’ve now got a local and online backup solution, and I’m about to add a second off-site backup into that mix. That means I’ll have four copies of everything important to me. Overkill? Probably. But I’m once bitten.

But – and here is another reason to have a memorable Dropbox password – your online, off-site backup system will require a password to access. If you encrypt your at-home backups, those too will require a password to work from. Good backups are important, but you may need to get to your 1Password data before you can restore from a backup.

An old lesson: Don’t reuse passwords

Even if we take good care of our passwords, that doesn’t mean that all the sites and services that we use take the same care. Mat’s case illustrates this fact when it comes to password reset mechanisms, but it can also apply to how passwords are stored and encrypted on sites. Because not everyone handles things perfectly, we need to make sure to use unique passwords for each site and service.

Friends don’t let friends reuse passwords

We’ve written about password reuse before, and we’ll be writing about it again. Password reuse—using the same password for multiple sites or services—is both rampant and dangerous.

There is real evidence that people are getting robbed because they are reusing their passwords. Thieves systematically exploit reused password to pay for retail items or hijack accounts for other intentions. And yet, we are reminded again this week by the recent leak of almost half a million Yahoo passwords that a majority of people just can’t stop reusing passwords.

I’ve seen password reuse and the damage done

Suppose you used the same password on Sony’s PlayStation Network as you Best Buyuse for your password when shopping with Best Buy. Now, suppose that your PSN username and password was among the 77 million leaked in April 2011. An attacker could, in principle, use that information to take a good guess at your password for, say, Best Buy.

Well this isn’t just something that can happen “in principle”. From an underappreciated report by John Fontana over at ZDNet:

After months of Best Buy customers reporting compromised accounts, the company has finally confirmed hackers are attacking its online retail site using credentials stolen from other sites.

It’s a worst-case scenario, where credentials stolen from one site are used to access other sites, most notably retail or banking sites where hackers can extract some value.

I have no doubt that things like this have been going on for a while, but it is always hard to confirm that this is what has happened when someone “hacks” a users account at a retail site. So let there be no doubt that password reuse puts people into real danger. It happens.

Some habits are hard to kick

Sites and services that store user passwords unencrypted or poorly hashed are a serious danger to their customers. But when they get breached and their password database made public, it is a boon to people who study password security. One of those people is Troy Hunt, who has taken this as an opportunity to look at password reuse between PSN and Yahoo.Chart of PSN-Yahoo password reuse

Of the 302 usernames in common between the two breaches, 59% of them had the same password on each site. Note also that the PSN breach was more than a year ago and was very widely reported. Put simply, we can estimate that about 60 percent of people ignore advice to change their passwords elsewhere.

Helping you to help yourself

I’ve argued many times before that when we see people systematically making poor security choices, we can’t just blame the user. We—the security business—have to look at how we can make it easier for people to behave securely. 1Password is our attempt at fulfilling that goal. We work to make it easy for people to have strong and unique passwords for each site.

First of all, 1Password provides you with a Strong Password Generator, in both the app itself and the 1Password browser extension. This generator makes it drop-dead-simple to create website passwords that are strong and unique. Plus, you don’t need to remember them because 1Password remembers them for you.

Although 1Password wasn’t born yesterday, many of us have Logins and passwords for sites that were created before we had the Strong Password Generator, which means we may still be using some passwords on multiple sites. Here are some tips on how to use 1Password to help you find duplicate password and clear those up.

Websites have responsibilities, too

Anybody who stores your passwords has responsibilities, too. We know that sites get compromised and their user databases stolen. What we don’t really know is how frequently this happens because only a fraction of those breaches get made public. Not only do websites and services need to take steps to prevent the theft of their user’s personal data, they need to store the passwords in a form that is useless to intruders.

It appears that the Yahoo passwords were stored with no encryption or hashing at all. I was astounded when this was discovered with Sony’s PSN last year, and I am astounded today that Yahoo would make the same mistake. I have been berating sites for not hashing their passwords well; I hadn’t expected to encounter more sites that didn’t hash at all. Because of their poor practice, everyone whose Yahoo password was leaked is vulnerable to having their accounts hijacked on every other site where they use the same password.

A salt-free diet is bad for your security

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

PasswordSHA-1 Hash

(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 like
PBKDF2, which 1Password does use when encryption your Master Password.

Flashback to Leopard

OS X LeopardIt seems that my ability to predict the future with respect to Mac malware is, indeed, on par with Digitime’s ability to predict anything. Just recently I wrote, “on the Mac, Leopard and Tiger are no longer being updated”. To prove me wrong (yeah, I’m sure that’s why they did it), Apple has just released a couple of security updates for Mac OS X 10.5 (Leopard). These are “Flashback Removal Security Update for Leopard (Intel)” and “Leopard Security Update 2012-003.” Both of these are available through Software Update.

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.

Failure to keep systems up to date with the latest versions of software is an enormous security risk. Good updating habits not only help keep your system free of malware, but these habits can help reduce the amount of malware in the environment.

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.

Only you should 0wn your data, Part 3: The Mac malware landscape

It’s tough to make predictions, especially about the future.

—Yogi Berra

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. OS X Version over time [from OmniGroup]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.

New Problem for Old FileVault users

FileVault iconIf 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

  1. 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.
  2. 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.

As David Emery, a discoverer of this problem, said in his report.

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.