[AGKyle]

When you remove a user from a team (or even a vault) the vault or team is effectively removed from the user's computer. The account will still "exist" in the preferences but it'll be suspended and their only option is to delete the account or have the admin restore the account.

Given the nature of passwords, if you've removed someone from the team you'll still want to change passwords for any items they have had access to if that's a concern.

Does that help answer your question? I'm happy to give you more information if you have more questions or if I somehow misunderstood your question. Just let me know!

Kyle

AgileBits

[halayli]

Thanks for the explanation!

While in theory the passwords should be changed, but shouldn't a new vault key also get generated/encrypted and the existing passwords get re-encrypted with the new vault key?

The case I was thinking about is: If for whatever reason that revoked user got access to an encrypted password that got added after he was revoked, he can still use the same vault key to decrypt it.

On a different note, I was trying to understand the granting access part and so far (correct me of I am wrong :)) I think it has to be done in a 3-stage process. 1. invite user, 2. user accepts and generates priv/pub and pushes encrypted priv + pub to 1password, 3. admin confirms the grant by encrypting the vault key with the new user's public key. Did I get it right?

Lastly, would it be more secure if instead of using a master vault key just rely on priv/pub key of each user. When one member adds a new password, they encrypt it with each user's public key and provide it to them (can be considered as a big disadvantage to this approach). I think it makes revocation easier and denies access to future passwords since the user will be out of the team and won't receive new passwords created. But I am not a security expert, so I won't claim anything. :)

[jpgoldberg]

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.

[halayli]

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.

[jpgoldberg]

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.

[halayli]

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.

food for thought. :)

[jpgoldberg]

For your second question boils down to "item sharing" versus "vault sharing".

Item sharing is more flexible than vault sharing, but it requires more work to see who has access to what. It also involves many more public key operations. And it makes things more complicated in finding efficient ways of actually getting things to the right individuals.

But as things develop we may switch to something more in line with what you suggest.

[halayli]

Yes, it definitely has cons and introduces complexity. But maybe if a proper REST API is built around the concept it can reduce some of the complexity at the surface.

The client will still have to encrypt for every user they need to give the password to and I don't know how expensive can this be in a large team but my assumption here is that people read passwords a lot more than write/edit them.