Security question about changing master password of secondary vault
The case:
I created a secondary vault with an easy password.
Then I shared the secondary vault over dropbox.
The other person changed the password of this vault via the Ipad app and added some additional items.
Afterwards I expected to need to enter the new password on my mac in order to access the secondary vault.
After entering my primary password I was able to see all the newly entered items from the vault without the need of entering the secondary password.
This feels like a huge security hole regarding secondary vaults.
1Password Version: 6.5.3
Extension Version: Not Provided
OS Version: OSX Sierra
Sync Type: dropbox
Comments
-
Hi @mike_the_brown,
Thanks for taking the time to ask us about this! I can definitely help to explain what's going on.
When you create a vault, the master password you choose encrypts a key, and that key encrypts the data in the vault. When you unlock 1Password, the master password you enter is used to decrypt the encryption key, and then that key is used to decrypt the vault. So the encryption key is what really unlocks a vault, and master passwords aren't actually stored anywhere.
When you have multiple vaults, unlocking the Primary vault automatically unlocks your secondary vaults, and it does that by using their encrypted keys. The way it works is that your 1Password vaults and the encryption keys for those vaults are all stored in a database (an SQLite file) on your Mac. There's also a copy of each secondary vault's key which is encrypted by the master password for the Primary vault. So when you unlock the Primary vault, 1Password gains access to the keys to decrypt the secondary vaults.
Now, keep in mind that a vault’s encryption keys never change. When you change the master password for a vault, it re-encrypts the same key differently, using the new master password. If that vault is syncing with Dropbox, the re-encrypted key is then copied to that vault's sync file in Dropbox. If you were you change the master password for your Primary vault, and the Primary vault syncs with other devices via Dropbox, you would need to unlock 1Password on those other devices with the old master password first. At that point, the re-encrypted key would sync, and the new master password would be required after that.
But in the case of a secondary vault, the only time you need to enter its master password is when you add that vault to 1Password on another device. You already have that secondary vault as part of 1Password on your Mac, so you don't need to enter its master password (old or new) to unlock it, because that happens automatically by using the encrypted keys stored in the SQLite database file (as I explained above). You won't need to enter the new master password for that vault on your Mac unless you delete it from 1Password and then re-add it from Dropbox.
An important thing to remember is that when you share a vault with someone else, you can't un-share it. Anyone with access to that shared vault and knowledge of its master password has the same rights to it as its original owner. You could prevent future changes from syncing to their devices by deleting the sync data or by removing them from the shared folder in Dropbox, but that wouldn't prevent them from accessing the local copy of the vault which they already have on their devices.
I hope this helps to explain how it works, but please don't hesitate to let us know if you have more questions or concerns about that. Cheers! :)
0 -
Thanx for explaining how it works. At least now I know this, I am able to manage the shared vaults safely.
But in this case I think the ability to change the password of a vault gives a false sense of security.
When someone gained access to your vault somehow, changing the passwords isn't enough - though the average user would assume it is(!). You have to create a new vault and move everything, otherwise all the potential attacker needs to do is retrieve a newer version of the vault, and he is good to go with all the sensitivities inside that vault. Unsharing the vault via dropbox is of course no secure option, that is security by obscurity. Changing the password is useless in this case.
Preventing access to further syncs is a terrible advise for the same reason. It's like hiding a document with plain text passwords for the attacker on the network.
Please help me understand the reason why you won't create a new key and re-encrypt the vault with that key the moment someone changes the password.
Why would you even provide the ability to change the password this way? This seems useless and all it does is give a false sense of security, since the main reason one changes a password is to protect it in case it is compromised.
An example case:
John Doe stored his credit card info in his private vault on the server at department. He is on the same network as his evil colleague from the IT department Mr X who happened to be in control of all the backups. John Doe has the bad habit to note his master password on a piece of paper. Mr X finds it - enters the vault and pulls out all the sensitive information to do something evil with it in the future. His colleague Mrs Teresa also finds the note and patiently explains to John Doe that this was not the smartest thing to do. The ignorant John Doe follows her advice, changed the master password and then took measures as if all the dat would be in the open (changed password etc). Phew - that was close. Then he happily saves all his updated sensitive data to his vault. You can guess what Mr X is planning.This was just as an example why I think this is a really bad way to manage passwords. It will get even more fun - being sarcastic - when someone started of with an 8 letter password. Then learned about brute force methods and changed his password to a nice long easy to remember hard to guess pass sentence. All Mr X would need is an easy to crack backup vault to crack the key and use that same key on the most recent vault to get the newest goodies out of his precious vault.
Seriously, I really can't get my head around the decision to make the process like this. Call me paranoid - but isn't that the reason for encryption anyway?
0 -
Hi @mike_the_brown,
You're correct that changing the password on the vault is not the same as rolling the keys. Unfortunately the AgileKeychain and OPVault formats were not designed with key rolling in mind, and the apps that read them wouldn't handle a change of encryption keys. This is why our recommendation for this is to actually create a new vault as opposed to simply changing the password on an existing vault.
There are other things to take into consideration. Re-encrypting everything is very expensive (we have users with very large vaults), and technically speaking re-encrypting the old contents isn't providing any additional secrecy either. If someone had access to the old vault they should be assumed to have all secrets within that vault. Re-encrypting them won't change that fact. So it's only new contents going forward that should get re-encrypted with a key the other person doesn't have.
We're still trying to find the best way of doing this.
Rick
0 -
I can understand the consideration that it is an expensive action. On the other hand, this is definitely not something that will be done often. But when you do it, you want it done right. What other reason would one have to change their password?
By changing the passwords you just make your vault more vulnerable in the case of backups. I think the least you can do is make it more clear that changing the password is not something that helps whenever your secrets are compromised. I truly was amazed when I saw the newly added secrets coming in without the need to provide some form of authentication.
Of course I can understand the argument of all your secrets being in the open, that's why it's a logical action to change any sensitive data in your vault after you re-encrypted it. If it can't be changed, you're done anyway. But changing a password gives a false feeling of being safe. In my honest opinion that is the worst thing that can happen to dedicated password software.
Why would one change the locks on his house when a burglar can still enter the house with the old key?
0 -
@mike_the_brown: That's a great question. The "house" metaphor really doesn't apply in this case though. This really comes down to the difference between authentication and encryption. It's a bit of a stretch, but the lock on the door of your house is more like authentication (thought not the same), since the contents are "plain text" and not secured in any way apart from the need to gain access to the inside. The lock is just a gatekeeper, an obstacle.
Conversely, getting "inside" your data by gaining access to the computer (or server, in the case of hosted data) is useless without the means to decrypt it. Someone could stare right at it all day long and not gain anything of value. So when you talk about "newly added secrets coming in without the need to provide some form of authentication", this simply isn't how 1Password works. It sounds like you're expecting that granting some access to a vault can be revoked. And while you can prevent them from accessing the data going forward by no longer sharing the data and password with them, you cannot retroactively prevent them from having what they already possess — in this case the contents of the vault.
And while it isn't generally a useful metaphor, there is one analogy we can make with the house/lock that is useful: If you want to keep someone out of your house who already has the key, you're probably going to make a brand new lock/key (akin to creating a new vault/password) instead of simply modifying the old one. Hopefully that makes things a bit clearer, but certainly it's not an easy subject...so we're in the same boat here. ;)
I think that your observations are reasonable, but it's important to keep a few things in mind: Changing 1Password's tried and true security architecture isn't something that should be taken lightly, and not something we're willing to do just so it's easier to conceptualize, potentially at the expense of security. If 1Password worked how most people expected (the "house" metaphor again), it simply wouldn't be secure. So while that's a bit of a sacrifice, I think that it's more important that it be secure and easy to use, since most people would rather not think about all of this in the first place.
As far as changing your password (for a website or for 1Password), you really shouldn't in most cases. There are few good reasons to do so, and it's pretty situational (for example, a website breach). One thing Rick mentioned in passing is that if you change your Master Password but still have an old copy of your vault or backups of your data around, the old one can still be used there. So no matter what we do (if we make changes to how this works in the future), that's still going to be the biggest "vulnerability" when it comes to your data and changing from a weak or compromised Master Password. I hope that helps clarify things a bit. Be sure to let us know if you have any other questions!
0 -
You both explained me the mechanics behind the scenes very well, thank you for that. The thing that bothers me is that these mechanics are not expected when there is a way to change the master password. I personally take this password as the most precious thing. I missed the alarm bells in 1Password which warned me that changing the password does not re-encrypt the vault. I think it is safe to assume the average user does not expect this.
"Conversely, getting "inside" your data by gaining access to the computer (or server, in the case of hosted data) is useless without the means to decrypt it" - Yes that is very useless. That's why I added the example case of a weak password. The rogue sysadmin would pull the old weak vault, crack the password and use the private key to decrypt newest version of that vault he is able to obtain.
I agree that changing your password is usually a bad idea, except in case of a possible breach. That is exactly the moment one does want to change his password. And of course after a possible breach I would change every secret which is possible to change inside that particular vault after re-encrypting it. I wouldn't have to rebuild the entire architecture inside that vault, which would be a nice feature.
As far as the house metaphor: The key is the private key, the lock is the encryption key, the house contains your secrets. It's unlocked by a handshake between the keys. In case of a lost key one should not have to redesign and build a house, but just get a set of new locks - encryptions keys. I expected that the vault was shared via some sort of UUID and the public key would also change when one changes it's master password. The data would be re-encrypted with the new public key and the private key would be saved which is unlocked by the new master password. The moment one regains access to your encrypted vault file (in case of a rogue system administrator and a weak password) he can not regain access to the data inside it since the old private key does not work anymore - hence the locks are changed.
This does not need to happen a lot of course, and rebuilding a vault is no problem at all when it is necessary. Though I would have appreciated some very loud alarm bells when changing the password of my private key..
0 -
I agree that changing your password is usually a bad idea, except in case of a possible breach. That is exactly the moment one does want to change his password. And of course after a possible breach I would change every secret which is possible to change inside that particular vault after re-encrypting it. I wouldn't have to rebuild the entire architecture inside that vault, which would be a nice feature.
@mike_the_brown: This is the tough thing, both to think about, and even worse, if it happens to you or someone you care about: If we agree that changing your Master Password is really necessary only in case of compromise (suspected or confirmed), then in that case I think we should assume that someone already has all of the data, including the contents and the keys to for access. And if we're in agreement on that, changing the Master Password on the existing vault doesn't change that, and the only real option is the arduous process of creating a new vault and systematically changing passwords for individual accounts stored in the old one. All of this, in no uncertain terms, sucks, but at this stage there isn't a better solution to what amounts to a whole bag of hurt for the victim in these cases. I agree that it isn't a good experience, to put it mildly, and I appreciate that you seem to care as much about this as we do. But unfortunately there just isn't a way around this, though we'll continue to work to come up with ways to make it less painless. :blush:
0
