1Password for Mac and iOS on sale to celebrate WWDC 2012!

Today kicks off Apple’s World Wide Developer Conference in San Francisco, and some of the AgileBits team is out there to partake of Apple’s engineering knowledge and make sure the local bars are properly stocked. But we figured we should celebrate Apple’s event with you too, so for a limited time, 1Password for Mac and 1Password Pro for iOS are on sale!

“How much on sale,” you ask? “For how long,” you wonder? Well: they’re both 20 percent off through Saturday, June 16, so when it’s gone, it’s gone. But don’t forget: no matter when you buy (or bought) 1Password for Mac in the Mac App Store, you get a free upgrade to 1Password 4 for Mac when we release it!

In other words: 1Password for Mac is just $39.99 in the Mac App Store, and 1Password Pro (the universal one for iPhone and iPad), is just $11.99 in the App Store. But only until the 16th. Whether you’ve been waiting to pick up 1Password or you know someone who could really use a copy, this is the perfect way to get on board.

1Password for Mac plays just fine in Apple’s sandbox

You may have heard the news that “Apple’s sandbox deadline has arrived” for the Mac App Store, and that it might cause headaches for some developers and their apps. There’s a lot to talk about in terms of this “sandbox” thing that Apple’s pushing, but I want to skip to the important part for you, our wonderful customers and readers: the Mac App Store version of 1Password has been ready for sandboxing since its debut in September 2011. For bonus points, the latest website and Mac App Store versions are even ready for Mountain Lion, too!

That means you have nothing to worry about as to whether Apple’s sandboxing rules will affect 1Password and its many excellent features. Our valiant developers started doing a ton of work on 1Password a long time ago—as soon as we heard sandboxing was coming to OS X. AgileBits has been humming along just fine since then, dreaming up new features, listening closely to your feedback, staying one step ahead in security, and building new foundation for the future of 1Password.

Now, if you’re interested to learn more about sandboxing and what it means for both developers and users, we’ve discussed it a little bit here on the Agile Blog. In a nutshell: Apple realized that if it added some restrictions to the files and parts of the system that applications can access, OS X can become more secure and resilient to malware or your typical rogue app. I guess you could say Apple gave these rules a test drive in iOS, since that’s how its apps have worked since the original iPhone in 2007.

Generally speaking, most users probably won’t notice any difference in day-to-day use of Mac App Store apps. But Apple’s new sandboxing restrictions for apps in its store can pose challenges for some developers whose apps have had free reign all these years. In some cases, developers might have to change or remove features, but some might have to remove their apps from the Mac App Store entirely. Again, 1Password has fortunately been prepared for these rules for nearly a year.

As for our previous posts on sandboxing and why Apple is doing it, you can check out Jeff’s posts about Gatekeeper, a feature coming to OS X that gives you control over how you install new apps.

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.

Alfred 1.2 for Mac is out with 1Password 1Click Bookmark superpowers!

Remember how Alfred, the excellent productivity utility from Running With Crayons, integrated 1Password 1Click Bookmarks in a recent beta? We’re happy to say those crazy colorers wrapped up the beta, and Alfred 1.2 is out!

If you use Alfred and you have its PowerPack which adds some great extra features, you can now quickly browse your 1Password Logins right inside Alfred, then open one to login with your default browser—all with a couple strokes of your keyboard no matter what app you’re using. Simply invoke Alfred, type “1p,” hit Return on the “1Password Bookmark ‘…'” option, and type a couple letters of the Login you have in mind. Then hit Return and watch the magic happen.

Use the 1P trigger in Alfred to get to your 1Password logins quickly!

This has been one of Alfred’s most popular feature requests for a while, and we’re honored that they put this together so well. Alfred 1.2 is a free update from Running With Crayons for website customers who have the PowerPack add-on (sorry, Mac App Store Alfred users, but Apple doesn’t allow the tech in the store that powers this 1Password+Alfred integration). Just grab the update, open Alfred’s preferences, and check out the new 1Password sidebar item for a powerful and quick new way to open your 1Password Logins!

Only you should 0wn your data, Part 2: Staying safe

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

—Lewis Carroll “The Hunting of the Snark”

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

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

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

1. Keep your software up to date

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

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

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

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

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

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

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

Infection rate before and after vulnerability fixed

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

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

How to keep things up to date

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

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

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

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

  1. Operating Systems. You need to schedule Software Update (on the Mac) or Windows Update (on Windows) to check for updates automatically.
  2. Web browsers. In each web browser, you will be able to configure its updating habits in its preferences.
  3. Web browser plug-ins. These are the programs – such as Adobe Flash Player, Adobe Reader (on Windows), Java, and Silverlight – that are used to open certain kinds “in the browser” that the browser itself can’t handle natively.
  4. Email software. If you are using the email software that comes with your operating system (Mail.app or Outlook), then they will be updated with the operating system. But if you use a third party mail program, then you need to make sure that that is kept up to date.
  5. Anything that opens files that you did not create yourself. Whatever software you use to look at pictures, read word processor documents, work with spreadsheets, or listen to music files must be kept up to date.
  6. 1Password. Well, really any software that has to do with your security. 1Password automatically checks for updates after it is launched and will only check periodically in case you are like me and never relaunch it because you never close it. You can configure 1Password’s updating behavior in Preferences > Updates. You should also keep the 1Password browser extensions up to date, which is typically done automatically right within the browser.

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

2. Back up your data

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

Most importantly, good backups are a vital part of data security over all. As the saying goes, there are two kinds of computer users: those who haveexperienced a catastrophic disk failure, and those who will.

3. Pay attention to where your software comes from.

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

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

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

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

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

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

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

4. Virus Scanning?

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

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

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

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

Other tips?

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

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

A peek behind the Gatekeeper

Mountain Lion1Password 3.8.19 for Mac is now available and it contains a number of improvements, and I’d like to provide a brief run down of those before getting into the meat of this article.

  • When making its backups, 1Password now performs some extra sanity checks on the data before backing up. This way, if your data is damaged, you won’t end up with lots of backups that are also damaged.
  • The same improvements that went into 1Password 3.9.5 (the version from the Mac App Store) are in 3.8.19 and will keep 1Password ahead of the curve as new browser versions are released.
  • Delaying when our Updater runs its check so that it doesn’t get in your way when you first launch 1Password.
  • A number of bug fixes, mostly improving the Conflict Resolver.
  • And the topic of this article, 1Password 3.8.19 fully qualifies as from an “identified developer” for the purposes of working with Gatekeeper in the forthcoming version of OS X, Mountain Lion.

Let me remind you that 1Password 3.8.X is the version from our own store that you can download from our website, and 1Password 3.9.X is the version from the Mac App Store. We are actively developing both, but the releases of updates to each of these may not always happen at the same time.

Mountain Lion ready

With 1Password 3.8.19, we have completed the final step in making 1Password for Mac completely ready for Apple’s upcoming version of OS X, Mountain Lion (1Password 3.9, from the Mac App Store, has been ready for a while). This involved codesigning 1Password.app with our new Apple Developer ID so that it will be treated as a signed application by Gatekeeper, one of Mountain Lion’s key new security features. We’ve mentioned this before in an earlier post: Do you know where your software comes from? Gatekeeper will help, but I thought it would be fun to provide more detail now that this is ready in 1Password 3.8.19 for our website customers.

What does Gatekeeper do

Security preference pane with GatekeeperGatekeeper gives you more control over what software runs on your Mac. With Gatekeeper, Apple is now drawing lines between three different kinds of software, depending on where it comes from. There are apps that you install from the Mac App Store, apps that comes from “identified Mac Developers”, and then there’s everything else.

Gatekeeper gives you the power to disallow apps from sources other than the Mac App Store. You may restrict your Mac to run only apps from the Mac App Store, or you can also include software that comes from identified developers. You can also stick with the way things have always worked and allow apps to be installed from “Anywhere.” Apple’s goal with Gatekeeper is to offer a layer of protection, built into the core of the operating system, that helps you make sure the software you are running hasn’t been tampered with, and that it comes from trusted sources.

1Password 3.9 already comes from the Mac App Store, so it will run even under the most restrictive Gatekeeper setting. As of 1Password 3.8.19 released yesterday, 1Password 3.8 verifies as coming from an “identified developer,” Gatekeeper’s second option.

“How does my Mac know where my software comes from?”

The remainder of this article is about answering the question “so how does my Mac really know that an app comes from a trusted developer?” I find the answer to that question fascinating, but it isn’t simple. There is no shame in just accepting that it is all part of the magic of cryptography. But if you’d like to know a bit more about that magic, read on.

Exploration

Before I actually explain how the system works, you may wish to poke around at what is involved. Until recently, examining the developer ID for an application involved working through obscure combinations of the codesign command in a Terminal window while also hunting down files inside of bundles. Fortunately, Rainer Brockerhoff has developed a nice free utility, RB App Checker Lite, which makes it much easier to see what certificates and certificate authorities are involved in the signing of your apps. Let’s see what happens when you ask it to take a look at 1Password 3.8.19.

1Password certification information viewed with RB App CheckerIn the red box in the screenshot above, we see “The code and signature validate correctly”. This is telling us that 1Password.app matches the signature. If some crucial part of the 1Password.app had been changed, then the code (the files that make up 1Password.app) and the digital signature would not match.

The part in the green box is what tells you that it really is Agilebits Inc. (that’s us) who created the signature. You can click on the white arrows to see details of each certificate involved, but most useful is to click on the arrow in the blue box. That will show the certificate chain.

1Password codesigning certificate chain

Again, you can explore details of the certificate chain. You will see that the certificate that signed 1Password.app says that it belongs to Agilebits. The AgileBits certificate was certified by Apple’s Developer ID Certificate Authority, which in turn was certified by Apple’s Root Certificate Authority. That Apple Root CA is trusted by your operating system.

Secrets and Files

I’ve been tossing around terms like “digital signature”, “codesigning”, “certificate”, and “certificate authority”. Now I’ll get around to explaining what those mean. All of these technical terms are so intertwined with each other that there is no good place to start, but I’ll start with the notion of a digital signature.

Let’s say you have a garden variety, everyday computer file. It’s possible to create a digital signature for it. To do that, you need (among other things) a secret key. The digital signature will be some special cryptographic output that depends on both the contents of the file and your secret key. What makes digital signatures work is that there is another key, called your public key, which is mathematically related to your secret key. Someone trying to verify the digital signature can do so by checking your public key along with the file that you’ve signed. If the signature verifies, it means that the signature could only have been created by someone who knows the secret key.

Because the signature also depends on the contents of the file, we know that the signed file must be identical in every bit to what was originally signed. If the file has been modified, the signature won’t verify. And only someone who knows the secret key can create a signature.

Codesigning is just the specific way of producing a digital signature for a software bundle. An application like 1Password.app is not a single file, but actually a collection of many files. Apple’s codesigning mechanism allows for a single digital signature to work as a signature for a collection of files. The signature itself may include some additional requirements that the developer wants to have checked when the signature is verified, and there are other things that are part of a code signature. But for what follows, you may just think of it as a way of signing all the crucial portions of the application, even if they are spread out among several files.

About the math

As I said there is a special mathematical relationship between the secret key and the public key that allows this to happen. One requirement of the system is that someone who has access to a public key, a signature, and the signed data cannot figure out what the secret key is.

The most widely used system, RSA, depends on prime numbers. Prime numbers are numbers that can only be evenly divided by 1 and itself. For example, 51 is not a prime number because it can be factored into 3 and 17. 41, on the other hand, is prime. While some families have special celebrations for birthdays and anniversaries that are multiples of 10, in my family we reserve these for the prime numbers. It’s particularly appealing because prime numbers are fewer and further between as we get to the bigger numbers.

The secret key includes two very very large prime numbers, the public key includes what you get when you multiply those two prime numbers together, which gets you an even bigger number (those of you who know that the public key is not quite that should just let me get away with this simplification). When we use big enough prime numbers, there is no feasible way of going from the product of the two prime numbers back to the prime numbers themselves.

But the mathematical relationship between the secret and public key means that it is possible to use the public key to construct mathematical puzzles that can only be solved with knowledge of the secret key. This, deep down, forms the basis of what is called public key cryptography.

Here is a 617 digit (2048 bit) number that is the product of two 1024 bit prime numbers

27219047959652654722414170131901754810882037173366387499643752583360
53674248472885748311121894086236015825177742540974215589410617055811
41056251871687611322203645648061852827702887407867981735879821807359
50224524930259181407685867849596786096790404160010876158425560398851
41008831976697149422479797818743514039235769485328395195614137252841
88464854991690851521459279495154864183891934329195018204208468538473
68871936474843479723548096187507192106674753171257734855506742032089
84432415517977675338784314535588802117418628093418022096614839091351
52559954997038551099013710643874352212670179579776988148618882559168
53533

That number would be part of the public key, when the corresponding secret key would contain the two 512 bit prime numbers this big number factors to.

There are systems based on other mathematical relations, including Discrete Logarithms and Elliptical Curves. All have the same property in that, while there is no feasible way to get from the signatures and public keys to the corresponding secret keys, anyone with the public key can verify that only someone who knows the corresponding secret could have created the signature.

A certificate, under any other name, would not verify the same

The 1Password.app is digitally signed using our secret key. Only those who can get at that secret could create a signature that anyone can then verify using our public key. As you can imagine, our secret key is protected by a very strong password.

But anyone could create a digital signature of modified versions of 1Password.app with their own secret key. So the next question is: how does your computer know that the public key it used to verify 1Password.app really and truly belongs to us? This is where a certification authority (CA) comes into play.

The file containing our public key contains much more than just the mathematical public key itself. It contains information about the mathematical public key (like what sort of system is used) and it also contains our name and other identifying material. This is our certificate. There is a whole lot of stuff in a certificate, but let’s focus now on information about us (the owners of the certificate) and the numbers needed for the public key.

Our public key and our name in our certificate is, ultimately, just data stored on a computer; and just like any data stored in a file, it can be digitally signed. If someone tinkers with the name in a certificate, then the signature used to sign the certificate previously will not verify correctly. So just as our signing of 1Password.app means that if it is tampered with, the signature won’t verify; if someone tampers with a signed certificate, then the signature on the certificate won’t verify.

So, crucially, our certificate has a third kind of information. We’ve already talked about (1) our name and other identity information; and (2) our public key and other technical information that goes along with that. The third type of information is a signature (from someone else) who has signed the first two types of information in the certificate.

Who signs the signers?

As I said in the previous section, our certificate is in fact signed by someone else’s secret key. Whose? The answer is that it is signed by a key belonging to Apple. Apple is issuing and signing certificates, which makes Apple act as a certification authority. Someone who has access to the private key used for signing Apple developer certificates has determined that we meet the criteria needed to call ourselves AgileBits Inc.

The public key that is used to sign the AgileBits certificate is part of a certificate that belongs to “Developer ID Certification Authority”. The next question is: what authority signed the Developer ID Certification Authority’s certificate? And the answer will be another certification authority belonging to Apple. It is called “Apple Root CA”.

Who signed the Apple Root CA’s certificate? In practical terms, nobody did—though, technically, it is a self-signed certificate. A self-signed certificate says, “I am who I say I am because I say so.” Normally when you encounter self-signed certificates you should be cautious.

Apple Root CA

Unless you have some other reason to trust a self-signed certificate, you should be suspicious of it. Fortunately, Apple gives us a very good reason to trust this certificate authority. They have included the Apple Root CA certificate in every copy of OS X and marked it as “trusted” by the system.

You can check to see what root certificate the operating system trusts by launching the Keychain Access application (in the Utilities folder in Applications). With that you can inspect the System Roots keychain which contains, among other things, a variety of certificates from various certification authorities.

All of this checking of certificates and signatures is performed by the system. With Mountain Lion, Apple is bringing more of this technology to protect what applications are, or are not, allowed to run on your Mac.

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

Go Tell it on the Mountain Lion: 1Password will be there

Mountain LionMountain Lion and Safari 5.2 are on their way, and 1Password is readier than it has ever been at this stage in an operating system upgrade.

It won’t be news to anyone that Apple has announced that the new next version of Mac OS X, called Mountain Lion, will be released in the summer of 2012 and that we developers have been given previews to play with. Developers are under a non-disclosure agreement, so I’m not allowed to say anything about Mountain Lion and Safari 5.2 that Apple hasn’t already made public. What I can tell you is that of all the times we’ve been given a first look at a new operating system version, we’ve never had a smoother ride.

1Password Browser ExtensionCredit for this steady transition goes to our “new” way of dealing with browser integration that we developed last year. By working with the grain of browser updates and official extension support, updates barely cause a hiccough.

I should note that, since Mountain Lion is in beta until its scheduled release in summer 2012, there will almost definitely be differences between what was given to developers last week and what will be released to the public. Everything is subject to change. But the ease of this transition so far is absolutely unprecedented. We’ve only spotted one issue so far, a peculiar cosmetic turn of events. I’m sure that we will find other things that need to be fine tuned for Mountain Lion, but we are in a remarkably great position at the moment.