The security of your 1Password data depends on only one secret—your Master Password. It also depends on plenty of things that aren’t secret. For example, 1Password uses the AES encryption algorithm, every detail of which is defined by public standards; your security depends on the security of AES, but there is nothing secret about it.
Another non-secret is the design of our data format, including the Agile Keychain format and the Cloud Keychain Format. Indeed, we have a history of being very open about our data format, and this is good for your security.
Third party apps and 1Password data
Let me jump to the what has prompted this article before returning to the virtues of publicly detailing our data format. Recently there’s been progress on third party tools and applications that can read 1Password data, and there are some important factors to consider about these tools:
- Third party tools for reading 1Password data do not reflect a “break” in 1Password. They, like 1Password, require your Master Password in order to read your data.
- We have to advise you to never enter your 1Password Master Password into anything that isn’t 1Password. We aren’t casting aspersions on the integrity or competence of any developers, but we simply can’t advise otherwise.
- Third party tools are “third party”. Although we may sometimes help them understand the details of our data format, they are entirely independent of AgileBits. The fact that we may maintain a good relationship with them is not an endorsement of what they produce.
- Third party tools exemplify the fact that there is no data lock in with 1Password.
The existence of third party tools for reading 1Password data has had people ask about the security implications of us being so open about our data format. Our openness is a good thing, and here’s why.
No lock-in
Vendor lock-in, roughly speaking, is when you depend on a particular vendor to be able to use what is already yours. An example that many of us face is with ink for inkjet printers.
The manufacturers of various inkjet printers make it very hard for you to purchase ink from any other vendors. Thus, to continue using their printer, you need a supply of their ink. Not only does that get expensive, but if you spent a lot of money on the printer, you need to worry about what might happen if the vendor goes out of business and no longer provides ink. You may not be able to use your printer at all.
I have more than 1500 items in my 1Password data, and it would be absolutely catastrophic if I were to lose access to these. This is, of course, why good backups are essential and why I need a Master Password that I’m not going to forget. “Data availability” is the jargon used for this aspect of data security, and it is one that people often overlook. Years ago, I wrote about the importance of backups in “Keeping your data at your fingertips (Part I)“, then I wrote about being sure you have access to those backups. Now it’s time to talk about part II of that first article: avoiding data lock-in.
Could you lose access to your own password data if we disappeared from the face of the Earth or turned evil? We have no plans to do either, but you should know that even if the worst were to happen to AgileBits, you would still have access to your data. One of the reasons for this is that, once you have purchased a copy of 1Password, you can continue using it forever as long as you have an operating system that supports it. Our (rare) paid upgrades are optional.
The second way we avoid locking you into 1Password is through the ability to export data to a more neutral format. Not all versions are yet where we want them to be with respect to export, and we’re working on that. But there is usually some path, if not always a simple click away, to export your 1Password data.
Enabling third parties prevents lock-in
It’s this third way that we avoid lock-in that is relevant to today’s topic. Our data format design is specified well enough so that people with no connection to AgileBits can write software to be able to handle it. Of course your data remains completely unusable without your Master Password; third party software still needs you to enter your 1Password Master Password.
There are, indeed, at least two projects independent of us, which are developing software that can read 1Password data (once you’ve given them your Master Password.). James Brown (@RogueLazer) has developed some Python libraries which can – given the Master Password – read both the Agile Keychain Format (1Password 2 and 3 for Mac, 1Password for Windows) and the Cloud Keychain Format (1Password 4). Indeed, RogueLazer’s efforts and queries have led to substantial improvements in our documentation. Another project is the very recent release of the tooPasswordapp for iOS. Its developers tell me that they worked straight from our documentation. I should also add that, in its own way, the John the Ripper module for the Agile Keychain data could be called another third party tool.
Without passing any judgement on any third party developers, we have to advise people to never enter their 1Password Master Passwords into anything other than 1Password. I have no reason to doubt the integrity or competence of these third party developers, and RogueLazer’s project is even open-source. But it would be irresponsible for us to do anything other than advise you never to give your 1Password Master Password to anyone or any other application.
So while we can’t endorse those systems, and indeed we have to advise you against using them; their existence is still a Good Thing. They are proof that our openness about our data formats means that you do not have to fear data lock-in.
Kerckhoffs’ Principle: No secrets beyond the key
Kerckhoffs’ Principle states that you should assume that your adversary knows as much about the system you use as you do. This is why – despite what I may have said on April Fools Day last year – security experts are skeptical of security systems that hide the details of how they operate. They are particularly skeptical of systems that derive their security from keeping the details of how they work secret. I could go on at great length about why openness about the system improves security. Indeed, my first draft of this article did go on at great length. I’ll try to be more concise this time through.
Too Many Secrets
If the security of a system depends on the secrecy of the system (in addition to the secrecy of the key) then that secret is actually a vulnerability.
Suppose my two dogs, Patty and Molly, have developed their own security systems. Mr Talk, the neighbor’s cat, wants to break into their systems. Patty has developed hers so that all of the secrecy is in her password. Everything else about the system can be made public. The security of Molly’s system, on the other hand, depends not just on her password, but also on keeping aspects of her system design secret.
Mr Talk will study both systems very carefully. He’s very patient and will pick them apart. As he learns more about Patty’s system, it doesn’t get any weaker. After all, Patty made the details of the system public in the first place. But as Mr Talk learns more about Molly’s system, the weaker it becomes. From Mr Talk’s point of view (that of the attacker), Molly’s system has a vulnerability that is waiting to be discovered through analysis. Indeed, Molly’s system has that vulnerability by its very design.
Public scrutiny
It’s easy to use the Advanced Encryption Standard (AES) algorithm from some standard library in some software and call it secure. AES is certainly strong enough. But unless it is used in the right ways at the right times as part of the right constructions, it would probably be a mistake to call such software secure.
We do believe that we use AES, PBKDF2, HMAC and other technologies in the right ways at the right times in the right constructions. A great deal of care and research went into those sorts of decisions. But the only way for the world to share our confidence is if we document our decisions. Sure, most people aren’t in a position to directly evaluate said decisions, but everyone can take comfort in the fact that there are enough people who can, and do, look at those details.
We’ve been here before, and we’ll be here again
This isn’t the first time Kerckhoffs’ Principle has come up. I specifically discussed it when talking about creating good, strong Master Passwords, when I said that we should use a system for coming up with Master Passwords that doesn’t lose its strength if the attacker knows the system that we used. Kerckhoffs’ Principle also came up (though not by name) in discussion about how 1Password stands up to password cracking tools.
All of this is to say that Kerckhoffs’ Principle runs strong and deep through 20th and 21st century thinking about cryptography. Even if I don’t mention it by name, you should keep an eye out for it.
Jeffrey Goldberg
Principal Security Architect
Tweet about this post