Be your own key master with 1Password

Encryption is great. By magic (well, by math) it converts data from a useful form to complete gibberish that can only be turned back into useful data with secret number called a key.

I happen to think that the term “key” that we use for encryption and decryption keys is a poor metaphor, as it suggests unlocking a door or a box. Cryptographic keys are more like special magic wands that are essential to the process of transforming data from its useful (decrypted) form to gibberish and back again. Since we’ve seen fit to disguise this magic wand as a simple “key,” I will continue to use “key” for simplicity’s sake.

Encryption is very powerful magic, and when done properly it is so close to being unbreakable that we might even get away with claiming it is. Of course, anyone who has a copy of the key doesn’t need to break it; they can just use their copies of the keys to decrypt your data.

This is why we have designed 1Password so that we never have the keys needed to decrypt your data. You are the master of your own keys. You are your own key master.

I should point out that even if you trusted us to not misuse your keys (if we had them) they could still be stolen from us (if we had them). If everyone’s keys were all in one place that would also make a very attractive target — yet another reason we don’t want them. We cannot use, lose, or abuse information that we don’t have. It’s not like we are planning on having data stolen from us. But we do plan for the possibility. Not having your keys is an essential part of that planning.

Now if someone were to store encrypted data in the same place that they store the keys to decrypt it, they may as well not encrypt it in the first place. I do not know what happened to OneLogin (absolutely no relation to us), but they did release a notice to their customers saying that their customer data was compromised “including the ability to decrypt encrypted data.” That certainly suggests that they held both the keys to the data and the encrypted data itself.

It really doesn’t matter how strong your encryption is if the keys can be stolen along with the data. This is why we have been very careful to design 1Password so that we never, ever have the keys to decrypt your secrets. Even if we are breached, your data remains secure because you (and only you) have the keys to decrypt it — we don’t.

Key management is hard

Key management is hard. And it is hard to talk about. I would love to talk about it here, but frankly it is what the bulk of our technical documentation (PDF) discusses, and I cannot do it justice without turning this post into a treatise.

Instead, I will summarize (with many shortcuts and omissions) how 1Password manages the keys to unlock your data in a manner that keeps your data secure:

  • Your encryption keys are generated only on your devices.
  • They are generated using a cryptographically secure generator.
  • Those keys, in turn, are encrypted with other keys that are generated on your device the the same way.
  • The key that encrypts the keys that encrypt the keys that encrypt your data are derived from secrets that we never have access to: Your Master Password and your Secret Key (formerly known as Account Key).
  • We’ve made sure that you don’t pass us secrets from which your keys could be learned when you sign in to your 1Password Account.
  • We’ve designed things so that it is impossible to make guesses at the secrets your keys are derived from using the data that we do store.

I could write at great length about each and every one of these, but I should probably finish this article this year, and much of this is in our security white paper.

Where the strength lies

It is frustrating and hard for the consumer to judge the security of a product or system as they choose one. Everyone touts the same buzzword compliance, yet there can be substantial differences in security design that are not reflected by that jargon.

Very strong cryptographic tools are (fortunately) available to almost every developer, but using those tools doesn’t automatically make a system secure.  Let me offer an analogy in which I confess to being a terrible cook.

If I were tasked with producing a high quality cooked meal and were given the freedom to pick the very best ingredients, the results would not live up to the quality of ingredients. The failure wouldn’t be that I choose incorrectly between Himalayan rock salt or Oshima Island sea salt. The disappointing meal I would prepare would be because I used far too much salt on the spinach which I boiled for 10 minutes. Using the right ingredients is the starting point, but preparing something with them to be proud of takes much more work and skill.

Handling keys in a way that ensures that only the owner of the data has the power to decrypt it (or share it) is just one of the many things that needs to be done right to make a system secure, just like adding proper amounts of salt at the proper time while preparing food is just one of the many things that a cook needs to master in order to prepare a five-star meal.

There is an important way in which my analogy fails. It does not take an expert cook to judge the quality (or lack) of a meal I prepare. I could advertise honestly the use of the very best ingredients, but the proof would literally be in the pudding (and the starter, and the main course …). But the practical security of a system is not so transparent to non-experts (or even to experts if they are not given a peek into the kitchen). This, as I lamented, puts the consumer in a very difficult situation.

Our hope, however, is that our openness about our security design, processes, and decisions allows the curious to peek into the kitchen and make an informed decision. We are happy to go to great lengths to ensure the security of 1Password even if those results aren’t immediately visible to the typical user. We do that because it is the right thing to do. (And we enjoy the challenge.)

This last point – naturally enough – leads directly to …

The marketing pitch

If you know someone (possibly even yourself) who has been using something other than 1Password, then we have a great offer for those ready to make the switch to 1Password. Not all security tools are created equal, and we suggest that you see what the security community recommends and what people love. (Yes, 1Password is a security tool that people love using.)

And, of course, you don’t have to be a switcher to start using 1Password. Just start using 1Password.

9 replies
  1. tangible
    tangible says:

    Excellent post, and it points up a glaring problem in your industry: the lack of a trusted rating agency. When I buy a car I can check government crash test ratings rather than rely solely on the manufacturers’ claims. These tests are beyond anything I could undertake myself. Why can’t I do the same with security software, which, as you say, suffers from the same lack of transparency?

    The US federal government has apparently finally awakened to the threats of cyberterrorism, from the individual hacker to the actions of hostile nations. If we accept and value taxpayer-funded vehicle testing, it makes perfect sense to provide consumers and businesses with the information we need to keep our systems safe.

    I do want to offer a correction, fortunately not to your cyber expertise but to your food analogy. “The proof is in the pudding” is something that can only be properly said if your kid drops his geometry homework into the dessert bowl. The actual adage is, “The proof of the pudding is in the eating.”, meaning that we can talk theory forever but ultimately every theory must be tested.

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Thank you!

      I think I will stick with the more traditional form of the adage, “the proof is in the pudding,” which is intended to have the meaning of the more literal expression “the test of the pudding is in the tasting”.

      The adage does rely on an older meaning of the word “proof”, which also could be used as “test”. That somewhat archaic meaning of “proof” is how to make sense another fixed expression about “the exception that proves the rule.” It’s kind of funny that over time the everyday meaning of “proof” has moved closer to the mathematical one.

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Let me add to my previous comment that there is more than one way to prove a pudding.

      “Prove” in the context of that adage does mean “test” (see my previous comment). And one of the things that I lamented is that while puddings can be directly “proved” by the consumer it is harder for the consumer to know what sort of security a security product really offers.

      We don’t have any magical solution to that, but in addition to working to be very clear about our security design in gory detail, we explicitly invite experts and others to poke at 1Password. As I said recently in More than just a penny for your thoughts

      We believe that we’ve designed and built an extremely secure password management system. We wouldn’t be offering it to people otherwise. But we know that we – like everyone else – may have blind spots. That is why we very much encourage outside researchers to hunt for security bugs.

      We need experts to taste the pudding. And so we try to provide numerous avenues by which they can. The primary purpose of that is so that we can use their analyses to make improvements to the pudding, but we also hope that this gets communicated to those who are not in a position to prove the pudding themselves.

      What everyone can directly prove themselves is how well 1Password works for them. (Yes, that was another reminder about our free trial.)

  2. Ian
    Ian says:

    Can I just point out that it’s incredibly irritating that you’re truncating your RSS feed. Since you’re not getting any ad revenue from pageviews, it seems pointless.

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Hi Ian, I guess this shows that I haven’t been using a proper feed reader for a while, as I wasn’t aware that we were doing this. I will ask around to see if anyone knows why we are doing this.

      I can’t make you any promises because I do not at this time know why we have set things up this way.

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Well, I asked around and nobody offered up a reason for why our feeds are set to “Summery” instead of “Full Text.” Of course it is 2AM in Toronto which might go a teeny tiny way toward explaining why I have heard no objections to switching it to Full Text. So for the moment, at least, it is full text. Though that may just start showing up for new posts. Who knows? I don’t.

      Now as the Chief Defender against the Dark Arts at AgileBits, I should object internally to someone who doesn’t really manage a system or know too much about how it works having admin rights to it. Especially if that person goes and makes changes at 2AM without consulting those who do know about the system. Yet this certain fool does seem to have admin powers on this blog and is willing to use them!

      Full text in RSS feeds it is.

  3. Dayana Pears
    Dayana Pears says:

    Nice post but when it comes to data encryption and keeping them safe, I give my trust only to this software: [Link to advertised product omitted. —JPG]

    • Jeffrey Goldberg
      Jeffrey Goldberg says:

      Dayana, I do not believe that you can use the file compression and archiving product you mentioned for password management. But if you actually do, I would like to hear about it.

      Normally I won’t comment on the security design of competitors, but because what you promoted here is not a password manager and can’t really be used as one, I will offer my thoughts on what you will “only give your trust to.”


      1. It now uses AES instead of that home-grown monstrosity that it used prior to 2003.
      2. It is very well documented.
      3. It uses authenticated encryption through an Encrypt-then-MAC construction. (See our article on authenticated encryption and how not to get caught chasing a coyote for what that means)
      4. It was well ahead of what most others were doing in 2003. I am genuinely impressed.


      1. It hardcodes the number of PBKDF2 iterations. This was common at the time (2003) but is inappropriate now.
      2. That hardcoded number of iterations is 1000. Likewise, this was common at the time and followed official recommendations in 2003. (I have argued there are diminishing returns to increasing the number of PBKDF2 rounds beyond a certain point, but 1000 is well below that point.)
      3. Key derivation uses an eight byte salt in its default configuration. (The technical documentation fully acknowledges the collision problem that this may cause, but probably felt it was an acceptable risk back in 2003 when people didn’t have as much data as they have now.)

      Making it work

      Fortunately there is an easy way to work around those problems with that product’s key derivation: Use 1Password’s Strong Password Generator to create strong and unique passwords that you use with that tool and keep those passwords in 1Password. This way you will have unguessable passwords (obviating the PBKDF2 issues) and unique ones (obviating the salt collision issue).

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.