Posts

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]

OAuth, Dropbox, and your 1Password data

1Password in DropboxA number of iOS apps, including 1Password, have a security problem in how they handle OAuth tokens. 1Password 3.6.5, which was submitted to Apple several days ago, fixes this. This will be a free update for all owners of 1Password for iPhone, 1Password for iPad, and 1Password Pro (for iPhone and iPad). We can’t predict how long Apple’s approval process will take, but the update should be available soon, if it isn’t already by the time you read this.

Because of this bug, someone who gains physical access to your device may be able to copy authentication tokens off of it, then install those tokens on their own device to access your Dropbox data. It is not entirely clear at the moment under what circumstances an attacker will also need the device passcode. It appears that if the device has previously been synced with the computer the passcode isn’t required. In any case it is important to protect your iPhone, iPad, or iPod Touch protected with a good passcode.

We have been extremely careful in how we store your Dropbox username and password for automatic syncing, but like many others, we didn’t take the appropriate precautions when it came to OAuth tokens. These tokens allow quick connection to Dropbox (Facebook and other services also use OAuth). Of course, any 1Password data that an attacker fetches from your Dropbox account is still encrypted by 1Password.

In 1Password 3.6.5, which we submitted to Apple at the beginning of the week, we store OAuth tokens securely in the iOS keychain, where they are properly encrypted and cannot be copied to other devices. However, if other apps that use Dropbox have the same problem (and it looks pretty common), then OAuth tokens can be copied from those apps as well.

The OAuth problem

The problem of how OAuth tokens are stored was first discussed Tuesday (April 3) by Gareth Wright reporting on the Facebook iOS app.OAuth logo Since then, it became clear that the Dropbox app itself has the same problem. Presumably there are many other apps that connect to services like Facebook or Dropbox that are unfortunately in the same boat.

Dropbox have told The Next Web that:

[Our] Android app is not impacted because it stores access tokens in a protected location. We are currently updating our iOS app to do the same.

Facebook’s initial statements have been less clear, but no doubt they will be submitting a fix soon.

For one of the best discussions of this whole thing, please see the report and analysis by The Next Web.

What this means for you and your 1Password data

1Password Pro iconThis design problem, both in versions of 1Password prior to 3.6.5 and in other apps, means that it is easier for an attacker to get hold of and manipulate your 1Password data stored on Dropbox than we had anticipated. I used to say that it was far more likely that someone could get hold of your 1Password data by stealing your Desktop computer than by getting it off of Dropbox. I certainly have to revise that assessment.

The good news is that your usernames and passwords  (along with notes and attachments) are well encrypted. Even if someone gains full control of your Dropbox account they will not be able to get at the secrets encrypted in your 1Password data. We have also been busily working on an updated version of our data format that is even better suited for life in the cloud.

You can also manage which devices are allowed to connect to Dropbox. That is, you can instruct Dropbox to reject certain OAuth tokens and also view the the last few times each authorized device has connected.

To manage your Dropbox devices, log in to your Dropbox account with a web browser, and under your account name, go to Settings and then “My Computers”. If you suspect that an OAuth token has been stolen, you can unlink the computer or device. After that you will need to relink the computer or device to your Dropbox account using your Dropbox username and password.

Alternatives to Dropbox

Every time there is a security issue with Dropbox, people rightfully suggest that we offer alternative syncing mechanisms. At this point, there is nothing that I’m in a position to say beyond what we’ve said earlier in “Dropbox Terms“. There are developments, but nothing I am even willing to hint at just yet.

More security changes to come in 3.6.5

The changes coming in 3.6.5 are all about security and bug fixes. Please see “1Password 3.6.5 for iOS is out with PBKDF2 goodness!” for details.

Appendix: When is a passcode required for this attack?

When an iOS device is connected to a computer that it hasn’t connected to previously, the user will be prompted to enter the passcode on the iOS device. After that first connection, the computer will store some keys that will allow it to unlock the iOS device for future connections.

So once you have unlocked your iPhone for a particular computer, when you plug it in later, you do not need to unlock it for the file system on the device to bevisible to tools like iExporer. This is presumably why initial reports of this issue claimed that no device passcode was necessary to extract the files containing the OAuth tokens.

There is, unfortunately, one further complication. iTunes will automatically unlock the device for any user account on the same computer that the device has previously been unlocked on. That is, if Alice and Bob both have user accounts on the same Mac, and Alice has at one point entered the her passcode on her iPad to allow syncing, then Bob will be able to gain access to most of Alice’s iPad simply by using iTunes in his account on the Mac. What is worse is that Bob’s account on the computer can also be a guest account, and he will still have access.

All of the testing I have done has been with iTunes 10.6.1 on Mac OS X 10.7.3 (Lion). I have not tested this with iTunes on Microsoft operating systems.

What is worrisome here is that exactly the same people (co-workers, family members) who have the easiest access to your iOS devices are very likely to have some account on the same computer that you have used.

Still, passcodes do matter so please remember that a good device passcode is a good idea.

Data protection classes

As of 1Password 3.6.5 we put the OAuth information into the iOS keychain using the “ThisDeviceOnly” data protection class that will not allow the OAuth token to be copied from the device unencrypted. There is a bit of terminological muddle in that “ThisDeviceOnly” and “ProtectionComplete” mean the same thing except that the former is used with keychain items and the latter used with files. I prefer the term “non-migratable” to cover both.

The application property lists files, plists, contain app preference settings, and this plists do not have the non-migratable restriction on them; they are fully accessible once the device has been unlocked. Note that data with the non-migratable restriction  cannot be restored from an iTunes or iCloud backup to a different device. So if you replace your iPhone or iPad, you will need to re-enter your Dropbox credentials to reestablish automatic syncing.

Please join the discussion of this on our forums.

The ABCs of XRY: Not so simple passcodes

1Password Pro iconWhen talking about reports of tools that break into iPhones, it is very important to remember that the seller may be inclined to overemphasize its capabilities. It is also wise to keep in mind that the more sensational claims are the ones that tend to be picked up, and perhaps amplified, by the press. In this light, let’s talk about Micro Systemation’s XRY, a cracking/forensics tool for extracting data from iOS and Android devices.

XRY, despite its recent press attention, does not appear to represent anything new. Everything that we said in Lost iPhone? Safe passwords! still holds true. Your 1Password data remains encrypted. That is, even if an attacker gets through all of the the iOS security, including capture of the device passcode, he or she would still have to break your 1Password Master Password to get at your 1Password data.

XRY logo

News of XRY has been circulating since Andy Greenberg of Forbes drew attention to it and to Micro Systemation’s video demonstration. The demo shows discovery of an iPhone’s passcode in a matter of second. This should naturally cause concern for everyone who cares about their privacy.

But I’m going to try to sort out what the real concerns are, and what you can do to to better protect yourself.

Cracking passcodes

Elcomsoft logEven though your 1Password data remains protected, tools like XRY or Elcomsoft’s iOS forensic toolkit do represent a threat to the secrecy of other data stored on your device.  Furthermore, most people will have weaker 1Password Master Passwords on their phones than they will on their desktop systems. This means that we do need to be a bit more concerned about what happens if people steal your encrypted 1Password data from your iOS device than if they steal your encrypted 1Password data from your desktop or Dropbox. Therefore it is worth spending a bit of time talking about device passcodes and the security of your iOS device in general.

Note that when I talk about your “device passcode” I’m talking about the passcode that is used to unlock your iPhone, iPad or iPod touch in the first place (assuming you set one, of course). I am not talking about your 1Password unlock code or master password. Those are different things. The tools described are all about breaking the device passcode and what can be done once that is available.

First, these tools jailbreak the device. This allows the user to then run a brute force attack on the device passcode. That attack must be run on the phone itself because it is tied to a unique device key. You may think that running through all of the passcodes, 0000—9999 would just take a fraction of a second, and under normal circumstances you would be absolutely correct. But Apple has protected the passcode with PBKDF2, which forces each trial to perform thousands of complex computations. Although things will differ from device to device, Apple appears to have tuned things so that it takes about one quarter of a second to process a single guess.

Without having hands on experience with XRY I can’t be absolutely certain of this, but I strongly suspect that the reason that it was able to discover the passcode so quickly in the demonstration was because the passcode was “0000”. That is, “0000” may be the first passcode it tried. At four guesses per second, it would take about 40 minutes to try all possibilities, with an average break time of 20 minutes. As we’ve seen, sometimes it can hit upon the correct guess quickly, but in other cases it may take the full 40 minutes.

Not so simple passcodes

Settings screen to turn Simple Passcode OffTwenty minutes to break into your device is still too quick for many of us to be comfortable with. Fortunately it is easy to set a longer passcode on your device. Launch the Settings app and go to General > Passcode Lock. You will be asked to re-enter your passcode at this point; after all, you wouldn’t want anyone who picks up your unlocked phone to be able to fiddle with its security settings. Once you’ve done that, you will have a screen with lots of options. One is called “Simple Passcode”—switch that to “Off” (the Simple Passcode means using a simple 4-digit number). Once you switch Simple Passcode to “Off” you can have longer and more complex passcodes.

Passcode entry for all numeric codeLet’s suppose that you wanted to use a six digit passcode. It would take almost three days to attempt all one million possible six digit passcodes. The average crack time would be half that, at about 35 hours. All the while, the phone needs to be attached to the attacker’s computer. For an eight digit passcode, it would take on average about four and a half months to crack. Each additional digit multiplies the attack time by ten.

If you want to use just lowercase letters and the space key, then with a five letter passcode it would take about three weeks to guess, and for six lowercase letters it would take about a year and a half on average. Each additional letter (or space) multiplies the crack time by 27.

The table below gives some sample average crack times. Assuming that your passcode is random, I count 27 possible lowercase “letters” (26 letters, plus the spacebar) and 53 mixed case “letters” (52 letters, plus the space bar).  Although we don’t know how XRY guesses, Elcomsoft has previously advertised that when confronted with a non-simple passcode, their system will try some commonly used non-simple passwords first.

[Click for HTML version of this data table]

So what kind of passcode is right for me?

When trying to figure out what the best kind of passcode works for you, there are a couple of things to keep in mind. The first one is that for someone to launch this attack they need to be in full possession of your phone during the whole time. The attacker can’t just grab your phone briefly and then do the rest of the attack later. So you need to think realistically about how much time and effort someone would put into getting at your data.

Also remember that this is just to get at your device’s passcode. It is not about your 1Password data which is protected separately in a number of ways, including your Master Password.

You must consider how easy the passcode is for you to enter. One very convenient feature of iOS is that if your passcode is digits only, you will be presented with a numeric keypad, making it much easier and quicker to enter. Likewise, if you keep your passphrase to lowercase letters only, you don’t have to shift keyboards. The passcode that I’ve personally been using falls into the ‘months to crack’ category. Your choice may be different.

What about 1Password data?

Your 1Password data is protected by several layers, the device passcode is only one of them. iOS prevents one application from seeing the data belonging to another application on the device. This can also be a layer of defense, but it is not one which will withstand most jailbreaks.

So finally we come to your 1Password Master Password for the data on your device. This is the final layer of protection. Note that if you use a 4-digit 1Password unlock code, it is just a convenience feature to allow you to do some things within 1Password without having to enter your full Master Password; it is not intended to be a meaningful layer of security.

Put simply: you should use the longest master password on your device that you are comfortable typing regularly. If it is a real chore to type, you won’t use 1Password enough to get its security benefits. Because typing on a desktop system, an iPhone, and an iPad are very different experiences, we have set things up so that you can have a different Master Password for each. The Master Password that I use on Mac and Windows is complex enough to be entirely unusable on an iPhone. This means, however, that my Master Password on my iPhone and iPad are substantially weaker than what I use on the desktops, which brings us back to why I am concerned with overall security of iOS devices.

As we’ve often said before, security is a process, not a product. So look for further security enhancements in 1Password for iOS in the not too distant future. As usual, I don’t want to say anything more specific until this is delivered.

Other claims in reports about XRY

One the the most frightening paragraphs from the Forbes article on the XRY demo reads:

As the video shows, […] XRY can quickly crack an iOS or Android phone’s passcode, dump its data to a PC, decrypt it, and display information like the user’s GPS location, files, call logs, contacts, messages, even a log of its keystrokes.

While it is true that the demonstration video suggests that XRY can do most of that, I am far from convinced that it it actually exhibits those capabilities, at least not as stated in those words.

I have no hands-on experience with XRY or any information that isn’t publicly listed on the Micro Systemation website, so my comments here are necessarily speculative.

“Quickly crack passcodes”

As discussed above, there is absolutely no indication from the video that XRY can do much better than four guesses per second when cracking passcodes. It would be a truly major break(through) if they either found a way to defeat PBKDF2 (in which case it wouldn’t just be phones that they could go after) or discovered a way to perform these passcode trials off-line. Such breakthroughs would be widely trumpeted, and they would have been able to perform a very different demonstration. The fact that their target passcode was “0000” only reinforces my view that there is no breakthrough.

Note that they might be able to get a slightly better crack rate on an iPhone 4, running iOS 4. But iOS 5 contains mechanisms to set the PBKDF2 iterations appropriately for the hardware it is running on. It’s worth noting that they used iOS 4 on an iPhone 4 in their demonstration.

“Display user’s GPS location”

In the video we are told that they found some “google maps data”. Whether or not this is a place that the phone has been is left entirely unclear.  Because there were only a couple of such data items listed, I am skeptical that it does represent actual phone locations. There also was a bit of a kerfuffle about a year ago when it was believed that Apple tracks an iPhone’s location. As it turned out, that wasn’t quite what was going on. It doesn’t appear from the video that the location data they are getting is anything like what is in the location cache database.

“dump files”

The video shows the inspection of a file called “keychain-2.db”, which seems scary enough, but there is no reason to believe that data within that file can be decrypted.  However, with a sufficiently jailbroken device with the passcode in hand, it is plausible that the information in there can be decrypted. They then go on to “the log file” and show that the device passcode is in it. What may not be immediately clear is that this is log file is created from their own password cracking process.

The log file that is being read there was actually created by XRY itself. There will, of course, be sensitive data (such as contact information) available to them after a cracking the passcode, but the demonstration does not illustrate those examples.

“logs of its keystrokes”

I am not certain where the impression of a keystroke logger comes from. I saw no implication of that from the video. Perhaps it is the discovery of a swipe pattern on the Android 2.3.3 (Gingerbread) system that was shown. Note that there have been two major releases of Android (Honeycomb and Ice Cream Sandwich) since the version used in the demonstration.

A large grain of salt

I am not in any way disputing that tools like XRY and the Elcomsoft toolkit can be useful for law enforcement. And I am certainly not suggesting that these shouldn’t be worrying to anyone concerned about their data and privacy. My point is simply that sensational claims about security issues need to be examined carefully. The more we examine some of the claims about XRY, the less frightening they become.

In sum

This was a long article, so I’d like to highlight a few main points

  1. Press reports based on marketing videos are not the most reliable way to to understand security threats.
  2. XRY, in particular, illustrates no threat that we haven’t addressed before. In particular, your 1Password data on your phone is encrypted and protected by your 1Password master password even if your phone becomes entirely compromised.
  3. It is probably time to move beyond simple 4-digit pass codes for your iOS device. If you use a longer sequences of digits, it will still be quick and easy to enter.
  4. For advice on what to do if your iThingy gets stolen, please see an earlier post that includes such advice.

By adopting reasonable security practices, such as using 1Password and moving beyond a 4-digit device passcode, we can enjoy on the benefits of our mobile devices without having to live in fear of what happens to our data if someone gets a hold of the device.

Update: Micro Systemation have removed their demonstration video from YouTube. Also someone more familiar with the jailbreaking technology has reported on this and points out that the tools at XRY uses do not work with the iPhone 4S, the iPad 2, or the new iPad. It also confirms my view of the password cracking time.

Strong Security Requires Strong Passwords

Elcomsoft just published a very informative review of the state of the mobile password manager landscape. They investigated the defences applications provide and how long it would take to discover someone’s Master Password. In their findings, they found that if on iPhone or iPad your 1Password Master Password contained only numbers and was 12 digits long, then it could be found in one day, assuming the attacker got ahold of your device or a copy of your data file.

Note that this discovery time is for passwords that only use digits. As Dmitry and Andrey pointed out, this would be equivalent to a 6 character password (lowercase and uppercase characters, digits, as well as symbols):

To quickly convert this value to a comparable length of a password composed of random ASCII characters one can simply divide the former number by two (since number of ASCII characters is 95 ≈ 102).

The main reason the password can be determined so quickly is because 6 characters provide relatively few possible password combinations. To put this into perspective, here’s how the password length affects the discovery time:

Password Length Possible Combinations Discovery Time
6 956 1 day
7 957 3 months
8 958 24 years
9 959 2,348 years
10 9510 223, 152 years
11 9511 21, 199 centuries
12 9512 20 million centuries
13 9513 2 bln centuries
(42 times the age of the earth)

The discovery times are extrapolated from the numbers provided by Dmitry and Andrey in Table 2: Password recovery speeds and recoverable password lengths.

As you can see, it would take quite a while to discover a ten character password. Personally, I use a 13 character password as I have a lot of very sensitive data within 1Password and I want to ensure it remains safe, even if my iPhone was lost. It would take an attacker a very long time to iterate through all the possible combinations, and that is why the discovery time is so inconceivably huge.

With that said, as Dmitry and Andrey point out, 1Password could do more to slow the password discovery process, thereby making it take even longer. For example, on the desktop (both Windows and Mac), 1Password uses PBKDF2 to significantly slow down attackers. Currently this is not available on iOS as we needed to support older devices. The next major release of 1Password will only support iOS 5 and at that time we will be incorporating these additional defences.

You may be wondering why we think strengthening is required; after all, even a 10 character password would require hundreds of thousands of years to crack. The reason is 3 fold:

  1. Some users are using shorter passwords and we want to provide them as much protection as possible.
  2. All these numbers are based on the same hardware described by Dmitry and Andrey. Depending on the attacker’s resources, more powerful machines could be available.
  3. As time goes on, machines will continue to get faster.

To help guard against faster hardware and to strengthen shorter passwords, we are planning to update 1Password’s defences with several significant changes:

  1. 1Password 4 for iPhone will no longer allow items to be protected by just the PIN code. The PIN code was meant for less sensitive items and we always expected the Master Password protection to be enabled on important items. To simplify things, all items will be protected with the Master Password, just like on iPad, Mac, and Windows.
  2. In 1Password 4, we will be switching from 128 bit AES encryption keys to 256 bit.
  3. In 1Password 3 for iPad and iPhone, the password verification process will be significantly slowed down. Specifically, PBKDF2 will be added to iOS to match the Desktop versions. We will also remove the PKCS#7 padding mentioned by Dmitry and Andrey so attackers will be forced to perform two AES decryptions instead of just one.

Updates for 1Password 3 will be submitted to Apple within the next few weeks. Work on 1Password 4 is ongoing and it will be published later this year.

In sum, it is great that Elcomsoft took the time to analyse mobile password managers and draw attention to how critical password length is when protecting your data, and at how easy it is to “pick” a 4 digit PIN code. It’s important that everyone knows this.

What you can do today to ensure your data is protected is the same thing we have recommended all this time: use a Master Password on iPhone and iPad that is long enough to provide adequate protection for your needs. You can refer to the table above to determine the length of password that makes you feel most comfortable. Also, on iPhone, be sure to go through your items and ensure you have enabled Master Password protection.

For tips on how to pick or update to a good, strong Master Password, see our blog posts like Towards Better Master Passwords and its accompanying Geek Edition.

Lastly, all of the calculations assume the attacker has full access to your data. To protect against this, secure your iOS device with a passcode and if you are still backing up with iTunes, be sure to encrypt your backups.

Stop me if you’ve heard this password before

It seems that “Password1” is the number 1 password on business systems. (Source Trustwave’s 2012 Global Security Report.) Of course if people used 1Password (the application, not as a password) they wouldn’t be stuck having to remember passwords.

The reason, according to the report, that “Password1” is so popular within businesses is that it meets the requirements on a typical corporate network. It is at least eight characters, it contains a capital, and it has something that isn’t a letter.

Here are some other things we’ve heard around the net about trying to meet similar requirements. Let’s hope they aren’t true:

My password has at least eight characters in it: “Snow White and the Seven Dwarves”

Or:

I always mention London or Paris in mine. That way it will have a capital.

And to get helpful reminders if you forget your password:

My password is “incorrect”. This way, if I type it in wrong the systems tells me what it is.

We fear that not all of the instances of the following conversation are tongue in cheek:

“I use 1Password.” “So do I. I use the same one everywhere.”

Of course all of you reading this know better. You use the Strong Password Generator in 1Password to get strong and unique passwords for each site and service.

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.

Staying ahead with security

We just released 1Password 3.8.11, and this seemingly minor update packs some important security changes under the hood. I’d love to share those with you all.

For a quick review, recall that keeping 1Password secure is a process, and one which requires we at AgileBits keep our eyes on the horizon for potential threats to your security. We want 1Password to be as secure in the future as it has been up to now, so read on about some of  the key changes we’re making.

Also remember that 1Password 3.8.11 for Mac from our website and 3.9.2 from the Mac App Store are both our latest versions for the Mac. Their version numbers are different for now mostly to help us keep them straight.

Increased and more flexible PBKDF2 iterations

PBKDF2 is a trick we use with 1Password to make it much harder for automated password guessing systems to crack your password if they get hold of your encrypted 1Password data file.PBKDF2 diagram Without PBKDF2, automated password guessing systems could guess hundreds of thousands, even millions, of passwords per second. PBKDF2 slows down the processing of your Master Password. There is no way to check a possible password without going through many cycles, called “iterations.”

This means that if you have a good master password along with our use of PBKDF2, your encrypted data is safe even if the bad guys get hold of your data file. If you want to learn more about PBKDF2, check out our previous overview on the topic: Defending Against Crackers: Peanut Butter Keeps Dogs Friendly, Too.

We were ahead of the game when we used PBKDF2 in the design of the current 1Password data file format more than three years ago. But we aren’t going to rest on our laurels. We have been phasing in an increase in the number of PBKDF2 iterations used from 1000 to 10000 or even more. Going from 1000 to 10000 iterations means that a cracker has to do ten times as much work to try a particular guess.

1Password 3.9, the Mac App Store version, can make use of a cool Lion-only feature that automatically calculates the optimal number of PBKDF2 iterations for use on your computer. When you first create a 1Password data file using 1Password 3.9, it will call the CCCalibratePBKDF function that is part of Apple’s new CommonCrypto framework. This will calculate how many PBKDF2 iterations are needed to force, say, a 500 millisecond delay on your machine. We then use this when creating the new data file. We do put an upper limit on these, because the files you create on your super powerful Mac Pro will still need to be used on other potentially less powerful devices that you sync your 1Password data file with.

1Password 3.8 needs to run on Snow Leopard as well as on Lion, so it doesn’t use the same mechanism as the MAS version. But in 1Password 3.8.11 we have set things so that a newly created data file will now use 10000 iterations instead of 1000.

These new settings apply only to newly created 1Password data files. You will have to be patient before we can provide a rock solid way of upgrading an existing data file. We need to make absolutely sure that no matter what may go wrong during a data file upgrade, you will not lose any data, and that testing simply takes time.

Groundwork laid long ago

We have been anticipating this increase in PBKDF2 iterations for a while. One thing that we need to make sure of is that every version of 1Password you may sync your data with will be able to cope with increased iterations. Otherwise, a 1Password data file created with, say, 1Password 3.9 couldn’t be unlocked on other systems, but we’ve had the infrastructure for this change in place for more than a year.

This means that new 1Password data files will also work with current versions of 1Password on iOS, Windows, and Android. It also means that those using 1Password 3.6 on Leopard or Snow Leopard will have no problem unlocking data files created using our latest version. Users of 1Password version 2 (are there any still out there?) will still be able to work with 1Password data files that have already been created, but will encounter problems using a data file that was created with the very latest systems.

HTML export and Login Bookmarklet are on their way out

It’s time to say good-bye to a couple of features that won’t stand up to the anticipated threat environment. One feature, loved by many, is the Login Bookmarklet. This was originally designed as a way to get some 1Password functionality into browsers we didn’t support at the time. Before we had 1Password for iOS, this could be used to kinda-sorta get 1Password data into browsers that didn’t support 1Password directly.

The data in the 1Password Bookmarklet is very well encrypted, but the password for it is not secured using PBKDF2. This means that if the Bookmarklet were to be captured it would need a very strong password on it to resist attack. Because the Login Bookmarklet lives in the browser’s bookmarks, there are more opportunities for it to be captured. Given these two issues, it is time to phase the bookmarklet out. Existing bookmarklets, already in the browser, will continue to work if users decide to keep them. But from this point onward, you will not be able to create new ones.

The story is similar for 1Password’s Encrypted HTML export feature. The passwords for those HTML files are also not protected by the PBKDF2 technique. But the good news is that our much-loved 1PasswordAnywhere feature will continue to work. 1PasswordAnywhere actually uses the same data file as the 1Password application itself, so there are no worries about its data format.

The Login Bookmarklet and Encrypted HTML export features were meant as temporary measures until something better could be put in place. 1PasswordAnywhere, 1Password for non-Mac platforms, and our 1Password extension for Google Chrome are those better ways of doing things.

Password strength indications

The last change I want to talk about is a perfect example of security in one area conflicting with security in another. The fact that you can list and sort your Logins by password strength means that you can easily see which of your passwords need to be updated. This is a very good thing for your security, but as we’ve described before, the information by which you can sort data is not encrypted in the current data format.

The security concern here is that if someone captured your 1Password data file, they wouldn’t be able to break its encryption but they could learn that you had a weak password for www.example.com. If they can also guess your username, they could try weak passwords logging into www.example.com. Fortunately, the real threat is far smaller because almost every website limits login attempts. But more importantly, we have been aware of this security trade-off since we designed the current format.

What we have been waiting for to resolve this trade-off is more powerful computers and cleverer programing techniques. Now that we have both, we’re implementing a new approach: starting with 1Password version 3.8.11 on Mac and 1.0.9.BETA-238 on Windows, password strength is not stored in the data at all, but is recalculated by 1Password as needed.

If you sync your data across different versions of 1Password, you may see some oddnesses where you would expect password strength to show up until those versions fully catch up with 3.8.11. That is, 1Password 3.9.2 from the Mac App Store (at the moment) will incorrectly treat the lack of a strength indicator as a lack of strength. So please have some patience with potentially misleading strength indications on versions that haven’t yet caught up to 1Password 3.8.11 with this.

Repeating myself

We’ve always known that security is a dynamic process and that we would need make these changes at some point. We remain vigilant about changes in computing and the threat environment so that you can rest assured that your data is safe.

Steamed up and ready to change passwords

Steam logo
The details are still vague, but it appears that the encrypted passwords of 35 million Steam users have been captured by bad guys. Note that there were two breaches. One was of Steam forums, the other is of their main user database. I am just discussing the later here as it involves many more users.

The passwords in the captured database were “hashed and salted”, which means that if you were using a strong password (say one generated by 1Password’s Strong Password Generator) you should be unaffected. Also if your password there was only used for Valve Corporation’s Steam game platform, then you don’t need to change it on other sites. Valve has not released details about exactly how the passwords are salted and hashed, so we should assume that weak passwords there are still vulnerable to crackers.

Tips for checking for duplicate and weak passwords

It’s really really important to have strong and unique passwords. So we’ve written about those before. You can read more about finding duplicates in 1Password for Mac and finding them using 1Password for Windows.

But for the very short version, on 1Password for Windows, you can sort your passwords by strength.

and in 1Password on the Mac you can search for specific passwords, which can help you find duplicates.

“Hashed and salted”

Websites should store your passwords in an encrypted format, typically using a “hash” function. The crucial characteristic of a hash algorithm is that it is unfeasible to calculate the original password (or other data) from the hash. For example, if we take the string “My voice is my passport, verify me” and run that through the (outdated) MD5 hashing algorithm, we get “7be5e25ce0fe807127c694c9bcb0008b”. If you have no prior reason to suspect what the password is, there, is no feasible way of computing this backwards.

Now suppose that someone has used the most common password out there, “123456”. The MD5 hash of that is “e10adc3949ba59abbe56e057f20f883e”. Couldn’t the bad guys just compute the hashes of some common passwords and then look for those hashes in the database? A quick scan of the database for “e10adc3949ba59abbe56e057f20f883e” should get you all of users who have “123456” as their password.

This is where salting comes in. Systems add a random something, called “salt”, to the password before hashing it. So if the random salt for a particular user is “4c8x” then what would get hashed would be “4c8x123456” and then what gets stored is both the salt and the hash of the salted password. Maybe something like “4c8x+70914eddcc1e5ad56f18076f7d2433cf”. The salt isn’t secret, but because it will be different for each user, the attacker can’t simply pre-compute the hashes for common passwords. It also means that if two users have the same passwords, the hashes will be different.

Salting passwords pretty much essential. Any site that isn’t salting passwords before hashing isn’t, well, worth their salt. Databases of this sort do get stolen, and the designers of these systems need to take that into account. It’s nice to know that Steam didn’t make the same mistakes as Sony.

For higher security passwords and for things that attackers have easier access to, salting isn’t enough. For those cases (like your 1Password Master Password) a cracker thwarting key derivation function is needed. I’ve written about our use PBKDF2 for those who would like to understand what we do to protect your master password.

Facebook and CAPS-LOCK: Unexpectedly Secure

Facebook SecurityIt has recently been noted over at ZDnet that if your Facebook password is PattyAndMolly, Facebook will also accept pATTYaNDmOLLY as a valid password. This may initially seems look something that weakens users’ security. However it actually is a good thing.

Facebook designed their system this way to help people log in even if they have their Caps-Lock key on (or had it on when they created their passwords for Facebook). The Caps-Lock problem is remarkably common, and it’s not at all surprising that this is at the top of our list of things to check in our “I forgot my master password” document.

My over all point in this post (which I probably repeat too much) is that some times our intuitions about security run counter to what we find when we look at things more deeply. So let’s look at this case a bit more deeply and explore how it impacts security.

How does Facebook do it?

I assume that when a user enters a password that fails, the Facebook login procedure will retry with a modified version of what the user entered. That is, Facebook it really just trying again on behalf of the user, but it is trying as if the Caps-Lock key was set differently. If you give Facebook your password as PattyAndMolly and that login fails, Facebook will immediately retry with pATTYaNDmOLLY.

Of course 1Password users will be using strong random passwords for things like Facebook instead of passwords like PattyAndMolly, but I will stick with this example to illustrate what is happening.

Lets return to what Facebook does when a user enters a password that doesn’t work. The Facebook login system will say to itself, “Hmm, the user gave me an incorrect password. Let me take what the user gave me and try again but this time pretending to press the Caps-Lock button first.”

Working with this assumption about how the Facebook login system works, we need to look at how Facebook’s policy might make things easier (or not) for an attacker. There are three cases to consider.

Off-line attacks

If someone captures Facebook’s database of encrypted passwords the attacker will be able to use his or her own system to have a go at cracking the passwords. This is called on “off-line” attack.

The database will have only one encrypted entry per user. And so a password guessing program will still need to try all of the combinations, including both PattyAndMolly and pATTYaNDmOLLY. This is because the underlying system is still only accepting one form of the password, even if the login system that a user interacts with takes a second guess.

We can see that in this case, the Caps-Lock transformation doesn’t weaken security.

On-line attacks

If an attacker must guess at various passwords over the network by connecting to Facebook’s login mechanism, then before they can try more than a handful of guesses, Facebook’s lock-out and throttling mechanism will come into play. If you enter a password incorrectly too many times, Facebook will deliberately slow down (throttle) how many login attempts you attempt in a minute. It might even refuse to process any more login attempts (lock-out) and require that you go through a different login procedure.

So unless an on-line attacker is extremely lucky, throttling or lock-out will kick in long before any gain from the system trying multiple versions of the password can benefit the attacker.

On-line, but without throttling

There is a third possibility that we need to consider. Suppose that an attacker is able to get behind the throttling and lock-out system, but still tries to guess passwords using the remainder of Facebook’s system. That is they can query Facebook’s password checking system without having to worry about throttling or lock-out. Does Facebook’s transformation of failed passwords help the attacker?

The answer, again, is “no”. This will not help the attacker. This is because for every password the attacker tries, two passwords need to be checked. This doubles the checking time. It makes no difference to an attacker if it takes one second to check each of PattyAndMolly and pATTYaNDmOLLY, or it takes two seconds to check only one of those while having Facebook perform the second check for them.

Presumably Facebook using something like PBKDF2 and trying two passwords instead of one will have the effect of doubling the PBKDF2 iterations.

Again, in this third case we find that adding in the Caps-Lock transformation does no harm.

Why is it good for security?

I think that I’ve covered why Facebook performing this kind of transformation (assuming it is implemented along the lines that I imagine) does no harm. But why is this good for security?

It certainly is a convenience for users who have mishaps with the Caps-Lock key. But the actual security gain comes reducing the number of password reset requests that Facebook needs to handle. Processing a password resets is fraught with difficulty. It often involves a secret (typically a link or a temporary code) being sent by email. The email can be intercepted or the user’s email account may be compromised.

Password reset requests really are a common way for attacking services like Facebook. So Facebook needs to check and audit those requests carefully. The fewer unnecessary password resets the easier it will be for them to spot malicious attempts.

Teaching bad habits or scaring users

There are two real downside to this policy that I see. The helpful Caps-Lock transformation can train users to be sloppy about case. That is, if users get too accustomed to things like this they may form the opinion that case doesn’t matter in passwords. I don’t see that as a big danger here, but there are other instances when training people to behave unsafely may be a very bad thing indeed.

Child illusion speed bump
One spectacular example of training people to behave unsafely is painting roads so that it appears that there is a person on them in a misguided effort to get drivers to slow down. Imagine what happens when drivers grow accustomed to these optical illusions and start adjusting their behavior.

In the case of Facebook’s treatment of Caps-Lock, we have much less to worry about. It is unlikely to affect the general behavior of many users. Still, we must always be mindful of the dangers of teaching people bad habits.

The other security downside to Facebook’s practice is that when users discover this, they tend to (incorrectly) perceive it as a weakness. Scared and panicked people make very poor security decisions in other places. This, by the way, is why we no longer use the same Caps-Lock mechanism for 1Password master passwords.

A few more notes

Facebook’s scheme is a bit more complicated than presented here. With login attempts from mobile devices they also will retry failed logins by changing whether the first letter of the password is capitalized. This is because many mobile devices will put in automatic capitalization, even where it gets in the way.

Also I should note that I have no inside information to how Facebook manages these things, and have taken some guesses about how things work. However, the kinds of designs that I’ve assumed have precedents. These aren’t wild guesses at how things work.

My main point, if you will forgive me for repeating it, is that security issues can be subtle — sometimes even counter-intuitive. We are always on the alert for ways that we can make the secure thing to do the same as the easy thing to do even if the underlying system is more complex.