Posts

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 SquirrelsAreEvil.net, 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.

big-and-small-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.

autolock-1P3-8

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.

Summary

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.

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.]

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.

1Password 3.6.5 for iOS is out with PBKDF2 goodness!

1Password Pro icon1Password for iPhone, 1Password for iPad, and 1Password Pro (for both iPhone and iPad) have just been updated to version 3.6.5. All of the changes are behind the scenes, but they include a great security enhancement to how your Master Password is protected. Different versions may become available at different times in different locations, so if your free update isn’t ready for download just yet, try again in a little bit.

In addition to the security enhancements discussed below, there are a few bug fixes, more syncing in the background, and some images tailored for the Retina display in the new iPad. If you just want the cliffnotes, here we go:

★ Improved security. Now using 10,000 PBKDF2 iterations to protect the encryption key.
★ Dropbox authentication tokens are now stored in the system keychain.
★ Better support for iPad retina display.
★ Improved Login filling.
☂ Bug fixes.

But if you want to learn a little more about what we’re doing under the hood to protect your 1Password data, venture on.

10000 PBKDF2 iterations

Your Master Password on your device is now protected with 10,000 iterations of PBKDF2. What this means is that if an attacker were somehow to get hold of your encrypted 1Password data from your phone (not an easy thing to do if you take proper precautions), it will be even harder for them to run automatic password guessing software against your master password. PBKDF2 makes the mathematical process of checking whether a Master Password is correct much longer and more difficult.

Your secrets are very well encrypted and protected by your Master Password, but these new measures strengthen that protection. You can read about PBKDF2 in an old article, Defending against crackers: Peanut Butter Keeps Dogs Friendly, Too to get more details as it applies to 1Password on the desktop; the same ideas work on iOS devices.

Why change things now?

We’ve long considered using PBKDF2 in 1Password for iOS. The advantages of using it are clear: It provides substantial additional resistance to attacks by password guessing software if your encrypted data falls into the wrong hands. There are a few reasons why now was the right time.

We have faster devices

The principle reason this didn’t come sooner is that, with PBKDF2, unlocking your 1Password data on older devices will take noticeably longer and will consume more power than not using PBKDF2. People running 1Password on first generation iPhones will now have an unlocking delay that may last up to a couple of seconds, and a delay of about one second on the iPhone 3G and on the  first generation iPod touch. Delays should not be particularly noticeable on newer devices, and the vast majority of our customers now use 1Password for iOS on said newer devices.

A great feature of iOS 5 and OS X 10.7 is that the number of PBKDF2 iterations can be calibrated to the particular device. We will be making use of that in 1Password 4 for iOS, and we already make use of that in 1Password 3.9 on Lion.

Finding the right implementation

A lesser reason is that the development toolkits for iOS 3 don’t include functions for performing PBKDF2. We try to work with established tool kits as much as possible. iOS 4 (and particularly iOS 5) contain built-in features that make it easier to write programs that perform complicated encryption functions.

That said, we are still able to bring PBKDF2 to 1Password running on iOS 3. Yes, it will be slow and power hungry on older devices, but it is possible because we found a way to take the PBKDF2 function from the OpenSSL libraries and incorporate it into our code. So even though this isn’t in the Apple supplied SDK for iOS 3, we are able to use a well tested and reviewed implementation.

Changes in the threat landscape

There has also been a change in the threat landscape since we first developed 1Password 3 for iOS. There are several “forensic” tool kits on the market for breaking into iOS devices. As new ways in which data can be taken from iOS devices come to light, we need to provide even better protection against off-line attacks on your 1Password data.

It is probably far less likely that that someone will capture your encrypted 1Password data from your iOS device than your 1Password data from your computer. A stolen computer, unless you use FileVault or some other disk encryption, means that your 1Password data will be available to who ever gets a hold of your disk. This is why we built PBKDF2 into 1Password on the desktop a long time ago.

But it is also the case that most people use better Master Passwords on their desktop systems than on their mobile devices. And so, in the less likely event that the data gets captured from an iOS device, the master password could do with extra protection. If everyone had sufficiently strong Master Passwords, PBKDF2 wouldn’t be necessary. But let’s face it: a very strong Master Password on an iPhone is a Master Password that won’t get used much.

Elcomsoft analysis

Although we have long been aware of the benefits of using PBKDF2, a recent report (PDF) by researchers at Elcomsoft highlighted how quickly a master password could be cracked without the additional protection of PBKDF2. We discussed that report in a recent blog post, “Strong Security Requires Strong Passwords“.

Other security improvements

Dropbox OAuth tokens

1Password stores your Dropbox username and password very securely on iOS for automatic syncing, but it hasn’t been quite as careful with the OAuth tokens used when connecting with Dropbox. If this data is copied and used on another device, it would grant access from that other device to a Dropbox account. We have fixed this in 1Password 3.6.5 for iOS.

We’ve discussed this issue extensively in a recent blog post: OAuth, Dropbox, and your 1Password data.

Padding, integrity, and standards

We try to stick to standards when it comes to encryption and protocols, but even well established standards can later be discovered to be flawed. There turns out to be a design problem with the padding scheme used as parts of the PKCS standards. Introducing PBKDF2 (also defined in the same set of standards) gets around the problem.

I won’t go into much detail, but here is a little background into the issue. An encryption algorithm like AES works on a block of data at a time. In the case of AES the blocks are 16 bytes (128-bits) long. Because the data to be encrypted won’t always be a multiple of 16 bytes, some extra data gets added to the end to “pad” it out to a multiple of 16 bytes. The details of the padding scheme have to include some clever tricks so that when the data in decrypted, the decryption process can recognize where the pad begins, so it knows what to remove.

The problem is that the padding scheme has also been used as an integrity check. That is, it provides a signal to the one decrypting the message whether the data has been modified. Padding is not well suited to that purpose, but that usage means that under certain circumstances it can be used to very quickly verify whether something has been decrypted correctly. The attacker is saved an extra decryption trial in testing whether they have “guessed” the right password.

The simple solution is to make use of cryptographically appropriate integrity checks, Message Authentication Codes (MACs) after encrypting the data. That is, the integrity check is performed on the encrypted data instead of on the plaintext. By using PBKDF2 we are forcing an attacker to go through a large number of extra steps with each “guess”, overwhelming any advantage an attacker might gain through the PKCS padding problem.

Processes and products

All this allows me to bring up a point that we’ve made before but will continue to make: Security is a process, not a product. One aspect of this is that a tool that your security depends on is never “done”. This is not the first security improvement we’ve made over the years, and it certainly won’t be the last. But process isn’t only in updating product. Process is about how people do things. That includes our own testing procedures, and it also includes always working to understand how people use 1Password so that we can continue in our effort to make the easy thing to do also the secure thing to do for people.

[Update April 11: Several people, including Quirks In Tech, have correctly pointed out that I should have been much more explicit in this post about the role that the Elcomsoft report played in our decision to start using PBKDF2. Earlier drafts of this included an extensive section on exactly that, but it got lost as I tried to cut this down to size. I've added a short section back into this post. -jeff]

Do you know where your software comes from? Gatekeeper will help

Mountain LionYou trust us to provide you tools that keeps some of your very valuable secrets safe. Part of that trust means that, when you install or update 1Password or Knox, you know the app you are getting comes from us. After all, if a bad guy produces a modified version of 1Password, it could do bad things. So far there have been no such modified versions “out there” and we want to keep it that way. In addition to all of the things that we do to ensure that you get the genuine article, Apple is working to make it even easier to keep your Mac free of malicious software.

Apple has just announced that Mountain Lion (to be released in the summer of 2012) will include something called Gatekeeper. This is a core OS X feature that I and others have been anticipating for a while. (surprisingly, almost all of its components are actually built into the latest version of Lion). Roughly speaking, Gatekeeper will allow you to control which apps to run depending on where the software comes from.

The question then is: how does your Mac know where your software comes from?

The Magic of Digital Signatures

I would love nothing more than to explain the mathematics behind digital signatures. But for today’s purposes, let’s just say it is magic (even when you know the math, it feels like magic). When you connect over HTTPS to a secure website, that website proves who it is because it knows a particular secret (called a “private key” or “secret key”). The corresponding “public key” is not kept secret.

The magic is that the website doesn’t have to reveal the secret to prove that it knows it.

Evilgrade

Evilgrade Interface

Instead your computer system can use the non-secret public key to construct a mathematical puzzle that only someone who knows the secret key can solve; anyone with the public key can check that the solution to the puzzle is correct, but they can’t figure out what the secret key is. This can prevent someone hijacking the download process with a tool like evilgrade.

In the same way that a secure website can prove who it is without revealing any secrets, a digital signature on a file (or a group of files) can prove who made it. If someone makes even the smallest change to the signed file, the signature won’t verify.

Three Kinds of Apps

Applications that you install through the Mac App Store (MAS) are all digitally signed this way. But for years, Apple has been encouraging developers to digitally sign applications even if they aren’t sold through the MAS. So on your Mac today there are probably three kinds of applications:

  1. Those that came from the MAS
  2. Signed applications that did not come through the MAS
  3. Applications that aren’t signed

Gatekeeper will allow you to decide which of these categories of applications may run on your machine.

If you are running 1Password 3.9, then that came signed through the MAS. But if you are running 1Password 3.8 or Knox 2 from our website, they are still signed by us and will fall into the second category.

Verifying a signature today

When you install an application from the Mac App Store, the installation process checks the signature. It won’t install the app if it isn’t signed or if the signature doesn’t verify (which is more likely to happen through a damaged download than through a malicious attack, but both can happen). When you update the non-MAS version of 1Password, our updater runs a code signing signature verification as one of the three checks we use to ensure that you are getting the genuine 1Password from us. For those who are curious, our other two verification mechanisms are (1) fetching from a secure web server and verifying the server signature, and (2) checking a cryptographic checksum for the download which we fetch from a separate secure server.

But suppose you wanted to check the version of 1Password that you currently are running. All of those behind-the-scenes checks on the download and installation processes won’t help you do that. Well, the way to check now is hard, which involves running a complicated command in a Terminal window. Here it is for the non-MAS version of 1Password

codesign -vvv -R="identifier ws.agile and anchor trusted" \
/Applications/1Password.app

The output should be something like

/Applications/1Password.app: valid on disk
/Applications/1Password.app: satisfies its Designated Requirement
/Applications/1Password.app: explicit requirement satisfied

Clearly we don’t expect users to run these sorts of commands.

codesign in Terminal

We have been using Apple’s code signing mechanism for years because we wanted to be able to direct concerned users to this kind of command if they specifically ask. We’ve also been using it for additional security in our own updater. But another reason that we’ve been doing this for a while is because we’ve been anticipating either Gatekeeper or something similar.

Verifying a signature tomorrow

Gatekeeper will perform the codesign verification when an application is launched. This adds a great level of additional security beyond verifying the download source when the application is downloaded and installed.

A mathematically valid signature is the easy part

Apple Developer IDThe mathematics (the magic) makes all of the above simple. The hard part of Gatekeeper is the trustworthiness of the signatures. I can sit at a my computer and create a public/private key pair that says that it belongs to Alan Turing. Since Turing has been dead for more than half a century, few people would think that it actually belongs to that great mathematician and codebreaker. But what if I picked the name of a trusted person or institution that is around today?

The answer is that some trusted third party digitally signs my public key after verifying it belongs to who it says it belongs to. I’ve discussed how this system works (and how it can break down) when it comes to web server certificates, so I won’t repeat that here; the concepts are all the same. In the case of codesigning certificates for Mac developers, Apple does that checking and signing.

We changed our name a while back, so at some point before Gatekeeper is in common use, we will have to update our codesigning certificate identifier from “ws.agile” to “com.agilebits”. But for the time being, when you see “ws.agile” as the entity behind the digital signature on 1Password and Knox, you should know that that is us.

Other than getting a new certificate with our new name, we have been ready and waiting for years to get on board with the new security provided by Gatekeeper.

[Update: As of 1Password 3.8.19 Beta 1, 1Password is now signed with our new Apple Developer ID, AgileBits Inc.]

PSA: Keep your software up to date (an ode to Apple Security Update 2012-001)

Mac Software Update

Apple released its first big OS X update of 2012 this week, and it’s pretty big. It’s easier than ever to keep your computer up-to-date these days, but it never hurts to review good habits, especially when it comes to keeping your computer and data secure.

By far, the largest number of compromises of home computer systems is through vulnerabilities that the victims could have avoided if they only kept their systems up to date. If you want to see the numbers, take a look at Microsoft Security Intelligence Report volume 11 (PDF). While that report is specific to Microsoft Windows, the lesson applies across operating systems.

This is why I am reminding all Mac users of Lion (OS X 10.7) and Snow Leopard (OS X 10.6) to update their systems by using Software Update. For Lion, the security updates come as part of the update from 10.7.2 to 10.7.3. On Snow Leopard, it is a separate security update that does not change the version number. If you are still using OS X 10.5 (Leopard), please understand that Apple is no longer providing any updates, including security updates for it.

There are a large number of security fixes in the latest (February 1, 2012) updates, Security Update 2012-001. None of the fixed security issues directly affect 1Password or Knox, but as always, it is better to keep your system secure through regular software updates.

Automatic Operating System updates

Windows Update icon On both the Mac and Windows you can set your system to check for updates automatically. On the Mac, just go to Apple Menu > System Preferences > Software Update and use the “Scheduled Check” tab.

On Windows 7, just go to Start > Control Panel > System and Security > Windows Update and then “Change settings” in the sidebar at the left. Note that the layout is slightly different depending on the version of Windows.

Windows Update Settings window

Keeping 1Password up to date

Naturally, you should also be keeping 1Password and its components up to date. If you are using the Mac App Store version of 1Password, then the App Store application will keep track of this for you. Just keep an eye out for a red badge on the App Store icon in your Dock or open the store every now and then and check the Updates tab.

If you got 1Password from our website, just go to 1Password > Preferences > Updates and make sure that you have things set to automatically check for updates.

Keeping the 1Password extension up to date

Back in the old days (before June 2011), the 1Password browser extensions came directly with the 1Password application. If we needed to make a change to, say, the Firefox extension we needed to release a new version of 1Password. Now, for all supported browsers on the Mac and for Safari and Chrome on Windows, we have a new spiffy browser extension. This extension is automatically updated through the each browsers’ extension management system so you don’t have to lift a finger!

This allows us to update the extension much more rapidly than we update the main application. It is also why the Safari upgrade to 5.1.3 that comes with yesterday’s Lion update and the release of Firefox 10 a few days ago do not require new versions of 1Password to be released.

Each browser does things a bit differently, so I won’t review their individual update processes here. Instead, take a look at our dedicated guide with step by step instructions for installing and updating the 1Password browser extension.

Make the computer do the work

Keeping software up to date used to be a chore, but more developers and more systems are working diligently to make it easier. Things like the Mac App Store along with automatic checking for updates within operating systems and individual apps lets you pass most of the work to your computer. After all, computers should be the ones performing the tedious chores. You do still need to supervise the computer in this task to make sure it gets done, though.

It’s hardly anything new or insightful to say that keeping your system up to date is one of the best things you can do for your security, but that doesn’t make it any less true.