Posts

I’m not sure what it’s like where you are, but it’s been HOT lately, here in Germany. Recent days have had many on the team wishing they could work in their underwear. (Spoiler alert: I believe many already do.)
And just like fine-tuning an air conditioner in the house can make the difference between melting like ice in the sunshine and constantly looking like a plucked goose, we’re using version 4.6 of 1Password for Windows to make some useful improvements and fix a few bugs, to make things extra comfy for you.

Here’s the new coolness:

1Password + Yandex = best pals

The 1Password extension now works nicely in the privacy-focused Yandex browser. To install it, simply visit our browser extensions page in Yandex. Yandex will identify itself as Google Chrome (it’s based on the Chromium project) and from there you can install the extension like you usually would in Google Chrome.

Usernames column in the Logins category

You asked for it, we’ve listened. Now you can have a username column in the Logins category. To enable it, select View > Columns > Show Username in Logins in the menu bar.

Reordering Favorites

Don’t like the order of your favorites? Now you can reorder them by right-clicking the item you want to move up or down and selecting the appropriate menu option.

New custom field type: Phone

Once you add a custom phone field to an item, clicking the phone number will allow you to dial it with your favorite VoIP application or hand off the call to your smartphone by using a remote phone app for Android or Windows Phone.

More cool stuff…

The reliability of 1Click Bookmarks in Internet Explorer has been vastly improved.

The date picker in all categories now includes month digits next to the month name.

When you start using 1Password, creating a strong Master Password is the first and most important thing you’ll do. We all know that the Master Password is the sentry that protects your data, so choosing a super-secure password is the key to starting your journey towards better security. After all, this will be the ‘one password’ that you have to remember from now on, so you want to make it a good one! Our Chief Defender Against the Dark Arts has written an awesome blog post to help you through this important step, but there’s a lot of information in there and it can be a little bit overwhelming.

One of our goals with 1Password is to make security convenient. We’ve thought long and hard about how to make the process of choosing this important password simpler and more friendly for our new users.

Could we make the password creation process fun, and maybe even danceable? Why not?

We called on our friend, Jonathan Mann, to help us teach everyone how to create a strong Master Password. It turns out, his method involves a lot less reading.

We’ve been humming this song for weeks now, and I’m so glad we can finally share it with you! I’m pretty sure my favourite scene is the 35 bats, but I’d love to know which one makes you smile the most.

There are a lot of technical terms that mean something very specific to cryptographers but often mean something else to everyone else, including security professionals. Years ago I wrote about what it means to say that a cipher is “broken”. Today’s word is “infeasible”.

The news that sparked this lesson is the use of “computationally infeasible” in an announcement by Slack. Slack has announced that their hashed password database had been compromised, and their message was excellent: They clearly described what was available to attackers (usernames, email address, hashed passwords, and possibly phone numbers and contact information users may have added); they offered clear and useful instructions on what users should do (change passwords, enable two-step verification), and described what they have done and what they will be doing. And – most relevant for the technical discussion here – they have told us how the passwords were hashed.

In this case they said:

Slack’s hashing function is bcrypt with a randomly generated salt per-password which makes it computationally infeasible that your password could be recreated from the hashed form.

It is terrific that they chose to use bcyrpt for password hashing. bcrypt is among the three password hashing schemes that we recommend for sites and services that must store hashed passwords. The other two are PBKDF2 and scrypt. But Slack’s use of the term “computationally infeasible” here illustrates that one must be very careful when using cryptographic technical terms.

One way hashing

When services that you log into store your password they should never store those as unencrypted “plaintext”. If they are stored as plaintext it means that anyone who can get their hands on that data file can learn everyone’s passwords. For example, Molly (one of my dogs) uses the same password on Poop Deck as she does on Barkbook. So if Patty (my other dog) learns Molly’s Poop Deck password, she can use it to break into Molly’s Barkbook account as well. This is why it is important not to reuse passwords.

Now suppose that Molly uses the password “rabbit” on Barkbook. (Have I mentioned that Molly is not the smartest dog in the pack?) Barkbook shouldn’t store just “rabbit”, but instead should store a one way hash of rabbit. A cryptographic hash function will transform something like “rabbit” into something like “bQ67vc4yR024FB0j0sAb2WKNbl8=” (base64 encoded).

One of the features of a cryptographic hash function is that it should be quick and easy to compute the hash from the original, but that it should be infeasible to perform the computation in the other direction. That is it should be pretty much impossible to go from “bQ67vc4yR024FB0j0sAb2WKNbl8=” back to “rabbit”. And it is.

Guessing versus reversing

With any halfway decent cryptographic hash function is it infeasible to compute the original from its hash if the original is chosen at random! But if you can make some reasonable guesses about the original then you can use the hash to check your guesses. Because passwords created by humans are not chosen at random, then it does become computationally feasible (and often quite practical) to discover the original based on the hash.

The actual formal definition of “one-way” for a cryptographic hash function, H(x), includes the requirement that x be the output of a uniformly distributed sampling of the domain of H. That is, considering all of the things that you can hash (under some set length), you need to pick something at random. Otherwise a hash function might be invertible. Human created passwords do not meet that requirement and so the “computational infeasibility” of inverting a one way function isn’t applicable when its input is not chosen at random.

So now let’s correct Slack’s statement:

Slack’s hashing function is bcrypt with a randomly generated salt per-password which makes it computationally infeasible that a randomly created password could be recreated from the hashed form.

Modified Slack statement.

This, of course, is why you should use 1Password’s Strong Password Generator for creating your passwords. When your password is chosen randomly with a large set of possibilities, then it really is computationally infeasible to discover the password from the cryptographic hash.

Slowing down guessing

I mentioned that (for now) bcrypt, scrypt, and PBKDF2 are good choices for password hashing. Once the final results are in from the Password Hashing Competition and the dust has settled, we will probably have a good successor to those three. These are built upon cryptographic hash functions, but are designed for hashing specifically for when their input is not selected randomly.

Because cryptographic hashing is something that we have computers do a lot of, one of the things that we want is that it be fast. We want to be able to perform lots and lots of SHA-256 hashes per second without straining a computer’s memory. But if an attacker is going to be guessing passwords to see if they produce the right hash, we want to slow down the hashing. PBKDF2, scrypt, and bcrypt are all designed to require much more computation than a regular hash function to compute a hash. This can slow down an attacker from performing millions of computations per second to just thousands. The actual speed depends on many things, including the hardware that the attacker brings to bear on the system. scrypt, additionally, places specific demands on memory.

So the use of bcrypt means that attackers will need to do more work than they otherwise would to guess passwords stolen from Slack. That is a good thing, but it is not an “infeasible” amount of work.

What’s infeasible?

I started out by saying that I was going to talk about the word “infeasible”, but so far I have just been using it a lot. This is because its definition is abstract, subtle, and hard. I am not going to give a full definition, but I am going to try to get reasonably close. The discussion that follows is inherently technical, and nobody will blame you if instead of reading further you just wish to watch us pour ice water over ourselves. (Remember, that was a thing just last year.)

Welcome back to this article. It get’s progressively more arcane from this point onward.

The notion of infeasible depends on the relationship between the amount of work the defender has to do to secure the system compared to the amount of work that the attacker has to do to break it. A bank vault may take a minute to unlock if you know the combination, but it may take days to break through if you don’t. With cryptographic systems it can take just a fraction of a second to decrypt data if you have a key, but many times the age of the universe to do so if you don’t have the key.

Security parameters

What we want is the amount of work the attacker has to do to be vastly disproportionate to the work that the defender must do. It turns out that this can be stated mathematically, but first we need to introduce the notion of “security parameter” if we want our definition to stand the test of time instead of depending on the speed and power of current computers. So we will talk about how much work the defender and the attacker have to do in proportion to some security parameter.

Let’s pick, for purposes of exposition, an encryption system that operates at a security parameter of 56. The amount of computation that the the defender has to do to decrypt some data with the key is proportional to 56, but the amount of work that the attacker has to do to decrypt the data without the key is proportional to 2⁵⁶. Fifty-six is much much smaller than 2 raised to the 56th power, but today even 2⁵⁶ operations is within the reach of many attackers. Thirty years ago it was within the reach of just a few.

So now let’s suppose that we want to double this security parameter to 112. How much of a work increase might this cause the defender? You might be thinking that it doubles the cost to the defender, but the system I’m thinking of actually tripled the cost to the defender. Tripling the cost for double the security parameter may not seem like a good deal, but doubling the security parameter increased the work of the attacker by another 2⁵⁶, for a total of 2¹¹². This puts it well outside the reach of even the most resourceful attacker for a long time to come.

When we doubled the security parameter in that example, the work to the defender increased linearly while the work to the attacker increased exponentially. We want the work required of the attacker to increase exponentially with the security parameter while for the defender we increase it linearly or polynomially.

Doing time, time, time in an exponential rhyme

If the security parameter is n, we will tolerate it if the amount of work the defender must do is proportional to na for any a > 1. That’s what we mean when we say the work is “polynomial in n“. So if the work goes up with the square or cube of n we might grumble and seek more practical systems, but no matter how big the power that n is raised to gets, this is still a polynomial expression. An algorithm that works this way is called a “polynomial time algorithm”.

For the attacker we want the number of computations needed to be proptional to an expression in which n is in the exponent. So if the work to the attacker is proportional to bⁿ for any b > 1, so that the work is exponential in n. (Those of you who know this stuff, know that I’m leaving some things out and am taking some shortcuts.)

It might seem that a “big” polynomial get us bigger numbers than a “small” exponential, but no matter how much a polynomial function starts out ahead of an exponential, the exponential will always catch up. Let’s compare the exponential y=1.1ˣ with the polynomial y=x⁶ + 2. For values of x below a few hundred, it looks like the polynomial is the runaway winner.But we inevitably reach a point where the exponential function catches up. For the particularly examples I’ve given, the exponential catches up with the polynomial when x is about 372.73.

Finally, if we go just a bit beyond the point where the exponential overtakes the polynomial, we see that the exponential completely flattens the polynomial.

Some computations will take a number of steps that are polynomial in n (“polynomial time algorithms”), and others will be exponential (“exponential time algorithms”). We say that a task is infeasible if there is no polynomial time algorithm to complete it with a non-negligible chance of success. I have not defined what a non-negligible chance of success is, but as the article appears to be growing in length exponentially, I will leave that discussion for our forums.

When we have this sort of asymmetry, where the work done by the attacker grows exponentially with the security parameter, but grows at most polynomially for the defender, there will always be some security factor beyond which the work to be done by the attacker is so enormously larger than what the defender must do as to just not be an option for any attacker.

Quibbling over terminology

Now that we have a workable definition of “infeasible” and a better understanding of what cryptographic hash functions do, we can take a closer look at Slack’s statement. First let me repeat that their overall statement was excellent, and I fully sympathize with the difficulty involved in writing something about security that is correct, clear, and usable. I’ve taken some shortcuts in my exposition on any number of occasions, and I’ve made my share of errors as well. My point here is not to criticize but instead to use this as an opportunity to explain.

Given what we believe about cryptographic hash functions it is infeasible to discover x if you are only given the hash of x but only if x is chosen at random. Furthermore this is true of any (decent) cryptographic hash function and is not limited to the slow functions that are recommended for password hashing. That is, we don’t need bcrypt or PBKDF2 for that property to hold.

The limits of slow hashes

Slow hashes – specifically designed for password hashing – are built because we know that passwords are not chosen at random and so are subject to guessing attacks. But slow hashes have their limits, and with the notions that have been introduced above, we can now talk about them more clearly. Using a slow hash like PBKDF2 slows things down for both the attacker and for the defender. And the amount of slow-down is roughly the same for both the attacker and for the defender.

If we increase the security parameter (number of iterations) for PBKDF2 the computational cost rises linearly for both the attacker and for the defender. This is unlike the security parameters we use elsewhere in cryptography, where we would like a small (linear or perhaps polynomial) increase in cost to the defender to create a large (exponential) increase for the attacker.

Let’s see how that works out with a concrete, if hypothetical, example. Suppose it is using 40,000 PBKDF2 iterations. Now suppose that you add a really randomly chosen digit to the end of your Master Password. Adding a single random digit will make an attacker do 10 times the amount of work that they would have to do to crack the original password. Adding two digits would make the attacker have to do 100 times the work of the original. Making a password just a little bit longer (with random stuff) makes the work required by the attacker increase exponentially. That is the kind of proportion of work that we like.

Now suppose 1Password uses 40,000 PBKDF2 iterations in deriving your Master Password. To get the same additional work as adding a single digit to your password, you would need to increase the number of PBKDF2 iterations to 400,000. And to get the equivalent of adding two digits, you would need to increase the number of iterations to 4,000,000. Once we have a goodly amount of PBKDF2 iterations, there isn’t that much gained by increasing it by an additional ten or twenty thousand. But there is much to be gained by even a small improvement in a Master Password.

PBKDF2 is terrific, and it is an important part of the defense that 1Password offers if an attacker gets a hold of your encrypted data. But you must still pick a good Master Password because the security parameter is linear for both the defender and the attacker. Unless there is a breakthrough in the slow hashing competition, a strong Master Password will always be required in order to ensure your security can withstand the test of time.

To learn how to have 1Password help you manage your TOTP Logins, go straight to our user guide. If you would like to better understand when and why TOTP is useful for 1Password users, and what to do if you truly want two-factor security, continue reading here.

I’ve previously written (at excessive length, in some cases) about TOTP in general, but in each instance pointed out that it is of limited utility to 1Password users. This is because such schemes are of most use to those people who have weak or reused passwords. If you are using a strong and unique password for a site, then many of the gains of two-step (or multi-step) verification are not relevant for you.

But “most” is not the same as “all”. There still are some cases where multi-step verification is useful to people using 1Password.

Sometimes you must use TOTP

Sometimes a site or service will simply require that TOTP always be used along with your regular password. Patty (one of my dogs) is working with a research group analyzing the structure of heart worm DNA. When she connects to the lab’s server, she is required to use TOTP.

TOTP example in 1Password for Windows

She has set up an app on her laptop that just constantly displays the current TOTP code. It’s sitting there ticking away all the time her laptop is running. Ideally, it should only be visible when she actually needs it, but she is understandably just trying to save time. Clearly, she could use TOTP more securely if it were available for the Login item within 1Password.

One-timeness? Yes

One-time passwords (the “OTP” in “TOTP”) are useful over insecure networks. Normally, when you submit a password to a site or service, you send the same password each time. Ideally, that connection is well encrypted so that the password cannot be captured when it is in transit. This is why it is very important to:

use HTTPS instead of HTTP when doing anything sensitive

pay attention to the lock icon in your browser’s address field (indicating HTTPS)

heed browser warnings about such connections

But networks are easy to compromise. Recently Molly (my other dog) was at the Barkville Airport. When she connected to Wifi, she saw several open wifi IDs. One was BVT-access, and the other one was “Airport Free Wifi”. As it turned out, BVT-access was the legitimate one, but she connected to Airport Free Wifi. Airport Free Wifi was actually a laptop operated by Mr Talk, our neighbor’s cat.

Mr Talk is using SSL-strip on his rogue wifi hotspot. If Molly isn’t paying close attention to the HTTPS status of her browser’s connection, she can send things unencrypted over Mr Talk’s network while thinking it is a secure connection. I should probably point out that Molly lacks the discipline to pay close attention to anything other than a squirrel or rabbit. This way, Mr Talk can capture Molly’s passwords in transit to the servers and save them for later use.

That is one of several ways that passwords can be captured in transit. The point of one-time passwords is that they are not reusable even if they are captured in transit. In this way, TOTP provides a meaningful defense against plausible attacks even though there is nothing “second factor” about how it is being used.

Second factor? No

We need to make the distinction between one time passwords and second factor security. One time passwords are often part of second factor security systems, but using one time passwords doesn’t automatically give you second factor security. Indeed, when you store your TOTP secret in the same place that you keep your password for a site, you do not have second factor security.

However, you still have the benefits of the one-timeness of TOTP codes.

Systems like TOTP are sometimes used as part of second (or multi) factor authentication systems. But this is far from their only usage. To be truly second factor, the TOTP secret (from which the one time password is generated) must not be stored on the same device that you use the regular password on.

Let’s consider an example. Molly has a Tumblr where she posts pictures of the squirrels she is after. So far, she has been using the Authy app on her phone to manage TOTP. If she never logs into to Tumblr on the same phone, then she is using her phone as a second factor. But if she is also using Tumblr from her phone and has had to use her one time password from there, then there is no second factor.

In general, there is a reason why many services that offer TOTP refer to it as “two-step verification” instead of as “second factor authentication”. The security that such sites seek to gain from this is not in the second-factorness; it is in the one-timeness. In particular, many of the sites and services that offer or require two-step verification with one time passwords are doing so because many of their users have weak or reused passwords. Although that should not apply to 1Password users, there are other benefits to one time passwords as I discussed above.

If you really want true two factor

If you would like to turn a site’s offering of TOTP into true two-factor security, you should not store your TOTP secret in 1Password (or in anything that will synchronize across systems). Furthermore, you should not use the regular password for the site on the same device that holds your TOTP secret.

Put simply: the device that holds your TOTP secret should never hold your password if your aim is genuine two factor security.

Personally, I don’t think that following that practice would be worthwhile for anything but a very small number of special circumstances, in which case, you should probably be using a specialized second factor device instead of something like a phone. But not everyone shares my opinion on this, and if you have a need for true second-factor security for some particular site or service, you should take that into account before adding a TOTP secret to 1Password.

For everyone else, if you find the one-timeness of TOTP worthwhile on its own (or are required to use it), 1Password’s new support in v5.2 for iOS and v4.1.0.538 makes it easier to use than ever.

Naturally, this new-fangled way for apps to interact in iOS 8 is leading people to ask how we do this in a secure manner:

Are we really letting third-party apps poke around inside of your 1Password data?

Answer: No, that is not how extensions work.

Can these third party apps ask 1Password for your PayPal password?

Answer: Well, they can ask, but you decide if they should get what they ask for.

Can they trick you into entering your 1Password Master Password into something that isn’t 1Password?

Answer: The very same mechanisms that prevent that today apply to application extensions.

TL;DR

I will elaborate on all of this below. But to summarize, all of my points and these safeguards in both iOS extensions and 1Password are built on an important design principle: Nothing happens without your explicit action.

This bug matters for everyone

Just because 1Password’s technology isn’t affected by this doesn’t mean that you aren’t. Pretty much everyone is affected by this. Many of the secure connections that you use with various services, including HTTPS connections to secure sites for shopping and many other activities, may be fully readable to attackers. Of course, this includes the usernames and passwords that you use to log in to various services. It’s not just HTTPS connections, but IMAPS—how your email program, such as Mail.app or Outlook, talks to a mail server—may be vulnerable.

“So I need to change all my login passwords, right?”

Your 1Password data remains safe, as does your 1Password Master Password. But whether or not you use 1Password to log into an affected site or service, your username and password, along with everything else that happens over that supposedly encrypted connection, may be exposed to attackers.

You will, at some point, need to change a lot of passwords. And 1Password makes this much easier than it other would be. But don’t rush to do that just yet. Not every server is affected, and those that are need to fix things at their end before you change your password. If you change your password before the servers fix things, then your new password will also be vulnerable to capture.

All that most of us can do is wait at this point. Presumably, various service providers will announce over the next few days when and whether users should change passwords or be aware that other confidential information may have been exposed.

At this point, I can only guess at how long it will take for various service providers to make announcements. They are in a difficult position right now. First, they need to determine whether they are vulnerable. That means finding out if their particular SSL/TLS service was using OpenSSL (the most popular SSL library in use today) version 1.0.1 (Released March 2012) through 1.0.1f (1.0.1g, containing the fix, was released April 7, 2014).

Once a service upgrades to a fixed version of OpenSSL (or to some other cryptographic library), they will need to revoke the certificate that they had been using with with the vulnerable version of OpenSSL and obtain a new certificate. Exactly how long that takes will depend on how quickly they can get things sorted out with their certification authority. Certification authorities are going to be very busy over the next few weeks.

Only after a new, certified certificate is in place on a server that is not using a broken SSL/TLS library will it make sense for you to update your password for that service (or even trust your communication with it). Most of us simply have to wait until notified by various websites and services when and whether we should change passwords.

Certificates and keys

If you are curious about what is actually exposed by the heartbleed bug, read on. It requires some understanding of how certificates work, but I’ll try to give an overview of just the parts we need for this discussion. I will take a lot of shortcuts in the presentation and pretend that things are simpler than they actually are.

How certificates and keys work

In order for your browser and a web site to encrypt the communication between them, they need to use an encryption key. That key is typically a 128-bit number. Now, it may be that your browser and the particular website have never spoken to each other before, so they need to work out an encryption key for this session in such a way that someone listening in will not know what the key is. It’s as if they have to work out a password to share between them while communicating where anyone can listen.

The encryption key that they work out is just for that particular session. The next time your browser establishes a connection to that server, a new key is worked out. This is called a “session key”.

Establishing a session key

Your browser and the server work out a session key using something called “public key encryption”. Public key encryption is the nearest thing to magic you will find in mathematics and cryptography. When I describe what I do to school kids on career day, I say that I get to think like a criminal and do magic with math.

Anyway, the server will have a public key and a private key that are mathematically related. The public key is not a secret at all. The mathematically related private key is. It is possible to use the public key to encrypt stuff that can only be decrypted with knowledge of the private key.

So (and this is taking a big shortcut), your browser can pick a random session key and encrypt it using the server’s public key. Because only the server knows the corresponding private key, only the server can decrypt the encrypted session key. Once your browser has sent a randomly chosen session key to the server, both the server and browser can use that session key for their communication throughout that session.

The private key is a big, long number. Often thousands of bits long. And it can’t be just anything; it has to have the appropriate mathematical relationship to the public key. Clearly no human is going to be dealing with those keys directly. Typically, those keys are stored in a something that can be used by the server software and is protected by a password.

This scheme of using a password to protect a key and then have the key be used for the encryption is typical of high security software. You find this in SSH, PGP, and in 1Password. A strong key is picked by the software and that key is then encrypted with a password that a human uses. With 1Password, your data is encrypted with a random 256-bit key that is chosen when your data vault is created. Your Master Password is used (indirectly) to encrypt that key (again, I’m skimming over some details).

How heartbleed bleeds your privacy

Anyway, the heartbleed bug pretty much allows an attacker to probe a server that will end up revealing the private key. Once an attacker knows the private key, they can decrypt session keys that have been sent to the server, and thus decrypt all of the encrypted traffic that goes back and forth between the browser and the server.

Another bit of magic with public key encryption is the notion of “digital signature.” Your browser can create a mathematical challenge using the public key that only someone with knowledge of the private key can solve. This is part of how a website proves to a browser that it is what it says it is. If an attacker learns the private key of some website, then it can masquerade as that site.

All in all, the capture of a server’s private key is a bad thing, and that is what this bug enables.

Valsorda has also created a web page based on his testing tool, which makes it easy for people who don’t wish to install and run the command line program to see which websites (or other services) are currently vulnerable to Heartbleed. I wanted to test the IMAP (mail access) server used by Fastmail.fm (which I use for my personal mail). The name of the IMAP server is “mail.messagingengine.com” (which I happened to look up in my Email accounts category in 1Password). Because I wasn’t testing normal HTTPS, which used port 443, I also had to enter the port number for IMAPS, 993. So what I put in the form was “mail.messagingengine.com:993”. This nicely passed the test at the time I tested.

The Heartbleed test fails for Dreamhost at the time of testing

To test a website, you do not need to put in the port number. The test will default to port 443 (HTTPS). So I was able to test Dreamhost.com by just using “dreamhost.com” in the form. At the time I tested, dreamhost had not updated to the fixed version of OpenSSL, and so the test reported it as vulnerable.

Patching OpenSSL isn’t enough

It is important to remember that during the period that your site was vulnerable attackers could have captured the key for the SSL certificate. Once they have your key, they can (under most circumstances) continue to read and manipulate traffic to and from your site. So the next step is to generate a new certificate and get that signed by a Certificate Authority. This is also a good opportunity to ensure that your RSA or DSA key is at least 2048 bits long. 1024 bit RSA and DH keys are no longer considered safe.

Once you have your new certificate signed and in place, you should inform users that their sessions may have been compromised prior to the installation of the new certificate. They should then change their passwords and take whatever other action is appropriate given that confidential data may have been exposed.

Updates

The bulk of this article was drafted late Monday (April 6) night and in the wee hours of Tuesday morning. We will have a series of other articles and announcements coming soon, so please continue to watch the Agile Blog for news here and 1Password on Twitter, on Facebook, and on App.net. We will also be providing only minor updates to this post, as we prepare new ones.

April 12

A new certificate for agilebits.com was put in place on April 10 and Dropbox.com put a new certificate in place on April 11.

Now that Dropbox is using a new certificate, we’ve removed the earlier advisory for users of the 1PasswordAnywhere feature.

To understand why this is really good news for us and for 1Password users, it is important to know what “crack” means in this context. I’ll come back round to that and why we encourage the developers of hashcat, John the Ripper, and cryptohaze to take a crack at 1Password. But first, let’s talk about this news and what it says about your password security.

Cracking fast and slow

If someone gets your 1Password data, they will not be able to decrypt it without your Master Password. A determined attacker might then try to guess your Master Password. Your job is to pick a good Master Password so that it will take trillions of guesses before the attacker finds the right one. Our job is to make sure that they can’t make millions of guesses per second on common hardware, thus significantly slowing down the guessing process, ideally to the point of futility. We do our job by using a “slow hash” for deriving encryption keys from your Master Password. In 1Password 4, that slow hash is PBKDF2-HMAC-SHA512. For the Agile Keychain Format it is PBKDF2-HMAC-SHA1.

Jens Stuebe, the developer of a password hashing system called hashcat, has been testing just how many guesses per second he can get out of hashcat for the 1Password 4 data format. The hashcat demonstration showed fewer than 500 guesses per second, but with somewhat beefier hardware and a more realistic data file, a better estimate based on the hashcat data would be between 5,000 and 20,000 guesses per second. For all of the calculations below, I will use the more pessimistic (for us, the defender) estimate of 20,000 guesses per second. It’s not because I think the pessimistic estimate is the most realistic, but simply that it is better to err on the side of caution.

If you use a four word password from the scheme described in Toward Better Master Passwords, then at 20,000 guesses per second it would take more than 5,600 years for a high-end PC with with multiple graphics processing units (GPUs) to work through all of the 3.65 trillion equally possible passwords. Of course, the attacker won’t have to try all of those. On average, she will find the right one after going through about half of the possibilities. So the average time to crack will be about 2,800 years. If you use a five word password, then the average time to crack will be more than 20 million years.

We like crackers

With enough time (perhaps far more time than the life of the universe) it will always be logically possible to guess a Master Password. This is simply the nature of the beast. We need to know how many guesses an attacker can make in a second, a day, a year with the resources available to them so that we can devise the most effective defenses against these sorts of attacks.

We make our own estimates, but the best estimates come from looking at real data. We will, on occasion, run our own tests but the people who specialize in password cracking are the people who perform the most stringent tests and will look for things that we might not notice. We want to know how hard they have to work at guessing passwords. We are extremely supportive of projects like John the Ripper, hashcat, and Cryptohaze. Indeed, conversation with people involved in these projects has very much helped us develop better resistance to password cracking.

This is one of several reasons why we are open about our data format. We get better analysis from the security community by doing so. Hashcat, and John the Ripper, worked against some sample data we make available to the public.

Cracking isn’t breaking

When crackers develop tools to guess at 1Password Master Passwords, they are not “breaking” anything. They aren’t exploiting vulnerabilities. They are just automating password guessing. Because they are working directly on the data files themselves, not with the 1Password software, things like lock-outs after multiple failed guesses aren’t an option (and don’t provide any meaningful security against encryption tools like this).

The technical stuff

The 1Password 4 data format uses PBKDF2-HMAC-SHA512 with an absolute minimum of 10,000 iterations when transforming a Master Password to a decryption key. I’m not going to explain what all of that means, but I will say that PBKDF2 is a Password Based Key Derivation Function that is designed to require that there be lots of computation in getting from an entered password to a key. It is specifically designed to slow down cracking attempts.

The attacker is able to build special machines for their cracking efforts, and software carefully optimized for that hardware. Defenders like us have to be able to process a single password in an acceptable amount of time for them on the hardware in their pockets. As a consequence, the attacker can process a candidate password much more quickly than the legitimate user. @bitwiesil, the developer of Cryptohaze, describes this as an Attacker/Defender Ratio (ADR).

For example: if it takes 1/4 of a second for a user’s Master Password to be processed on their mobile device, but the attacker using specialize hardware can make 10,000 guesses per second, the ADR would be 2,500. In a perfect world, the ADR should be 1:1, but that is never going to happen. Plus, ADR in the tens of thousands, instead of in the millions or billions, is a hard but more realistic goal.

The limits of PBKDF2

PBKDF2 isn’t perfect. Most importantly, it can only go so far. We can reach a point where even tiny improvements to a password (say, just adding a digit) can offer far more additional protection than adding extra strength to PBKDF2. For example, adding a single random digit to the end of a password will offer as much as going from 30,000 PBKDF2 iterations to 300,000. And the latter can do real harm in making legitimate decryption too slow. Increasing the number of PBKDF2 iterations does not change the Attacker/Defender ratio at all.

There are a couple of other things that PBKDF2 doesn’t do. When it uses SHA1 internally (a very common configuration), it can be optimized to run extremely quickly in GPUs, giving the attacker a high ADR. Computers built with several (or many) GPUs operating in parallel can still perform many billions of SHA1 computation per second. GPUs cannot be so easily tuned when PBKDF2 uses SHA512 instead of SHA1. Our use of SHA512 within PBKDF2 in 1Password 4 is overwhelmingly the biggest reason that we are seeing such a small Attacker Defender Ratio in the hashcat report.

There is another, more subtle issue with PBKDF2 which can allow the attacker to double the ADR in some peculiar cases. Those cases can be avoided (once people know to avoid them), and a doubling of the ADR is not a big deal. But this does show that PBKDF2 is not the slow hash we would design today.

PBKDF2 is not “memory hard”. It is designed to raise the cost in computation for both attacker and defender, but it doesn’t force a substantial demand on computer memory. If, as the case has been, that the price of computations falls faster than the price of computer memory, the attacker can affordably purchase or rent a fleet of fast processors. But, if we build a slow hash function that also requires substantial memory use, we have more flexibility in trying to reduce the ADR.

So why do we stick with PBKDF2?

For all of its warts, PBKDF2 is the best choice for 1Password today, although it may not be tomorrow. We can mitigate some of the limitations of PBKDF2 in our design, which we currently do. After all, the great results that we have from this weekend’s hashcat report show that we continue to be successful with it.

The best alternative to PBKDF2 that is reasonably well available and scrutinized is scrypt. If scrypt or similar had been further along as a standard, we probably would have used that. But because you need to unlock your 1Password data on a variety of different platforms, we need to use cryptographic functions that are included in well-tested libraries for all of those platforms.

This is why the Password Hashing Competition is so important. This is an effort to develop and agree upon a design for a successor to PBKDF2 that takes into account everything we’ve learned since it was first developed. The aim is that the successor will have enough support to become available to developers in many cryptographic tool kits. But that is a hope for the future. Right now we continue to use PBKDF2 in a way that takes its various quirks into account.

Your part of the job

Even the slowest hash with a perfect Attacker/Defender Ratio can’t protect a weak Master Password. Our job is to make sure that, when an attacker needs to guess trillions of passwords, they have to really work to do so. Your job is to pick a good Master Password so that it is trillions of passwords they need to guess instead of thousands. In our sample data that hashcat used, the password was “fred” (this was also made public). So even performing less than 500 guesses per second, hashcat was able to find the password “fred” in less than a minute.

Rumors of a Dropbox data breach spread this weekend, a breach that ultimately turned out to be false. But even in instances of false alarms, it is useful to remind 1Password users that their 1Password data cannot be decrypted without the Master Password. So let me take this opportunity to remind everyone that your 1Password data cannot be decrypted without your Master Password. If someone steals your 1Password data – whether from the theft of your own computer or through the breach of a sync service – they cannot decrypt it.

Fact checking

It is worth noting that when a perpetrator of a rumor like this self-identifies as “Operation Troll Security”, it might be worthwhile to double check their claims before jumping to conclusions or even reporting the claims further. This is particularly true if a perpetrator has a history of claiming responsibility for every notable site outage, then laughing at people who believed them. Operation Troll Security doesn’t often tell the truth, but it may be wise to heed one particular tweet:

https://twitter.com/1775Sec/status/421861679631044608

Despite the fact that the claims of a Dropbox breach were a complete hoax, it still is worthwhile to point out some things about the security of your 1Password data if it ever does fall into the wrong hands.

End-to-end encryption

1Password uses what is called “end-to-end” encryption. 1Password on your computer or mobile device encrypts your data with keys that are derived from your Master Password. Those keys are never stored anywhere or transmitted. Nobody, not even us at AgileBits, ever sees those keys or your Master Password. This is why it absolutely essential that you don’t forget your Master Password. We cannot reset it or reconstruct it. Your data can only be decrypted by you.

We designed 1Password this way from the outset because we knew that computers get stolen and services get compromised. By placing all encryption and decryption under your control, we become far less reliant on the security of any sync service.

Protecting Master Passwords

If an attacker does get hold of your 1Password data, the only feasible way for them to attempt to decrypt it would be to try to guess your Master Password. Of course, they wouldn’t sit there typing in guesses. Instead they would run automated password guessing systems against the data.

We have a long history of building mechanisms into 1Password’s data format that make it harder for attackers to guess your Master Password. When we released 1Password 2.5 in 2007 with the then new Agile Keychain data format, we added PBKDF2 so that anyone trying to run automated password guessing systems against captured 1Password data would have to perform lots of slow computation for each guess. You can read more about PBKDF2 and this aspect of our design in an older article of mine, Defending against crackers: Peanut Butter Keeps Dogs Friendly, Too. Many of the details have changed over the intervening years, but the essential concept remains the same.

Toward better Master Passwords

PBKDF2 makes it harder for those automating password guessing, but it does have limits. You need to do your part by choosing a good Master Password. Even a small improvement to a Master Password goes a long way. Adding a single truly randomly chosen digit to the end of your Master Password makes the attacker work ten times longer to guess it. Adding a truly randomly chosen word make the attacker work thousands of times longer. Adding two truly randomly chosen words makes the attacker work tens of millions of times longer.

You will note that I emphasized the phrase “truly randomly” a few times there. That part is crucial. People turn out to be very unrandom even (especially?) when they are trying to be random. If you follow our advice in Toward Better Master Passwords, you will see how you can securely pick words at random to add to a Master Password. Hint: It involves rolling dice. It’s fun!

A hoax is a hoax, of course of course

Even though the report of a Dropbox breach was a hoax, you still may ask what role Dropbox security plays in the security of your 1Password data. I hope that this article helps explain that and how using 1Password can keep your secrets safe. I look forward to further discussion in our forums.

Of all of the revelations about the NSA that began in June and continue to this day, the one that has shocked me the most is the fact that the United States National Security Agency has been deliberately inserting weaknesses into security products and even into NIST standards. In light of this, it is fit and proper for anyone who relies on 1Password for their security and privacy to ask whether 1Password has been, or could be, tampered with to deliberately weaken it.

The easy questions

Has 1Password been deliberately weakened?

No.

Have we, AgileBits, ever been asked/compelled/pressured/contacted by any entity asking us to weaken 1Password?

No.

Could we be compelled to weaken 1Password or allow for the weakening of 1Password?

Not without substantial risk that such attempt would become public.

Those questions are the easy ones to answer. The harder question is why you should believe those answers.

Why should you believe us

It is impossible to absolutely prove that our answers to the easy questions above are truthful. But what I can do is provide a number of more verifiable claims, each of which makes it harder for us to lie about any of this. In combination, these should be enough to persuade you that there is no backdoor (deliberate weakness) in 1Password and that it would be very unlikely for one to be introduced.

They can’t gag all of us

We have developers in four separate countries: Canada (AgileBits is a Canadian company), the United States, the United Kingdom, and the Netherlands. The gag orders that accompany National Security Letters in the US would not bind non-US citizens outside of the US. Likewise the Canadian, British, or Dutch analogues to National Security Letters wouldn’t bind US citizens. To compel all of us to betray our customers and principles, they would need to coordinate that legal compulsion in four jurisdictions.

This doesn’t entirely rule out the possibility of such a set of gag orders, but it does make such compelled silence much harder to achieve. This also doesn’t rule out other avenues of attack. In particular, could just one or two people within AgileBits sneak in a backdoor? We’ll talk about that below, but note that the inability to gag so many of us means that a backdoor would have to remain unknown to most of us.

Our lack of data collection is verifiable

Your 1Password data is under your control. Out of the box, 1Password creates a local data file (your “vault”) and sync is disabled. We never have the opportunity to see your Master Password or even your encrypted 1Password data. 1Password not only gives you “end-to-end” encryption, but our overall design means that we are never in a position to turn over or intercept your data. We simply never see it in any form whatsoever.

Furthermore, we never see how you use 1Password. We don’t know what sites you log into, we don’t know how many 1Password items you have. Indeed, we don’t even know whether you use 1Password or not. We offer a soon-to-be-incremented number of data synchronization methods, none of which involve us ever having the opportunity to intercept your data. When 1Password 4 for Mac arrives soon, Wi-Fi sync (currently in testing) will allow you to sync locally, meaning your data never has to leave your local network.

You can monitor 1Password network activity for yourself to confirm that your data, even encrypted, is never sent to us. All of this dramatically reduces where a backdoor could be inserted. Indeed, it eliminates the otherwise easiest to insert and most difficult to detect backdoors. So an entire range of attacks is already off the table.

As always, this doesn’t rule out all kinds of mischief, but it substantially limits the scope and opportunity for an attack.

This doesn’t rule out every kind of sabotage that could be done, but it does rule out a broad range of some of the easiest lines of attack. Because this limits where a weakness could be introduced, it’s harder for a deliberate weakness to be introduced that isn’t noticed by others who can access the source code.

As a consequence of this, everyone with access to the source code knows where to look for possible tampering. This makes it harder for a backdoor to be introduced without it being noticed by many of us. As pointed out above, they can’t gag us all.

Lavabit has set a precedent

One company, Lavabit, has shut itself down rather than comply with betraying their customers. This increases the risk of discovery to those trying to compel developers to introduce weaknesses.

It is impossible to predict how we would react in absence of having the full details of such compulsion in front of us; there are just too many unknowns and too many forms of compulsion. But the very real possibility that we would shut ourselves down (which would be public) rather than sabotage what we do and love should act as some deterrent to those who might wish to compel us to introduce a backdoor.

Only communications tools appear to be targeted

From the most recent revelations, the targets appear to be communication tools and protocols. 1Password is not such a tool. This doesn’t mean that the NSA couldn’t change their focus, but from what we know so far, 1Password is not the kind of thing they are after.

Going around crypto instead of through it

Even if you don’t find any of the individual reasons listed above to be persuasive, they interact powerfully. In combination, they make it much harder to get a weakness into 1Password without taking on large risks of getting caught and failing. Any attacker, including the NSA, will avoid high risk, high cost attacks if there are safer and easier alternatives. I’m therefore confident that the NSA would rather go around 1Password than through it.

Crypto Wars II

In the 1990s, there was a series of debates, pressure, civil disobedience, and cryptographic developments that have come to be known as “The Crypto Wars”. At the heart of this was the US and other governments’ efforts to prevent people from having access to cryptographic tools which those governments couldn’t break. In the end, governments (seemingly) surrendered, in large part because the tools they wished to use to enforce those restrictions (export restrictions, the Clipper Chip) just weren’t going to work.

What the 5 September, 2013 revelations show is that the US government has taken a different tack. The Crypto Wars may never have ended. Instead of explicitly and openly trying to limit the power of the cryptographic tools allowed to the public, they are now surreptitiously sabotaging the tools that we all use. As before, this will be fought on the political front—people telling their representatives that they don’t want hobbled security tools—and on the technological front—building better, stronger, more robust and verifiable systems.

Our role in this as a company is to be transparent about our approach to security while keeping your 1Password data protected.

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

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

Keeping secrets small

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

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

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

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

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

Throwing away the key

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

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

When to throw away the key

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

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

Is Auto-Lock helpful?

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

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

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

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

Auto-Lock *is* helpful

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

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

Raising the attack bar

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

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

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

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

Defending against practical attacks

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

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

Summary

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