Teams and Family together?

ThomasK

What's the recommended way to get Family-type functionality if someone is already (and needs to keep) running Teams for a company? The two options[2] that spring immediately to mind are either: Run both Teams and Family at the same time, or Run only Teams, but pay for two entirely separate teams, one business, and one personal

Some questions then:

• Q1. Can Teams and Family run alongside each other at all? i.e. Can their vaults be used from within the same 1PW App? This would probably be the simplest solution, but I'm bracing to have my heart broken by hearing that it isn't possible yet.
• Q2. What can Teams do that Family can't? Even if they can run alongside each other, maybe using only Teams but paying for multiple teams is still worth considering.
• Q3. How much does Teams cost versus Family? i.e. Even if even if they can run together, and even if Teams *does* have enough extra coolness that I might feel could be useful for my non-business use, still I'm not made of money. I already know that Family is $1/person/month (with a minimum of 5 people). But although I use (and administer) Teams, I can't find out how much we're paying for it. Is it still free-because-its-in-Beta? If so, whats it going to cost. If not, where do I find pricing info, either in my own account, or on your website?

But finally, assuming the Multiple Teams option is either necessary (because Family and Team wont co-exist), or functionally desirable and financially tolerable:

• Q4. Are Multiple Teams really completely separate? That is, other than me paying for both, and having admin accounts on both, are the two team accounts at what tax people would call "arms length"?
• Q5. Are Multiple Teams actually usable from within a single 1PW app? This must be the case, surely? But I just want to check.

Thanks!

[1] I suppose technically a third could be "Run only Teams and include my family members as a Group within the overall company Team", but that's a non-starter from a legal, data security, not to mention business common-sense point of view. Another non-option would be to convert my current Team to Family and do everything in Family. I think that makes no more sense than the everything-in-one-Team option.

---

1Password Version: 6.2.1 (621001) Mac App Store
Extension Version: 4.5.5
OS Version: OS X 10.11.4
Sync Type: Not Provided

ThomasK

Sigh. What a palaver. Turns out I could answer most of the above by doing a trial of Family while Teams is active. So the answer to:

Q1. Can Teams and Family run alongside each other at all?

Is, yes, and pretty well by the looks of it. I currently have, all visible within my single 1PW app:

• One Team account for my company. It already has several users, each with at least one private vault and we have a few shared vaults as we learn
• One Family account for my personal use. I've just created it, so it has the standard one-private and one-shared values
• The original non-Team-non-Family vault or two that my wife and I have shared for years via DropBox syncing. But these will now become obsolete as they migrate to Family or Team, depending on whether they are personal or work-related

That still leaves as relevant, one of my original questions:

Q2. What can Teams do that Family can't? It's all looking good as-is, but is there anything I'm going to find Teams can do that Family cannot? I'm assuming that even though the Team/Family words appear to refer to the accounts themselves, and not the 1PW app code as I'd first though, still Teams is still Family++ (or, more accurately, Family is Teams--), yes? So what's the difference?

And it raises a new one:

Q6. Does a Team or Family subscription come bundled with the appropriate number of licenses for the 1PW app itself? And is that true for mobile version too, such as iPhone and iPad?

Jacob

Hey @ThomasK! It's nice to hear you're looking at using 1Password for your family as well. :) To answer your questions:

Q1. Can Teams and Family run alongside each other at all? i.e. Can their vaults be used from within the same 1PW App? This would probably be the simplest solution, but I'm bracing to have my heart broken by hearing that it isn't possible yet.

Yep! You can have as many Families and Teams accounts set up on your devices as you'd like. You can move things between them as well, so if you need your Gmail login in your Personal work vault, just share it over there.

Q2. What can Teams do that Family can't? Even if they can run alongside each other, maybe using only Teams but paying for multiple teams is still worth considering.

Q3. How much does Teams cost versus Family? i.e. Even if even if they can run together, and even if Teams does have enough extra coolness that I might feel could be useful for my non-business use, still I'm not made of money. I already know that Family is $1/person/month (with a minimum of 5 people). But although I use (and administer) Teams, I can't find out how much we're paying for it. Is it still free-because-its-in-Beta? If so, whats it going to cost. If not, where do I find pricing info, either in my own account, or on your website?
It's all looking good as-is, but is there anything I'm going to find Teams can do that Family cannot? I'm assuming that even though the Team/Family words appear to refer to the accounts themselves, and not the 1PW app code as I'd first though, still Teams is still Family++ (or, more accurately, Family is Teams--), yes? So what's the difference?

Well, since Teams is built for a work environment, it has a lot of functionality you simply don't need in a family one. 1Password Families is a way to use the technology we introduced with Teams at a price that’s more affordable and with features designed for families. Here are some of the specific differences right now:

• Families is less expensive (5 users for $5 instead of $25).
• Teams is priced per-user (more flexible for companies).
• Teams has fine-grained permission control.
• Teams has more advanced management capabilities.
• Teams will support custom groups.
• Teams has more storage, more days of item history, more guests. Bigger numbers in general.

As the services grow they will be more differentiated, with new features specifically intended for families as well as ones for organizations. I don't think Teams is something you'll need in a family environment, but it's up to you.

Q4. Are Multiple Teams really completely separate? That is, other than me paying for both, and having admin accounts on both, are the two team accounts at what tax people would call "arms length"?

They are indeed. You access them at different domains, get a different Account Key when you sign up, and you should be using a different Master Password for each one. You can use the same email address on as many accounts as you need though. There is no relation between the accounts aside from the email address you use, even if you move items between them.

Q5. Are Multiple Teams actually usable from within a single 1PW app? This must be the case, surely? But I just want to check.

Also yes. I mentioned that above. :)

Q6. Does a Team or Family subscription come bundled with the appropriate number of licenses for the 1PW app itself? And is that true for mobile version too, such as iPhone and iPad?

Even better, actually: Each member of the account gets access to all the 1Password apps on as many devices as they own. They can also access the account at 1Password.com anytime using their email address, Account Key, and Master Password.

Hope that helps! If you have any questions, feel free to let me know.

ThomasK

Thanks @penderworth .
And by way of follow up to my own answer to my original question:

When explaining that I'd actually got Teams and Family working together, I described my setup as having essentially three forms of vault: Team vaults, Family vaults, and the original "local" vaults. Of the latter I then said:

"But these will now become obsolete as they migrate to Family or Team, depending on whether they are personal or work-related"

However, I've changed my mind on that, for now anyway. After seeing how well the Team/Family combo was working, and how useful the extra functionality would be, and as a result preparing to gaily move everything, lock stock and barrel into one of those two vault types, I forced myself to pause to ask the inevitable questions about the safety of cloud-based passwording in general. To cut a long story short[1], in this discussion[2], the suggestion of OP @wsjndr on still using a local vault in addition to any Team or Family faults was confirmed as practicable by @rob:

"You can create a local, offline vault outside of your family account for storing personal information that you don't need to share with your family. Or, if you need to share it with family, you can use a traditional sync method like Dropbox."

I'm thinking that's a safe first step at least initially. I've been using that local-vault-plus-DB-sync method for ages anyway, but I'd assumed that in the era of Family and Teams, it was no longer useful, or maybe not even possible (i.e. I had wondered if it was about to be phased out). Well in terms of usefulness, mitigating cloud concerns (as per [1]) provides a use. And as to possibility, I'm hoping that it's simply the case that local vaults do remain a 1PW feature indefinitely. If not -- if "Local Vaults Will Remain A 1PW Feature Forever" is not already engraved in granite in the conference room used by the 1PW Powers That Be ("All Hail the 1PWPTB!"), and so if a phasing out of local vaults were ever to become even open for discussion -- then I'm hoping that the 1PWPTB ("All Hail...!") are sufficiently aware of these forums, that they would hear concerns like this, would look down with compassion on them, and would respond favorably by strangling at birth any such why-dont-we-phase-out-local-vaults nonsense!

Of course, the ideal would be if some large-brain-crypto-type could provide reassurance that cloud-based password management really is sufficiently robust against even the kind of intensive brute-forcing enabled by cloud-ishness (assuming, it goes without saying, that the user has provided a sufficiently strong master key in the first place). Maybe that really would make local vaults obsolete (although I'd still recommend you stick with the granite, for a good few years anyway). But I don't see that happening very soon, not least because no matter how secure things actually are, we small-brain-non-crypto-types are so subject to FUD in this area.

==

[1] The actual story is long-ish. But in summary it's the (far from new) concern over the extent to which having vaults out in the wild and, more to the point, more easily locatable will make us less secure by making broad-front, long-duration brute-force attacks more possible. I say "more easily locatable" because I assume that it's a lot easier for the Bad Guys to set up camp to hit [anything-and-everything-at].1password.com than it is for them to have to figure out, for every Joe User out there (or at very least for those of us who are both sufficiently able and paranoid) a potentially unique and quirky use of DropBox, or iCloud, or even some more obscure combo of things like unison, rsync, or even "well first I use an ssh tunnel for syncing, but I do it on an non-standard tunnel port which although does get forwarded through my router is only useful after the relevant listening daemon gets turned on after an authentication protocol has been negotiated, under control of a Python script I wrote myself, via another port entirely different from the the main-but-non-standardly-numbered tunneled one".

[2] In fact that discussion actually handles a different (albeit valid) concern about cloud-based password management, namely browser vulnerability. But the "solution" offered helps with my brute-force concern too.

AGAlumB

@ThomasK: Indeed. It's important to note that when you use 1Password, AgileBits never has access to your data, regardless of the setup you choose. Even with 1Password for Families/Teams, your data is encrypted on your device, so all the server ever ends up with is an encrypted blob. And since the Account Key is created locally and your Master Password is never transmitted and only known by you, no one — including AgileBits — has the means to decrypt the data. So even if someone gains access to our servers or we become compromised ourselves, whoever gets the database isn't getting anything useful.

You can read more details on how all of this works in our white paper, and don't hesitate to ask any other questions yo may have! :)

ThomasK

Thanks @brenty. That looks like good stuff. I'd just been reading Rick Fillion's blog post "How 1Password syncs changes to your Master Password", and it looks like the white paper covers that and more.

It'll be useful because my primary interest at the moment is to really understand how all this stuff is being done because although I've used 1PW for years, I'm now looking to roll Teams out to my company and the whole passwords-in-the-cloud thing is a worry I need to resolve. My main concern in my previous post wasn't about Master Key handling per se, but rather about whether or not the whole idea of the Personal vault was about to made redundant by (and so disappear because of) the advent of Family and Teams. But reading stuff like Rick's post -- and as I say I think the white paper will help even further -- made me realize that I was conflating the type and location of a vault (Personal/unsynced, Personal/synced, Family, Team) with the core security mechanisms of 1PW. The fact that those are entirely different things (I think -- I may still not be getting it fully) does not in itself render invalid my concern about passwords-in-the-cloud, but it does mean the scope of possible issues is reduced.

That said -- given that my perception of the scope for possible cloud-ish issues reduced but not yet eliminated -- I was encouraged by the favorable comparison in Understanding the Account Key of 1PW's approach vs 2FA. I guess that also applies to Personal vaults (??) but it may be what I was looking for to gain confidence about cloud-based vaults. (Given the topic, I'm not taking anyone's word for this, so I'm currently getting opinions on this from some people more clueful on this than I am.)

Thomas

ThomasK

Incidentally -- and this may be covered in the white paper, which I haven't read through in detail yet -- but one thing that might help the non-specialist (e.g. me) get faster to a reasonable understanding of some of this is to include, somewhere on your site, a good layman's explanation of the differences between the following terms (in the first three cases the example is grabbed right off the first page of the white paper, the last is from your Security page).

1. Key, as in "All cryptographic keys are generated and managed by the client on your devices..."
2. Key, as in "Your locally held Account Key means that the data we store cannot be used for cracking attempts."
3. Password, as in "We are never in the position of learning your Master Password or your cryptographic keys."
4. Password, as in "Secure Remote Password. A zero knowledge protocol that encrypts all traffic over the network...."

For you guys, that will all be as clear as crystal, but for Joe Normal (again, me), the potential for confusion, or at least confusion-inducing fear, is quite large. And it's compounded by various other adjectivized mentions of "key" throughout your documentation. For example, and picking on Rick's article only because it's fresh in my mind:

• "An AES key used to encrypt and decrypt items"
• "a key to encrypt your AES key"
• "The key that is derived from your Master Password..."
• "...the derived key..."
• Not to mention "...like leaving your house key..." but I'll let you off with that one :-)

To be clear, I don't doubt the accuracy of what's being said. And I'm pretty sure that the bottom set of quotes are all merely instances of type 1 from the first list. But I think there's enough fuzziness to throw someone whose brain is already working hard to grasp the actual mechanisms being described. When I was reading it I quickly found myself asking things like:

"So, a password can be used to create a key, but can it also be used to encrypt a key?", and
"So, a password can be used to create a key, but can a key be used to create a key?", and
"So, a key can be used to encrypt a key, but can a ...? ... well you get the message. And there was even:
"Encrypt a key? What does a key need to be encrypted for anyway? Dang, I thought I was understanding this!"

And then -- and it's possible I may have begun to have auditory hallucinations by this stage -- I started hearing things like:
"This key is your key! This key is my key! Oh wait, that's your key! No wait, it's my key!"
and at one point even

Crypto key connected to the Account Key
Account Key connected to the Password-generated key
Password-key connected to the ....
...
Now hear the word of the Teare!

I dug into it all a bit, and I think I figured it out. But it involved a bit of reading, and included a trip to Wikipedia (and even updating its entry on Keys, which I probably got right but as with all things Wikipedia, caveat lector!) so if you guys made it clear somewhere you'd be doing the world a favor.

Thomas

AGAlumB

@ThomasK: I definitely appreciate that it can be confusing. But what you seem to be asking for is a simple phrase explaining in detail how it all works, and that isn't really possible: you have have a basic description which is understandable or you can have all the gory details of exactly how everything works (literally, the math and how cryptography is applied in 1Password Families/Teams), a to z.

For example, you asked for a definition of "key", but there are many involved. This is sort of like asking how a computer works: the device you have in front of you today (or in your pocket!) is built on technologies which are built on technologies (et al) going back decades, and cryptography is similar in that it too cannot be summed up in a way that is easily digestible. It requires some knowledge about the foundation it is built on. Thus the trips to Wikipedia. ;)

Going back to "keys", though, what a key is is less important than where it comes from and how it is used. For instance, you have a key to your house. It unlocks it, to prevent someone casually walking in. That's good, right? But what if it is identical to everyone else's? Sure, you still have a key, but the lock will only keep out those who don't know theirs are identical, or don't bother trying. So what you really want is a unique key to unlock your home.

Similarly, cryptographic keys are strings used to encrypt data, and then are needed to decrypt it later. If everyone has the same one, that's not very helpful. So these are generated randomly, for example, to encrypt your vault. Great, right? But then how do you unlock it? Oh, you just have to memorize a 256-bit key. No problem! Okay, that's terrible. So instead, with 1Password, the keys used to encrypt your data are encrypted using the Master Password you choose, which you can (hopefully) remember.

That's the short version, and that takes us up until 1Password Teams/Families. But there's more. Since 1Password Teams/Families data is guaranteed to be stored "in the cloud" (that's how you're able to get to it from anywhere, after all), the possibility exists that someone other than you could gain access to it someday. Maybe the server is breached due to some heretofore-unknown security vulnerability in the server software. Who knows? If that happens, someone can download the entire encrypted database and take their time trying to brute force your Master Password to decrypt the keys (and therefore the vaults). But your Master Password is good, right? Well, we don't know that, and we're not willing to take any chances here. So instead of the Master Password alone being used, both it and the Account Key are actually used to encrypt the keys for 1Password Teams/Families data. So even if someone is able to breach the server and get the database and guess your Master Password, they don't know it. Nothing happens. They still need to guess the Account Key as well, and use both together to decrypt the keys to the vaults which hold your actual data. Better safe than sorry. And that's why I'm not the least bit concerned about storing my own sensitive data in 1Password Teams/Families.

And that really doesn't scratch the surface of how cryptography actually works, but since there's no way I can do it justice myself (I'd run out of room here, and probably gloss over some things in the process) and you're clearly interested in the subject, I encourage you to go down that rabbit hole! There are a lot of great resources, both on the internet and in the library (or bookstore), that explain how cryptography itself (not just 1Password) works. Most people really aren't that interested in going that deep, so long as their data is inaccessible to anyone they don't grant access, and that's fine. But for those of us who are curious, there's a sea of information for us to lose ourselves in. :sunglasses:

jpgoldberg

Thanks @ThomasK!

Oh, the whole using a key to encrypt a key is enough to make the mind boggle. When documenting the OPVault format, we kind of used this to help keep the various keys straight.

Each item key’s encrypted with the master key
And the master key’s encrypted with the derived key
And the derived key comes from the MP
Oh hear the word of the XOR
Them keys, them keys, them random keys (3x)
Oh hear the word of the XOR

And there is even a longer chain of keys in Families and Teams, which not only involve symmetric keys, put public/private key pairs. It's not that we are in love with, or seek out, complexity. There is actually a good reasons for every one of these layers.

As @brenty pointed out, it a password itself doesn't work well directly as a key. We need a number of a particular sort. But that is only part of the process. But first let me talk a little bit about what a key actually is.

What is a key?

Let's suppose that we are only going to encrypt the 26 letters of the English alphabet and your encryption scheme is to shift the letters a certain number of positions. Let's say that for encrypting a message, we would shift each letter three places forward in the alphabet. So a message like

Attack at day break!

Would take the A to D, the ts to w and so on producing the encrypted text

Dwwdfn dw gdb euhdn!

Note that we wrap around the end of the alphabet, so shifting y three places brings us to b.

So encrypting a message means shifting each letter a certain number of places in one direction. Decrypting the message means shifting each letter that same number in the opposite direction. So when we shift each letter of the ciphertext back three spaces we get D going to A and so on and we decrypt back to the plaintext,

Attack at day break!

Now suppose we used the same system, but instead of shifting by 3 places, we shift by 10 places. That turns our plaintext message into the encrypted message:

Kddkmu kd nkr lboku!

We can consider this whole notion of shifting as the encryption scheme, and the number that we shift by as the key. So we used the same encryption algorithm in both cases, but the first time we encrypted using the key 3 and the second time with the key 10.

The idea is that once the original message is encrypted, the only thing that needs to be kept secret is the key. The encryption scheme can be used to encrypt large messages to produce large encrypted messages. For example, we could take a deep important secret and encrypt it so that the encrypted form is

Tswwi Ryppk'c lyni mkx lo pyexn exnob dro lsvvskbn dklvo grobo ro gkc lbedkvvi cvksx li Myvyxov Wecdkbn gsdr dro mkxnvo cdsmu.

Now if our encryption scheme were sufficiently strong (this one isn't) there would be no feasible way to figure out what the original message was without the key. The key in this case is the number 10. So what we have done is turned a 125 character secret (the original message) into gibberish that is protected by a simple number. Cryptography is about turning big secrets (in terms of size of data) into little secrets (the size of the key).

The idea is that it is easier to protect small (in terms of size) secrets than big ones. So we use cryptography to turn those big secrets into smaller one.

Why so many?

Well @brenty already pointed out one reason for having different keys. The kinds of things that we use for keys are typically 77 digit numbers. The numbers are so big because we don't want the attacker to be able to try each one until they get something that works. In our shift cipher above, an attacker could simply try all 26 possible keys. So we need keys to be big enough numbers. And so because we aren't going to remember such numbers, we memorize passwords. Those need to be converted into things that can be used as keys.

The process that derives keys from things like passwords is supposed to produce keys with certain sorts of statistical properties. And we do believe that these work properly, but we don't have all of the mathematical theorems proved to completely convince us that our key derivation functions produce perfect keys. So we like to actually create keys that are completely random and just used the derived keys to encrypt the fully randomly created keys. And, of course, by using the keys derived from a Master Password to encrypt other keys we make it feasible to actually change a Master Password.

Another reason for there being so many keys is that we use keys for different sorts of operations, and we want to make sure that if one of those keys is somehow discovered it doesn't lead to the compromise of any of the other keys. In OPVault, we use one key for doing the encryption and decryption of an item and another key to verify (before decryption) that the item hasn't been tampered with. (In Families and Teams we use a different encryption scheme that allows us to use the one key to cover both functions).

In Families and Teams, you need to actually "log in:" or authenticate to our server. The secret that is used for that is not the same secret that is used for encrypting your data. Again, this is to compartmentalize things. Sometimes different keys need to have different sorts of mathematical properties.

And of course we need different keys for each vault for people to be able to share individual vaults without having to share everything. If Patty and Molly (two of my dogs) are both members of the vault that contains the password. for dog door, then they both have access to the key that encrypts the password for the dog door. But Patty also needs keys that only she has access to that Molly doesn't have access to. So Patty can decrypt the keys for her personal vault, and she can decrypt the keys for the shared vault, but she can't decrypt the keys to Molly's personal vault.

I hate to say it, but I've barely scratched the surface of why so many keys. And I promise you that we did not seek this out. (I am really pleased that where there were four keys per vault in OPVault, we've been able to use just one per vault in Families and Teams, but of course we've had to add more sorts of keys elsewhere.)