Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing 1Password for Teams

blog.agilebits.com

Post reply on HN
Print view View original

141–150 of 151 posts

Re: Introducing 1Password for Teams

#141

Post by keeper »

jms703 wrote: post #55
AGKyle wrote: post #50

Earlier quoted context omitted.

Hey, thanks so much for that. Seriously, means a lot to come in here and know full well you're not really the right person to answer the question but give it a shot anyway and the other party is gracious enough to explain it. I will definitely be passing this along so we have some proper request information on hand. My bosses are reading this, one has even interacted in this discussion already so they're seeing this…

Recommend including LDAP integration in addition to Active Directory. With such a large Mac userbase, you're likely to have more customers using LDAP than AD.

Keeper Enterprise has AD / LDAP integration! Check us out https://keepersecurity.com/enterprise.html

Re: Introducing 1Password for Teams

#142

Post by keeper »

devonkim wrote: post #123
AGKyle wrote: post #43

Earlier quoted context omitted.

Really don't want to see anyone get down voted here for having an opinion. Different opinions are what drive conversation, so, I won't ignore your concerns here. I'm not super big on the terminology, but I assume on-prem is on-premise, meaning you'd like to self-host. If I have that correct then unfortunately I can't promise anything here. I will most definitely pass this along to our team though so that they know th…

We already use something like this product but with a vastly worse UI / UX from CyberArk. That's the kind of feature set you'll need to sell to companies that aren't already Mac users or larger than 1000 employees on a consistent basis. Unfortunately, you'll probably need to hire 5 new people per F100 customer at a minimum but if that sort of growth is what you want I assure you it's mandatory. Please try, please hel…

We're up for that task :) https://keepersecurity.com/enterprise.html Would love to hear your thoughts if you haven't already checked us out.

Re: Introducing 1Password for Teams

#143

Post by newman314 »

keeper wrote: post #140
newman314 wrote: post #110

Earlier quoted context omitted.

No, not delegated auth although 2 factor might be nice. Delegated user admin/sync would be what I'm looking for. Centralized user management along with RBAC makes it much easier to set policy.

Check out Keeper Enterprise. We have delegated auth, 2 factor, AD/LDAP sync and centralized user management with a policy engine. And much more :)

I see in your comments that you are a new user.

I have no issue checking Keeper out but two things to note:

1) It's considered good form to clearly disclose your affiliation

2) Repeatedly spamming/commenting a different product's thread isn't.

Comment once or twice. Feel free to submit your site to HN with something interesting (blog post?) and people will up vote accordingly if there is validity.

=)

Re: Introducing 1Password for Teams

#144

Post by AGKyle »

newman314 wrote: post #135
AGKyle wrote: post #129

Earlier quoted context omitted.

I actually had this idea back when I first started at AgileBits and had to really start maintaining ssh keys for work purposes. Prior to that it was mostly just side projects and my own personal stuff. Maybe we'll have to kick this one in the pants and see what we can do. No promises of course but I'll be passing this along again since I have a personal investment in that idea :) Kyle AgileBits

=) I'm the technical head for our cloud business so I've got some pretty specific ideas on how to make this more useful from a day to day operational standpoint (multi-tenant infra support has lots of interesting use cases). Feel free to ask if you want more input.

Sounds good. You're welcome to send any thoughts to me privately. My email is my first name (see the username here and remove the first two characters, ag is our shorthand for AgileBits). Then @ company name .com.

Having some information I could make sure is in our bug reporter as a feature request would certainly be nice to have around in case we did implement this at some point in the future.

Kyle

AgileBits

Re: Introducing 1Password for Teams

#145

Post by jpgoldberg »

halayli wrote: post #134
AGKyle wrote: post #132

Earlier quoted context omitted.

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 acce…

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 no…

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.

Re: Introducing 1Password for Teams

#146

Post by jpgoldberg »

halayli wrote: post #134
AGKyle wrote: post #132

Earlier quoted context omitted.

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 acce…

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 no…

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.

Re: Introducing 1Password for Teams

#147

Post by halayli »

jpgoldberg wrote: post #145
halayli wrote: post #134

Earlier quoted context omitted.

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 no…

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 pass…

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.

Re: Introducing 1Password for Teams

#148

Post by halayli »

jpgoldberg wrote: post #146
halayli wrote: post #134

Earlier quoted context omitted.

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 no…

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 wh…

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.

Re: Introducing 1Password for Teams

#149

Post by jpgoldberg »

halayli wrote: post #147
jpgoldberg wrote: post #145

Earlier quoted context omitted.

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 pass…

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.

Re: Introducing 1Password for Teams

#150

Post by halayli »

jpgoldberg wrote: post #149
halayli wrote: post #147

Earlier quoted context omitted.

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 w…

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. :)

Post reply on HN