Well spotted about the revocation and password change issue.
At the moment, the way we address this is through server policy to prevent the user with rescinded access from getting any new vault data from the server. But as you correctly note, this isn't enforced by the cryptography.
There is a technique, called "lazy encryption" by some, to manage this sort of thing. What would happen is that any time there is a password change or someone is kicked out of a vault, a new key is created for the vault and all changes and new items are encrypted with the new key. The new key will also encrypt the previous key.
With this, someone who still has an "old key" can cryptographically decrypt things that they could have before (but they could have saved those things before), but would not be able to get at new or modified data.
I spoke about this problem (as it applies to things like a password change) in my talk at PasswordsCon 2014 in Las Vegas, which should give you some idea of how long we've been thinking about this problem.
We've got some of the underlying infrastructure in place for this, but as you can obviously see we didn't get this all working by the time of the release of our beta.
But I cannot make any promises whatsoever about when it will actually be implemented.
Ah got it. I think implementing it as a server policy is fine for now.
What would be nice is to have 1password regenerate and assign new passwords for certain supported services when a user leaves a vault. Not sure about its feasibility but if implemented correctly it can be a big feature win.
Oh that would be nice. The difficulty is in keeping track of "supported services" and making sure that they haven't changed their password change forms yesterday.
Standardized password change forms would make our lives (and our customers' lives) so much easier.
It's not impossible, but it it takes a lot of maintenance, to make sure that it behaves as expected. And when you are automating password changes you really want to make sure that it does work as expected.
Agreed. The lack of standards around this makes it very challenging and the implementation will be against a constantly moving target. We all know how this ends. :)
But it can also open the door further(not that it cannot now) to have 1password team become central password store for your production environment. I can envision a 1password agent (with hsm support maybe) running on a machine to provide processes with required passwords/keys as a way to eliminate the need to store passwords on disk. If the box gets compromised, changing the password in one central location so that others pick it up can be convenient.
At the moment, the way we address this is through server policy to prevent the user with rescinded access from getting any new vault data from the server. But as you correctly note, this isn't enforced by the cryptography.
There is a technique, called "lazy encryption" by some, to manage this sort of thing. What would happen is that any time there is a password change or someone is kicked out of a vault, a new key is created for the vault and all changes and new items are encrypted with the new key. The new key will also encrypt the previous key.
With this, someone who still has an "old key" can cryptographically decrypt things that they could have before (but they could have saved those things before), but would not be able to get at new or modified data.
I spoke about this problem (as it applies to things like a password change) in my talk at PasswordsCon 2014 in Las Vegas, which should give you some idea of how long we've been thinking about this problem.
We've got some of the underlying infrastructure in place for this, but as you can obviously see we didn't get this all working by the time of the release of our beta.
But I cannot make any promises whatsoever about when it will actually be implemented.