Posts

Convenience is Security

We often hear people say that there is a trade-off between security and convenience. Although there is some truth to that, I want to explain why, more often than not, security actually requires convenience. I should warn you, though, that this is going to be one of my most boastful articles to date.

Users of 1Password will certainly have experienced for themselves that security and convenience go hand in hand. Our design goal has always been to make it easier for people to behave securely, rather than insecurely. We have customers who use 1Password only for the convenience, yet they enjoy real security benefits as a result.

We’ve made this point in several places (it’s something I often say in some of our forum discussions), but it always comes across better if I quote someone else instead of myself. So here is noted security researcher Matt Blaze commenting in Why (special agent) Johnny (still) Can’t Encrypt. He discusses a police radio system which had users frequently talking over unencrypted channels while they thought their communication was secured:

The unintended cleartext problems […] first and foremost remind us that cryptographic usability matters. All the security gained from using well-analyzed ciphers and protocols, or from careful code reviews and conservative implementation practices, is lost if users can’t reliably figure out how to turn the security features on and still get their work done.

This is not news to researchers in the field, or at least it shouldn’t be. It certainly isn’t news to us, because we’ve designed 1Password with this fundamental truth in mind from the beginning. If some security policy or mechanism becomes onerous or confusing to use, the people who it’s designed to protect will circumvent it. If people are forced to use a difficult and confusing system, they are likely to make serious mistakes. At best, a security product should make it easier to get your work done. At worst, it shouldn’t make things prohibitively difficult to complete your tasks.

If researchers have understood this concept for decades, why does the view still persist that there is a trade-off between security and convenience? I have a few theories.

1. Rules instead of reasons

Dilbert.com

Most people just want to be told that something is secure and how to use it. They aren’t all that interested in how the thing works. You, reading this article or diving into the deeper parts of our documentation, are an exception. I have a pathological desire to explain things, and I love a job that turns my pathology into something good. But there is nothing wrong with the majority of users who have other interests. We need to make sure that our products work for those people who don’t take a great interest in how things work.

This brings us to rules of thumb. We all follow some rules of thumb without understanding the reasons behind them. Life is too short to investigate everything. Sometimes these rules persist when the reason behind them disappears. An example of this is the habit some people still have of underlining for emphasis. No printed document should have underlining in it, but the practice is a holdover from the days of typewriters. Here’s another apocryphal example:

I was having dinner at a friends house and before he put the roast in the oven, he cut about an inch off from each end. I asked him why and he said that it makes the roast taste better. I said that I’d never seen this before, but he said that he learned it from his mother, but never really asked about it. So he called his mother to ask why she always cut off the ends of the roast. She said, “Well, with the tiny oven we had back then, a large roast wouldn’t fit; so I had to cut a bit off.”

Rules, without reasons, can turn out to be wasteful or sometimes actively harmful.

Now time for a true story: Back in the days when banks were issuing credit cards to trees a friend of mine explained what he did with the credit cards he didn’t plan to use. He knew that the cards had to be signed to be valid (it said so right on the card!), so he never signed the ones that he didn’t plan to use. This, of course, made him less secure, because a stolen credit card could then be signed by the thief whose signature would easily match what was on the back of the card. But if you don’t think about the reason behind the rule, then his mistake was very reasonable.

Security systems (well, the good ones anyway) are designed by people who fully understand the reasons behind the rules. The problem is that they try to design things for people like themselves—people who thoroughly understand the reasons. Thus we are left with products that only work well for people who have a deep understanding of the system and its components. The fantastic designers and developers here at AgileBits would fall into the same trap if we didn’t constantly remind ourselves that we want to bring a secure password and information management experience to everyone.

2. Your security is my security

Helping other people be secure is a good thing in and of itself. But there is also a selfish motivation: Your security is my security.

I used to hear people say, “Well I don’t do anything sensitive with my computer, so I’m not worried about its security.” I hear that statement less now that more people are doing on-line banking and shopping, but let me use this example anyway. A compromised home computer that is connected to the network, even if there is no data worth stealing on that computer, gets used for other criminal activity. The computer can be used for sending spam, attacking other systems, or hosting fake pharmacy sites.

A compromised computer joins the arsenal of the bad guys even if they don’t do damage to its the legitimate owner. This means that the cost of letting your computer be compromised is not borne by you, but is distributed over the rest of the net. Because of this distorted incentive system, many people are unwilling to take on the chore of security if they don’t see the benefit.

I think that many security developers have mistakenly assumed that people are willing to pay a substantial price in convenience for security, forgetting that most home users don’t actually feel the consequences of their own insecure practices. I suspect that one reason why the convenience versus security myth has persisted is that the system developers cared so much about security that they assumed that everyone else did too. These assumptions and their resulting obsession over security meant that little or no effort went into looking at usability.

3. Complex options

If you look at the Preferences > Security window in 1Password you will see seven different options.
This is more than we we would like. You will also find that although 1Password is extremely powerful there aren’t boat loads of “Advanced Options” either. For a product that has been under such intensive development (1Password for Mac has been updated over 150 times in its life) you would expect options from “use Blowfish instead of AES” to “store my keys file on an external device” or additional functions such as “manage my Certificate Signing Requests” to “manage my hardware serial numbers”.

To help explain our reluctance to add these seemingly useful features, I’ll quote from an old (2003) article by Niels Ferguson and Bruce Schneier on why IPSec—an internet security technology—never met expectations:

Our main criticism of IPsec is its complexity. IPsec contains too many options and too much flexibility; there are often several ways of doing the same or similar things. This is a typical committee effect. Committees are notorious for adding features, options, and additional flexibility to satisfy various factions within the committee. As we all know, this additional complexity and bloat is seriously detrimental to a normal (functional) standard. However, it has a devastating effect on a security standard.

We will, of course, add features and options when they make things easier and more secure for a large portion of users. But we also resist the temptation toward feature bloat, even when it is “just an advanced option for those who want it”. The thinking that “well it’s just one option that most people can ignore” is fine when it really is just one option, but it never really is just one.

We do look seriously at feature requests; I don’t mean to suggest otherwise. But our concern for usability for everyone is why we tend to be very conservative about adding more options. Never fear, though. There are some great new things in the pipeline that will make 1Password even more useful for everyone. As it has been for more than five years now, 1Password is under active development, and we have some wonderful stuff for you to look forward to.

4. Because the myth is kind of true

Of course there is some truth to the convenience versus security myth. After all, the fact that we have passwords (or other authentication means) at all for websites is an inconvenience. So it would be absurd for me to completely deny the myth.

Most of the trade-offs we face are between security in one respect with security in another. For example, we could store more of 1Password’s indexed information in an unencrypted format (which would slightly speed up some processes) if we didn’t insist on decrypting only the smallest amount of information needed at any one time.

Why Wendy can encrypt

You may have met Wendy Appleseed. She is our sample user if you import our Sample data (Help > Tools > Import Sample Data File). Wendy can get the full benefits of the top notch algorithms and protocols we use because we take her user experience very seriously; we see convenience as part of security. When we are presented with something that appears to be conflict between usability and security, we take that as a challenge. Meeting that challenge is hard work, but we love it.

AES Encryption isn't Cracked


An otherwise excellent article over at The Inquirer has a very unfortunate title: AES encryption is cracked. AES is the Advanced Encryption Standard and is at the heart of so much encryption used today by governments, militaries, banks, and all of us. It is used by 1Password and less directly by Knox for Mac. It is the work horse of modern cryptography, and modern computer chips even have components built is to allow AES to be used efficiently. If AES were to be found weakened in any meaningful way, it would be very bad news for a lot of people.

Before I get into what has happened, I’d like to quote from the research paper itself: “As our attacks are of high computational complexity, they do not threaten the practical use of AES in any way.

And quoting the Inquirer’s interview with Andrey Bogdanov, one of the researchers, we learn

“To put this into perspective: on a trillion machines, that each could test a billion keys per second, it would take more than two billion years to recover an AES-128 key,” the Leuven University researcher added. “Because of these huge complexities, the attack has no practical implications on the security of user data.” Andrey Bogdanov told The INQUIRER that a “practical” AES crack is still far off but added that the work uncovered more about the standard than was known before.

“Indeed, we are even not close to a practical break of AES at the moment.”

What’s the news

I’ve been trying to work through the actual paper and presentation slides by Andrey Bogdanov, Dmitry Khovratovich, and Christian Rechberger who were visiting Microsoft Research when they developed this. And although this research is far from having any practical influence on the use of AES it is actually fairly big news.

Cryptographers use the word “broken” in a very special way. If an attack on an algorithm can be computed with fewer computations than is required to check every single possible key, then the system is “broken”. Even if the improvement in the number of computations is negligible (as in this case) and even if other resources needed to get that small advantage are outrageously huge (again as in this case) it still gets called “broken”. But in this very specialized sense of the word “broken” the new research represents the first break of the full AES. It also displays the power of a technique developed earlier by the authors.

Impracticality #1: Impossible amounts of data

The authors calculate the best attack using their technique on AES with a 128 bit key requires storing 288 bits of data. That works out to about 38 trillion terabytes of data. Although estimates are hard to pin down, this is more than all the data stored on all the computers on the planet.

Impracticality #2: All for a two-bit gain

The number of encryptions that have to be performed to recover a 128 bit AES key is 2126.1 instead of the 2128 encryptions it would take to try all of the possible keys. This is a very small gain, as a 126-bit key (instead of 128-bits) would still take billions of years.

Impracticality #3: Lots of known plaintext needed

I may be misreading the research, but I believe that to discover an AES key, an attacker needs an enormous amount of known plaintext. That is, the attacker needs to already have a huge amount of information in both decrypted and encrypted form. I don’t know exactly how “huge” this will be, but I expect it to be far larger than any data anyone would or could encrypt using 1Password. I’m speculating here until I get a better grasp of things. Indeed, the amount is almost certainly related to the amount of data needed in “Impracticality #1”.

So this all doesn’t represent any threat to the practical use of AES for any purpose it is used for. An unfeasible amount of data needs to be stored in order to gain an insignificant improvement over just trying every key. But what it does do is highlight features of AES that make it subject to this kind of attack. Whether attacks based on this ever become any kind of real threat, we can bet that successors of AES will incorporate mechanisms to thwart them.

Where’s the meat? It’s in the middle

From here on out, I will try to explain some of what I understand from the new attack. There is much that I don’t understand of this, but I will give a broad outline and then wave my hands a bit. This part gets very technical, and I won’t be the slightest bit hurt if you stop reading here.

You may have heard of 3DES (Triple DES) which was used in many places before AES was settled upon as a replacement. The old Data Encryption Standard (DES) uses 56 bit keys. By the time we got into the 1980s it was absolutely clear that 56 bits was no longer enough for a key size. One could imagine (as many people did) taking two DES keys and just encrypting your data twice, first with one DES key and then taking that output and encrypting that with the second DES key. This, you might think, would get you the strength of a 112 bit key. It doesn’t.

It turns out that if you have an sample plaintext and ciphertext pair what you can do is try everyone one of the 256 possible keys on the plaintext and also try everyone of the possible keys on the ciphertext as well. You will then find that there is an overlap of results. Some things that the plaintext encrypts into with one key will be the same as what the ciphertext decrypts into. This will give you (pretty much) the two 56 bit keys. This looking for where the output of one can meet up with the input of the other leads to this being called a “meet-in-the-middle” attack (not to be confused with a “man-in-the-middle” attack which is something else entirely). Note that in doing this, we “only” had to work through 256 keys twice. That is the same as working through 257 once. So double encrypting with DES only improved the security by one bit. This is why to get 112 bit strength out of DES we need to go through it three times, and so even though it allows for double the number of key bits, it is actually Triple DES.

Meet-in-the-middle diagram

Now back to AES. Ciphers like AES go through multiple rounds of scrambling and manipulating the data. They also have various internal states as they process a block of data with a key. If we find an internal variable that allows us to break the encipherment into two halves then it is possible to do a meet-in-the-middle attack on that. AES, along with every modern cipher, is designed with this in mind. It is designed with enough rounds and interactions among them so that a standard meet-in-the-middle attack will not be quicker than simply trying every key.

Instead of doing the traditional meet-in-the-middle attack, the new attack constructs entities that group internal states, potential keys which complement each other in specific ways, and ciphertext into what they call “bicliques”. By using these more abstract entities instead of an intermediate variable, the attack can avoid some of the limitations on meet-in-the-middle attacks and be effective over a greater number of rounds. By carefully selecting which potential keys go into which biclique, some computation can be reduced by avoiding any duplication of effort. I still haven’t managed to understand, even in overview, how and why these bicliques do what they do, so I can’t say much more.

Thanks for joining me

If you’ve read this far (including the last section) then I thank you for joining me through my process of trying to understand this new attack on AES. Even though it has no practical implications, I find this stuff oddly fascinating. If you’ve just skipped right to the bottom (not an unreasonable thing to do at all) then let me say again everyone who has studied this, including the authors of the attack, state that this has no implications whatsoever for the practical use of AES.

Better Master Passwords: The geek edition

I’ve always wanted to write a technical followup to an earlier post, Toward Better Master Passwords, but this time going into some of the math behind it. Today’s xkcd comic does that for me:

Indeed, what took me nearly 2000 words to say in non-technical terms, Randall Monroe was able to sum up in a comic. This just shows the power of math, but that’s another issue. So for those of you who want to understand the comic and see how it relates to my earlier post, read on. But first read or re-read my earlier post on strong master passwords.

If, like most sane people, you don’t want to dive into a technical discussion, then stop here and just read the original, non-technical, post that says the same thing as the comic. It’s also where the practical advice is.

The only thing I’ll restate

There is one concept (well, actually two concepts) from the Toward Better Master Passwords post that needs to be restated. It is central to everything that follows:

The strength of a password creation system is not how many letters, digits, and symbols you end up with, but how many ways you could get a different result using the same system.

This embodies two things that we need to take into account when looking at the strength of some components of security. Kerchoff’s Principle, and entropy.

Kerchoff’s Principle

Kerchoff’s Principle states that you should assume that your adversary knows as much about the system you use as you do. In this case it means that if you are following advice about how to generate strong memorable passwords, the people who will be trying to break that password are at least as familiar with that advice as you are.

I can’t over-emphasize the point that we need to look at the system instead of at a single output of the system. Let me illustrate this with a ridiculous example. The passwords F9GndpVkfB44VdvwfUgTxGH7A8t and rE67AjbDCUotaju9H49sMFgYszA each look like extremely strong passwords. Based on their lengths and the use of upper and lower case and digits, any password strength testing system would say that these are extremely strong passwords. But suppose that the system by which these were generated was the following: Flip a coin. If it comes up heads use F9GndpVkfB44VdvwfUgTxGH7A8t, and if it comes up tails use rE67AjbDCUotaju9H49sMFgYszA.

That system produces only two outcomes. And even though the passwords look strong, passwords generated by that system are extremely weak. Of course nobody would recommend a system that only produced two outcomes, but people do recommend systems that produce a far more limited number of outcomes than one might think by inspecting an individual result of the system. This is because humans are far more predictable than we like to believe.

Entropy

What unit do we use to measure the number of different results you can get from a system? The answer to that is “bits of entropy”. The silly system I listed above can get us two different results. We can represent two different outcomes using one binary digit (bit). Passwords from that system have just one bit of entropy.

Now suppose we had a similar system that involved rolling one die. That would lead to six possibilities. Six outcomes can be represented in three bits (with a little room to spare). The actual number of bits is closer to 2.58. (And for those who really want to know where that number came from it is the base-2 logarithm of 6.)

One feature of using bits of entropy as a measure is that each bit represents a doubling of the number of possible outcomes. Something with 10 bits of entropy represents 1024 possibilities, while 11 bits will double that to 2048 possible outcomes. There are many reasons that we use bits instead of the number of possibilities. I won’t go into the mathematical reasons, but one nice result is that it gives us manageable numbers. In cryptography we routinely deal with things that have 128 bits of entropy. 128-bits would represent 340282366920938463463374607431768211456 possible outcomes. It’s hard think about or compare such numbers.

Working through the comic

Now lets look at a few things in the first pane of the comic. Let’s start with the stuff I’ve put into the green pink box. The single small gray square in the bottom of the green pink box shows that the choice between capitalizing or not capitalizing the word adds one bit of entropy. Of course people could add more entropy by possibly capitalizing other letters, but people don’t capitalize randomly. The do so at the beginning, at the end, or sometimes at internal word or syllable boundaries.
If people capitalized randomly that would add a lot of entropy, but capitalizing randomly would make the password impossible to remember.

Now let’s look at the stuff that I’ve put in the blue box. Here 16 bits are awarded to picking an uncommon, but non gibberish word. That would imply that the person picked a word in a truly random fashion from a list of 216 words (65536). I don’t believe that people would be truly random in their choice of base words, so I would assign fewer bits to this choice, but I’m not going to quibble about a few bits here and there.

The red box covers three “tricks”. Adding some punctuation and a numeral to the end of the password. Adding a numeral gives us roughly four bits of additional entropy, and punctuation gives us four. We get one additional bit by not knowing which comes first, the digit or the punctuation.
I didn’t put a box around the common substitutions and misspellings of changing something like Troubadour to Tr0b4dor; three additional bits seems about right.

When we add up all of the bits of entropy that this system uses we get 28-bits. Of course the system can be made more complex and may go up a few bits, but almost certainly at a great cost of memorability.

For those who recall some laws of logarithms, you now can see an additional benefit for using bits as our unit instead of numbers of possible outcomes: We can add the bits contributed by each choice instead of having to multiply the number of possibilities. It is very convenient to say that such-and-such adds X bits of entropy.

Now contrast this with using a sequence of random common words. It is absolutely crucial that the words be chosen in a truly random fashion. Here 11 bits are assigned to each word. That means that the list of common words used has 211 elements. That is, it is from a word list of 2048 words. This gives a more memorable password with 44 bits of entropy.

Cracking time

Depending on what sort of access the bad guys have, they can test from 1000 passwords per second to hundreds of thousands per second. For more information on how we slow this down, see the post on PBKDF2. Only you can decide how much effort someone will put into cracking your master password if they get hold of your data.

Using Diceware alone with five words (you know what I’m talking about because you read the earlier post) you will get 64 bits of entropy. If you add your own private scheme (say it contributes 10 bits) then you will have 74 bits of entropy, which would take about 500 million years to crack at one million guesses per second. Not everyone needs that kind of strength in a master password.

Of course if you do have Three Letter Agencies willing to spend hundreds of millions of dollars specifically on getting at your secrets, then you have problems bigger than what can be managed through software alone. Indeed, let me point you to another favorite xkcd comic.

[Updated: August 11 to correct my colorblindness error and spelling of Randall Munroe’s name. — jpg]

JavaScript grows up and plays in a sandbox

About 12 years ago I was fighting a losing campaign against JavaScript’s ubiquity. There was a time when JavaScript was a security nightmare, and I ranted and raved against it. Things have changed enormously since then, all for the better. A few of the slogans that I and my colleagues shouted from the rooftops in the previous millennium seem to have stuck in the public mind, “Using JavaScript is insecure” or “JavaScript can’t be used for encryption”. Those slogans are no longer true. This post talks a little bit about how things have changed.

What has happened over the past dozen years falls into two categories. The first have to do with the way browser developers look at JavaScript. All of the vulnerabilities in handling JavaScript taught browser developers to be much more systematic and careful with how they handled JavaScript itself. The design of JavaScript and browsers have gone through a lot of change during this time.

Playing in the sandbox

Rhino Sandbox

The second category of change is more recent, and it really changes the game. The buzzword is “sandbox”, and it needs a lot of clarification because it is used all over the place in different ways. Roughly the idea is that something can do what it wants within a limited area and cannot really interact with anything outside of that sandbox. It is a safe place to play.

Increased browser sandboxing affects 1Password in two very big ways, and these are because of two different kinds of sandboxing relevant to us.

Sandboxing the browser

The first sandbox that matters for us is that browsers are becoming increasingly restrictive in what bits of your system they can interact with. The way that 1Password interacts with Safari 5.0 and earlier is profoundly different than the way that 1Password is allowed to interact with Safari 5.1 and above. Prior to Safari 5.1, there were “hooks” in Safari that allowed external applications to communicate with Safari. But in Chrome, from its inception, and in Safari from version 5.1 that kind of communication isn’t allowed. This is a major security enhancement; it limits the damage that a browser exploit can do. A successful browser exploit now can only interact with data and processes that are within the browsers’ sandboxes.

The upshot of this is that we have had to entirely redesign our Safari extension to fit within the tighter, better security model of Safari. It means that 1Password needs to work within the browser to do its job. That work must be done using only CSS, HTML, and JavaScript. Clearly for 1Password most of that work will be in JavaScript.

Sandboxing the extension

Browser extensions shouldn’t step on each others’ toes. We need to prevent this not only for security reasons, but for stability reasons. Extension X shouldn’t be able to see the database created by extension Y. So each Safari extension is also put in its own sandbox. This not only protects others from a misbehaving extension, but it protects the extension from outside interference from other sources, including JavaScript in the web page a browser is visiting.

JavaScript and encryption

People used to say that you can’t do encryption in JavaScript (because it doesn’t have the right data types, and because as in interpreted language it is far too slow). I suspect that most readers will have noticed that computers have gotten a little bit faster over the past 10 years. So while JavaScript may not be ones first choice of language coding encryption routines, there are now well developed, publicly available implementations of all of the algorithms and protocols that we rely on.

Users of 1PasswordAnywhere over the years have already experienced JavaScript opening of their 1Password data.

Times, and rules of thumb, change

It seems like yesterday (though it was actually years ago) that I was telling people to distribute documents as PDFs instead of word processer documents, because PDFs can’t be exploited in the same way. (As an aside, I would like to mention that there is a new security update for iPhone which fixes an exploit that can live in a malicious PDF file). It’s also true that the password advice I would have given 10 years ago is much different that what I would give now. The tools and the threats have changed so much. So it is with JavaScript.

Enhanced by Zemanta

Dropbox Terms

When in the course of network events rumors start flying about Dropbox a decent respect for the concerns of 1Password users compels me to blog about it.

1Password users certainly enjoy the convenience of syncing their data across Mac, Windows, iPhone, iPad, iPod Touch, Android and Windows 7 Phone. This is managed using Dropbox, and so it is fit and proper for 1Password users to be attuned to news regarding Dropbox security and privacy.

1Password in DropboxYesterday (July 1) Dropbox provided an update of their terms of service. Since then the net has been a-twitter with very frightening accusations about what Dropbox may do with your data. Those accusations are incorrect, and the Dropbox terms of service do not give them any rights to your data that you wouldn’t expect. And as always the main thing to keep in mind is that your 1Password data are well encrypted before ever being sent to Dropbox (or even written to your own disk).

Read the policy, not the tweets

It appears some misleading (at best) and downright incorrect claims about the Dropbox Terms of Service are spreading via Twitter and blogs. So don’t trust what the bloggers say (I guess that includes me) and go read the Dropbox Terms for yourself.

Permission to share what you ask them to share

The portion that seems to be behind the panic is in this paragraph:

We sometimes need your permission to do what you ask us to do with your stuff (for example, hosting, making public, or sharing your files). By submitting your stuff to the Services, you grant us (and those we work with to provide the Services) worldwide, non-exclusive, royalty-free, sublicenseable rights to use, copy, distribute, prepare derivative works (such as translations or format conversions) of, perform, or publicly display that stuff to the extent reasonably necessary for the Service. This license is solely to enable us to technically administer, display, and operate the Services. You must ensure you have the rights you need to grant us that permission. [Emphasis added]

Dropbox can be used for more than just syncing your own private data. It can be used to share information with selected others or with the world. When you put something in your Public folder on Dropbox to share, you are asking Dropbox to re-publish that data. Dropbox actually needs your permission to do so, and this paragraph is the bit of their Terms of Service which allows them to share the material you ask them to share.

The bottom line is that there is nothing in these Dropbox Terms of Service that gives them the right to do anything with your data that you don’t ask them to do. (The one exception is in the paragraph of the Dropbox privacy policy which states that they will comply with law enforcement requests for data stored on Dropbox.)

New Security Document

I have complained in the past that Dropbox had been unclear about their security policy with respect to everyone’s data. I am very pleased that they have produced a new security document now and that they took the time to do it right. It contains no surprises. Also with this announcement, they have updated their applications and APIs for mobile devices to address an earlier concern about encrypted filenames and such.

Why Dropbox and where are the alternatives?

Dropbox seems to have shifted from an Internet darling to a boogyman in less than six months. The silly accusations regarding re-publishing permissions in their newly stated Terms of Service illustrates that any allegation about them will gain traction even when completely unfounded. But even though this current hysteria can be dismissed it doesn’t mean that we can brush off all concerns about Dropbox or any cloud syncing solution.

I will try to briefly address some of the questions that come up in any discussion of Dropbox and 1Password. These are “Why Dropbox?” and “Have you considered X as an alternative sync solution?”

Dropbox does two things that no other system (yet) does. It provides the necessary programming tools (APIs) for all of the platforms that we support: OS X, Windows, iOS, Android, and Windows 7 Phone; and it provides syncing to truly native filesystems on the Mac and PC.

The short answer to “Have you considered X as an alternative sync solution” is “Yes” for every value of X that people have asked about. We have considered them, and have had to reject them for various technical reasons.

Getting more technical

Each item in your 1Password data is stored in its own, separate, file. This is great for syncing in that it means that only the changes need to sync and this can be done by file and folder syncing. This not only makes syncing faster and cheaper, it also makes it much more reliable and robust against potential data corruption. But this also means that 1Password needs to read lots of different files quickly as it runs. Dropbox does fast syncing while storing the local files on the native local file systems, allowing it to function properly.

As an illustration, an alternative such as WebDAV (which we worked on extensively but had to abandon before we moved to Dropbox) provides a file system abstraction layer that is just too slow for 1Password. It can hang when we try to access some file that it hasn’t cached properly. Also WebDAV isn’t designed for updating many files is quick succession. It’s not that WebDAV is bad, but it isn’t suitable for how we would use it.

Everything else we’ve looked at (and we have looked at many things) suffers not only from the same problems we saw with WebDAV, but they also lack usable APIs for all the platforms we need to support. It may be possible, for example, to sync data to an Android or iOS device using SugarSync or Wuala, but it isn’t possible to sync that data in a way that would make it available to 1Password on those devices.

What’s gone before

I’ve written about a number of things related to the security of your 1Password data in the cloud and on Dropbox in particular. Instead of repeating those, I will list some of those here.

Dropbox Security Questions and Dropbox security revisited: Plus ça change
Both discuss the Dropbox security issues that arose earlier this year. As an update, over the course of the past few months, Dropbox have successfully addressed each of those concerns.
Defending against crackers: Peanut Butter Keeps Dogs Friendly, Too.
What we do to defend your master password against automated crackers if your data should fall into the wrong hands.
Toward Better Master Passwords
What you can do to defend your master password against automated crackers if your data should fall into the wrong hands.
Looking ahead in security
Some hints about what we are working on to make your data even more secure in the cloud.

In Conclusion

Thinking about security (and privacy) is hard. It is important to look at the facts behind the headlines and the tweets before jumping to conclusions.

Update: An expert weighs in

Simon Bradshaw who blogs about intellectual property and technology on his LawClanger blog has posted an analysis, coming to pretty much the same conclusions presented above. [Updated, July 5]

Update 2: Dropbox rewrites

On July 6, Dropbox posted about a rewrite of their Terms of Service. In my reading of it, it makes no changes of substances, but it goes above and beyond the standard language that we see elsewhere in allaying fears.

By using our Services you provide us with information, files, and folders that you submit to Dropbox (together, “your stuff”). You retain full ownership to your stuff. We don’t claim any ownership to any of it. These Terms do not grant us any rights to your stuff or intellectual property except for the limited rights that are needed to run the Services, as explained below. […]

Now that things have calmed down a bit, I would like to reflect on (and rant about) how we got here.

My overall point remains. A few people who were unfamiliar with reading ToSes delved into the earlier ToS and misinterpreted something and posted their misinterpretations. Those misinterpretations spread like wildfire because others were willing to believe the worst instead of investigating for themselves. I am not criticizing typical users for doing so, but my frustration is directed at portions of the technology press who did not do their job.

People are correct to be concerned about what is buried in Terms of Service and Privacy agreements. As a whole, we don’t pay enough attention to these, and it is good news that people are paying more attention. But it also takes some time to learn how to read them. If something seems fishy, ask for an explanation before jumping to the conclusion that something is evil. If you are part of the technology press your job is to do your homework instead of just regurgitating hot stories for clicks. The press’ job is to investigate, analyze and explain. [Updated July 8]

Toward Better Master Passwords

1Password is great for generating strong random passwords for sites without you ever having to memorize (or even see) those passwords. But there are a few passwords that we all do need to remember. I have a small number (I wish I could say just one) high security passwords that I need to remember. One, of course, is my 1Password master password.

Your 1Password master password is extremely important. Although we take steps to thwart automated password crackers you should still use a strong, memorable master password. Password cracking tools are becoming more powerful every year, and too much is at stake in your 1Password data. Given the strength of the encryption we use, your master password is likely to be the weakest link in your 1Password security. Don’t be too scared of that. Given how strong everything else is, it would be practically impossible to use and remember a master password that is actually stronger than 1Password’s encryption.

This is going to be a very long blog post, so I’d like to start out with a few points to keep in mind

  1. We are not seeking perfection. Instead we need to find ways to improve master passwords if they aren’t currently very strong.
  2. Many of the schemes that people (including myself) have proposed in the past suffer from a major flaw.
  3. No matter what you read here, always keep in mind that a master password that you can’t type or remember is terrible choice of master password.
  4. This discussion applies only to 1Password data on the desktops or stored in the cloud. Master passwords for 1Password on iOS do not need to be as strong as master passwords on the desktops. [Update: Since 1Password 4 for iOS was introduced in December 2012, the same Master Password is used on all of your devices.]

Change a weak master password, otherwise leave it be

Change master password window

We’ve all been told to change passwords on a regular basis, and there are still some circumstances under which that remains reasonable advice. But it is not a good idea with 1Password master passwords. Ideally you should pick a good master password at the outset and never change it.

Passwords in need of changing

Everybody knows to avoid short, common passwords or dictionary words (in any language). The world’s most common password, 123456, is, of course, terrible. But even things like Sally4th or like Molly&Patty2 (the names of my dogs) are not really strong enough for something as important as your 1Password data. The latter is just of the form NAME & NAME DIGITS which password guessing programs do get around to checking.

You can change your master password in 1Password by going to Preferences > Security and clicking on the “Change Master Password” button.

After you change your master password

It is extremely important that you learn your new master password, and you learn it through practice.
Go to the Security preference pane again and set “Auto-Lock” on and to a short time. Maybe just 5 or 10 minutes. This will mean that you will have to type in your master password more frequently, but that will help you learn it. After a few days, you can then set the Auto-lock time back to something less annoying.

Also – and this may sound like heresy even though it is sound security advice – when you change your master password, you can write it down on a slip of paper and put it in your wallet. Once you no longer need to refer to it, you can destroy the piece of paper.

A walk through of a password creation system

The challenge that we face is to have master passwords that not going to be guessed by password cracking programs, yet we mere mortals are capable of remembering and typing without it being a burden.

What makes this a particular challenge is the fact that the bad guys know at least as much about how people pick passwords as we do. They are not only reading the same password picking advice that gets posted in places like this, but they have studied millions of stolen passwords.

Here is an important principle that we need to keep in mind:

The strength of a password creation system is not how many letters, digits, and symbols you end up with, but how many ways you could get a different result using the same system.

Don’t worry if this principle doesn’t make sense yet. It should start to after I walk through an example.

I have two dogs: Molly and Patty. Suppose I wanted to make a master password from that and came up with Ihave2dogs:Molly&Patty. With that as an example, I’ll work through why that isn’t as good as it might first appear. (It looks good at first because it is long, has mixed case, and has punctuation.)

Use spaces to make things easier for you

1Password master passwords can include spaces. So you can make things easier to type and remember by using spaces (even though it adds little to the actual security). So our first improvement will be to change this to I have 2 dogs: Molly & Patty

Don’t tell the the truth

If your master password is to be based on something meaningful, remember that there are more ways to lie than to tell the truth. There are more ways for me to lie about my pets than tell the truth, and so I should use a lie. So let’s try, I have 3 bats: Larry, Moe & Curly.

Don’t make sense

There are more ways for a sentence to not make sense than to make sense. So let’s change my three bats to thirty-five bats, but still list three: I have 35 bats: Larry, Moe & Curly

Avoid predictable phrases

For those of us of a certain age and steeped in American culture, once we begin a list of names with “Larry…” following it with “Moe and Curly” is very predictable. So even though the Moe & Curly add 11 characters to the password, those 11 characters are so predictable that they add very little actual strength. Even though it is shorter, using I have 35 bats: Larry & Amy is actually stronger than I have 35 bats: Larry, Moe & Curly.

Along the same lines, the “e” after “I hav” isn’t doing much good either. Because it is easily guessable from the rest of the password it isn’t actually adding much strength. There is nothing wrong with that “e”, but I’m mentioning it to help illustrate the point that the number of ways things can be different is often more important than length itself.

Avoid secrets or things that are personally meaningful

The more personally meaningful something is to you the fewer alternatives there are. There are more things that don’t have personal meaning to you than do.

In particular avoid personal secrets. Twice in my life when I’ve been asked to find weak passwords where I worked, I had the embarrassing task of telling my friends and colleagues to change passwords that also revealed their secret crushes. Also there may be a time when you actually do need to reveal your master password to a loved one. When I spot passwords like IloveUVicky along with the owner’s email address among 26000 email addresses and password exposed from a pornography site, I certainly hope that this won’t cause too much trouble for the owner.

Obvious punctuation is obvious

Capitalizing the beginnings of words or changing “for” to “4” really doesn’t add much security. Remember, if you can think to do this, the people who write password cracking systems have already done the same. Unfortunately adding punctuation in truly random manner makes the password too hard to remember. Certainly add the obvious punctuation, but recognize that it doesn’t strengthen your password as much as it might appear.

What we’ve learned from this example

At every stage in working though this example, we made some real improvements. Remember that we are not trying to reach perfection here; we are looking instead to create better master passwords that remain usable. Do not create trouble for yourself by picking a master password that is too difficult to type or too hard to remember.

But we have also learned that human behavior really isn’t very random. The schemes we come up with can be coded into password cracking systems. A good master password is not just limited by what a human can remember, but it is also limited by what a human can create. We can get digits and punctuation into passwords easily enough, but our selection methods involve a lot of predictability. Human behavior is more predictable than we like to imagine. That predictability can be exploited in password guessing programs.

Roll the dice to avoid predictability

dice

If people are so predictable, how can we create memorable passwords that aren’t predictable? It turns out that Arnold Reinhold published a solution to this back in 1995 to help people create strong and memorable pass phrases for PGP. It’s called Diceware.

Because words have meaning, we can remember a sequence of words even if it doesn’t create a meaningful statement. And because there are many more words than there are individual characters, selecting a random sequence of five or so words provides a hard to crack password.

Reinhold produced a list of 7776 short words or sequences (that is 65 for people who care about such things). A word can be selected from the list by rolling five dice (or rolling one die 5 times). Here is a small excerpt from the English Diceware Word List.

  35443  knew
  35444  knick
  35445  knife
  35446  knit
  35451  knob
  35452  knock

If you roll your dice and get the sequence 3 – 5 – 4 – 5 – 1, then your Diceword would be “knob”. Another five rolls of the dice will get your next word. If you rolled 3 – 2 – 6 – 5 – 6 then your next word would be “hike”.

The great thing about Diceware is that we know exactly how secure it is even assuming that the attacker knows the system used. The security comes from the genuine randomness of rolling the dice.  Using four or five words should be sufficient against the plausible attacks over the next few years given observed speed of password crackers. [Updated October 2, 2013]

For those who really want to use this system and get the most security out of it, you should combine Diceware with your own private system. Create a short random password, including digits and symbols and use that in place of one of the dicewords in your final password. So going back to my dogs, Molly and Patty, I might create a weak password like 2dM&P, and suppose my rolls of the dice gets me cleft cam synod lacy, I could then create a master password like cleft 2dM&P cam synod lacy, which would be a very good master password. With repetition, it is something that you can learn to type quickly.

In Conclusion

I would like to remind you of some crucial points I made near the top:

  • We are working toward better passwords, not perfect ones. You should take only as much advice from this as you are comfortable with and no more. Remembering and typing in your master password should not become a chore.
  • If you do change your master password, practice with it regularly so that you don’t forget it. Don’t be afraid to write it down on a piece of paper for a while if you keep it in a safe place.
  • The kinds of master passwords that you need depend on who may try to break it. Even though a typical criminal may have access to sophisticated cracking tools, it is unlikely that they will dedicate hours – much less days, weeks, years or decades – to your particular data.

Related (later) articles

  • This article was followed up by a geek edition which discussed an XKCD comic and some of the mathematical concepts behind this.
  • Once the password cracking tool, John the Ripper, was adapted for taking a shot at 1Password Master Passwords, we looked at how well 1Password holds up with these sorts of Master Passwords
  • In April 2013, hashcat achieved remarkable speeds (300,000 guesses per second) against the 1Password 3 data format, suggesting that a password of 4 or 5 diceware words should be used with 1Password 3.

Dropbox security revisited: Plus ça change

Plus ça change, plus c’est même chose
— Jean-Baptiste Alphonse Karr

Summary: Dropbox remains safe for 1Password use despite some high profile discussion of its security.

Keeping up with news about security issues can make your head spin. It certainly does that to me. Most often important news gets little public attention, and at other times non-events go viral. I think the latter has happened with respect to the complaint filed against Dropbox (PDF) with the United States Federal Trade Commission.

Naturally, when I heard that the complaint had been filed I had to read it closely. After all, the security of Dropbox is of great concern to us all. So what did I find? I found that every security issue mentioned in the FTC filing was something that we had already looked at. I discussed all of these points in earlier posting.

There is no new information in the FTC filing or discussion surrounding it, and so the conclusion posted earlier still stands:

[T]here is no need to panic about Dropbox security. The issues that have come up all do raise very 1Password in Dropbox
legitimate concerns about how Dropbox presents their security claims and addresses issues when they arise, but the actual issues are not nearly as serious as some of the the discussion would suggest. They are even less of an issue for 1Password users. Your sensitive information in your 1Password data is extremely well encrypted and we remain comfortable recommending syncing with Dropbox.

It seems that not even I can resist blogging about the FTC filing, but recent news has put me in the position of having to say that just because there is new “news” doesn’t mean there is new information. Real security must be based on level headed assessments of the threats, whether those are highly publicized or – as is more common – are only discussed by those in the field.

Informed users are the best users

Informed users are the best users, and the outpouring of questions to us regarding Dropbox let us know that you want to be informed. I am delighted by this, but it has also meant that we haven’t been able to respond to queries as quickly as we would like. We are all working hard to catch up, and we should soon be back to providing the speedy responses you deserve and have come to expect from us.