Sync question
I was wondering what the difference in security is when you look for example at Dashlane who only store the encrypted data on their server and no key whatsoever and 1Password where apparently a key (private key) is stored on the server?
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
Hi @RoWi69,
Thanks for taking the time to write it. We do not store either the Secret Key or the Master Password on our servers. You can read about how the Secret Key works and why it exists here:
About your Secret Key | 1Password
And you can read about our security model in general here:
About the 1Password security model
Storing the Secret Key on our servers would largely defeat the purpose of having it. :) I hope that helps!
Ben
0 -
Thanks for the quick reply, but what is the private key then that is stored on your server? Ik read that in the white paper and was a bit confused, since next to master password and secret key there's also a private key that appears to be saved on the server or am I wrong here?
0 -
Could you post the section of the white paper you’re referring to please?
Ben
0 -
Sure, I'm referring to this part:
Oscar somehow gains access to all of the data stored on the 1Password for Teams server. We don’t know how, and we certainly tried to prevent it, but nonetheless, this is the starting point for our story.
Among the data Oscar acquires is an encrypted copy of your private key. (We store that on our server so that we can deliver it to you when you first set up 1Password on a new device.) If he can decrypt that private key, he will be able to do some very bad things. Nobody (other than Oscar) wants that to happen.
Oscar will take a look at the encrypted private key and see that it is encrypted with a randomly chosen 256-bit AES key. There is no way he will ever be able to guess that. But the private key is encrypted with a key derived from your Master Password (and other stuff) so he fig- ures that if he can guess your Master Password he will be able to get on with his nefarious business.0 -
Hi @RoWi69,
That is a great question. I can assure you that the particular distinction makes no security difference. In the relevant sense we are behaving exactly like Dashlane in that neither of us are storing the key that is derived from your Master Password (and Secret Key). Note that Dashlane doesn't involve anything like our Secret Key, so I am going to have to take some shortcuts when talking about comparing the relevant portions.
Note also that anything I say about how Dashlane operates needs to be recognized as potentially mistaken and approximate.I haven't studied their processes in detail, but I do feel that I understand things well enough to be able to answer the question given, even if some of the finer details are wrong.
KEKs and KDFs
tl;dr: We do not store your key encryption key in any form, and that is the relevant comparison for the question asked.
To understand the similarities and differences with respect to the question that you asked, it becomes necessary to understand the difference between a key encryption key (KEK) and a key that is used for encrypting your data.
Your KEK is computed from your Master Password (and Secret Key) along with some non-secret information through what is called a Key Derivation Function (KDF). Our KDF involves the combination of the Master Password and Secret Key, 100,000 rounds of PBKDF2, and some other stuff. Dashlane's KDF will involve something that plays the same role as PBKDF2 (perhaps PBKDF2 itself). And their KDF will derive a KEK from your Dashlane master password.
In neither case should this KEK be stored on the server in any form. We certainly don't store it, and I presume that Dashlane doesn't do it either.
What does the KEK encrypt?
As you may have noticed, "KEK" stands for "key encryption key". It is a cryptographic key that is used for the sole purpose of encrypting some other key. So let's talk about what the KEK encrypts.
There are a number of good reasons why your data is not encrypted directly with the KEK. Instead (in the simplest case) your data is encrypted with a randomly generated key that in turn is encrypted with the KEK. Let's call call this key that is encrypted by the KEK the "master unlock key". (I don't know what Dashlane calls it, but that is what we call our internally and in our documentation). Recall that "KEK" stands for Key Encryption Key.
There are lots of practical and security reasons to not encrypt data directly with what comes out of the KDF. So that is why we (and others) will use the product of the KDF as a KEK.
Now in the simplest of cases (and 1Password's chain of keys is not the simplest of cases) your data would be encrypted by that master unlock key, which in turn is encrypted encrypted by the KEK which in turn is derived from your master password and such. Even in that simplest of cases the encrypted master unlock key will be stored somewhere. And it is going to be stored server-side (as well as potentially by clients for off-line use).
Again, I can't make claims with confidence about Dashline's security architecture, but I would be very surprised if they didn't store an encrypted master unlock key just as we do.
Now in our case that master unlock key is still not the key that encrypts your data. It encrypts a key that encrypts your private key. And your private key doesn't encrypt your data either. Instead it is needed to decrypt your vault keys. And it is your vault keys that actually encrypt your data. (Though each Document will have its own key that is encrypted by the vault key.)
Let's walk that chain of keys backwards
Working backwards, data in a vault is encrypted with a vault key. Each vault key is encrypted with your public key (and so needs your private key to decrypt), your private key is encrypted by a random key that is encrypted by your master unlock key. All of those encrypted keys live on the server (and in your own data for off-line use). But the master unlock key is encrypted by the KEK that is derived from your Master Password and Secret Key. That KEK is never stored on a server.
Our chain of keys is long, but it is no longer than necessary for the kinds of security and functions we offer. The use of a public/private key pair for dealing with vault keys allows for vaults to be securely shared among people. I expect that Dashlane also has a complex chain of keys (though probably not as complex as ours). Even in the simplest case, they should have something like our master unlock key.
I think that the difference you may be seeing in this regard, @RoWi69, is that we document the chain of keys, and so document that we have encrypted keys.
If I'm wrong
If it turns out that Dashlane is directly (with no intermediate keys) encrypting data with the output of their KDF, I would like to see how the handle certain sorts of things, such as master password changes, or their rationale for not using a randomly generated keys for encryption. But I really don't think I'm wrong. They are not stupid, and so must be using what they derive as a KEK.
0 -
Thanks for the clarification, I guess I was mistaken the public key mentioned in the story in the white paper with the master password and secret key then. You explanation makes it a lot more clear
On additional question (I think it's often asked) I'm planning to switch from using standalone to membership and with creating a family account you need to create a master password in the browser. Which of cause feels very scary.
From what I understand from other posts regarding this subject, it's not really a webpage but rather an app? Can you tell a little more on the security of creating your master password in the browser? I mean isn't it unsafe? for example if your computer is compromised and has for example a keylogger on it? I always understand that in the standalone app the input field of the app is sandboxed and cannot be logged with a key logger, but what about stuff you do in the browser?0 -
Also good questions @RoWi69!
It really is confusing that we have you do stuff in a browser and also state that all of the encryption is performed locally. And yet both are true. When you sign-in or use the 1Password service in your browser, you are downloading a program from us that gets run in your browser on your machine. The web client (as we call it) is a program much like 1Password for Windows or 1Password for Mac that runs on your machine. The principle difference is how it is delivered to you.
You are also correct that a browser operates in a hostile environment. But browser security has improved dramatically over the past decade. Some malicious content that you may have visited in one tab or window isn't going to be able to do damage to what you are doing when on other sites. The one thing to watch out for is that you limit the browser extensions you install. A malicious browser extension can be dangerous.
If you want extra precautions
What I do, though this may be more than you need or want to do, is use a different browser (and profile) for those times when I log into 1Password on the web. I tend to use Safari as my main browser, but I have a Chrome profile specifically for logging into 1Password that does not have any browser extensions in it (other than 1Password).
Again, that is not really necessarily, but if you are comfortable using browser profiles or multiple browsers, it does add an additional layer of defense.
0
