Should existing 1Password users store Teams master password in their vault?

I'm watching team members who are existing 1Password users walk through the Teams onboarding process. It's unclear to me and them how the Teams master password should be treated.

According to the FAQ:

If you already have a strong Master Password which you know by heart, it is safe to use that same password when you sign up for 1Password for Teams. (Of course, you can also take the opportunity to create a new one using our new Master Password Generator!)

A couple of questions:

  • If people generate a new master password for Teams using the password generator, would they want to store it in their local vault?
  • Would it possible for the onboarding flow to be opinionated and guide existing 1Password users to choose one of the two options - using existing master password or generating/saving a new one? To me, it seems like the flow assumes that the user isn't an existing 1Password user.

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

Comments

  • ssoroka
    ssoroka
    1Password Alumni

    Thanks for the excellent question!

    To answer your first question, it should be safe to store your master password in your vault, just make sure you've had enough time using it so that you don't forget it. This is something that needs to be 100% committed to memory.

    To the second question, We've been discussing this, and the advice we want to go with is that you should use your existing 1Password password if you have one, and not generate one. It doesn't make sense to have two master passwords. Also the existence of the account key used in combination with your master password makes it much more secure.

    Let me know if you need more details,
    Thanks :)

  • alsmola
    alsmola
    Community Member

    I'm wondering why existing 1Password users shouldn't use a generated password and store it in their local vault, like any other password. It seems like a more secure practice then typing the existing password in the web browser.

    Put another way, if I remember my local 1Password master password, why should I need to remember my 1Password for Teams password?

  • I think it is true that remembering your teams password in addition to a separate Master Password can be tough. It's really hard for those enrolled in multiple teams. So storing it in your local vault is valid. Just be sure to store your Teams account key somewhere too since you need both to log in to Teams on a new computer.

  • JamesHenderson
    JamesHenderson
    Community Member

    I generated a new one and now regret it. Is it possible to change my teams-master-password to be the same as my local master password? ...I cannot find an option for doing this.

  • JamesHenderson
    JamesHenderson
    Community Member

    sorry, just found the answer here

  • Glad you found it, @JamesHenderson! :smile:

  • jpgoldberg
    jpgoldberg
    1Password Alumni

    I should add that, like @JamesHenderson, I generated new Master Passwords for my various teams. And I have come to regret that. With a good primary Master Password, things work much more nicely when using the same Master Password for all your Teams.

    And as he found in How can I change the master password for 1Password for Teams?:

    You can change the master password in 1Password for Teams from the Mac desktop or iOS client applications. At the time of writing [February 2, 2016] this feature hasn't been implemented in the Windows or Android clients yet.

    In both clients, the option is in the Settings/Preferences, select Teams, then select the current Team, and there will be a Change Password option.

  • mehmetbozatli
    mehmetbozatli
    Community Member

    This is a bit confusing. Also, your comment @jpgoldberg: why do you regret it?

    I think I understand the onboarding problem, and am trying to figure it out myself...
    first part of the problem is that the teams vault set-up on a web browser, and not within 1password.
    the second part of the problem is that setting up a vault in the browser asks for a username, "team" name, generates a key, and asks for a master password.
    If you set up a new vault in the application, you are only asked to name it and give it a master password. So team vault seems like a different methodology from other 1password vaults and it's as if the "team vault" is no different than any other login.

    So the instinct is to give it a new password like other "logins" (which, oddly, is the same instinct when adding a new vault since the application prompts you for a new master pass)..
    If the recommendation is to use the same master password, then the "vaulting" system might need to be represented differently. (every real world vault has its own combination or key, which the bearer holds... no skeleton key for vaults)

    AgileBits is recommending to treat your master password as a skeleton key, and I think @alsmola is suggesting that you put the keys to the other vaults inside your biggest vault; take them out and use them to access your mini vaults when you need to...

    I don't know which is better...

    <<also, it's confusing that there is a personal vault inside the team's "account" - why do I have 2 personal vaults now, one for everything, and one for team related, but personal? I guess it makes sense from an organizational perspective, but I have to have "all vaults" selected in the application in order for both my regular, and my team personal logins to appear in 1password mini... is this meant so you have a work computer 1password app that has your team personal vault, and a home computer that has your "all vaults" - in this regards, is THIS the actual reason you want to have the same master password? so that you have access to limited logins at work or mom's house, but use the same master, so if Hans Gruber takes over your building and forces you to login to your team vault, he doesn't also see your personal vault, but feels like you've let him access everything since you've entered your master pass????!!!>>

  • AGAlumB
    AGAlumB
    1Password Alumni

    This is a bit confusing. Also, your comment @jpgoldberg: why do you regret it?

    @mehmetbozatli: My guess is because it's burdensome and — assuming he already had a perfectly secure Master Password (if anyone should, it's him) — there's no need to "change" it to something else by introducing a new one to use in its place.

    I think I understand the onboarding problem, and am trying to figure it out myself...

    first part of the problem is that the teams vault set-up on a web browser, and not within 1password.

    While it may be something that changes someday, this is by design and not really a problem at all when you take into account that your 1Password Team doesn't live in the app on your device; it lives on the server. The apps are just nice native clients to access the data which can be cached locally.

    the second part of the problem is that setting up a vault in the browser asks for a username, "team" name, generates a key, and asks for a master password.
    If you set up a new vault in the application, you are only asked to name it and give it a master password. So team vault seems like a different methodology from other 1password vaults and it's as if the "team vault" is no different than any other login.

    Ah, I think I understand now. The "problem" we're dealing with is that 1Password Teams is new and different in some ways from the 1Password you're used to. I don't think there's anything wrong with that from either perspective. But it's certainly different. Different is good though. It's what makes it easy to setup new devices (QR code? Yes, please!), to not have to deal with sync or sharing configuration, not to mention being able to access data on the website itself, to name a few advantages. None of that is possible with a local 1Password vault.

    So the instinct is to give it a new password like other "logins" (which, oddly, is the same instinct when adding a new vault since the application prompts you for a new master pass)..
    If the recommendation is to use the same master password, then the "vaulting" system might need to be represented differently. (every real world vault has its own combination or key, which the bearer holds... no skeleton key for vaults)

    This is really interesting. Some great psychological and philosophical observations! I think that the main hurdle here is the metaphor: your vaults filled with digital information do have separate keys like the real world counterparts you're describing. If they didn't it wouldn't be possible to share only one with another person; if the keys were the same, they'd have access to all of your data! But — mercifully — 1Password Teams doesn't expose the public key cryptography that makes it all work to the user.

    AgileBits is recommending to treat your master password as a skeleton key, and I think @alsmola is suggesting that you put the keys to the other vaults inside your biggest vault; take them out and use them to access your mini vaults when you need to...
    I don't know which is better...

    In the end, it depends on your needs. The only "right" answer is to protect your data with a long, strong, Master Password. Whether that's the whole thing or it is also protecting many subsidiary Master Passwords doesn't matter, so long as the first is sound and you don't give it away.

    <<also, it's confusing that there is a personal vault inside the team's "account" - why do I have 2 personal vaults now, one for everything, and one for team related, but personal? I guess it makes sense from an organizational perspective, but I have to have "all vaults" selected in the application in order for both my regular, and my team personal logins to appear in 1password mini... is this meant so you have a work computer 1password app that has your team personal vault, and a home computer that has your "all vaults" - in this regards, is THIS the actual reason you want to have the same master password? so that you have access to limited logins at work or mom's house, but use the same master, so if Hans Gruber takes over your building and forces you to login to your team vault, he doesn't also see your personal vault, but feels like you've let him access everything since you've entered your master pass????!!!>>

    Vault boundaries are useful for organization, but most importantly in the case of sharing they're crucial for security: the people you share with only get the keys to the vaults you choose and nothing else.

    This is also what I touched on above: there are two main models here. It sounds like you might simply prefer to use 1Password Teams only, without a Primary local vault. That way you'd have a single "main" Personal vault, along with any that are shared. The alternative is to maintain a Primary local vault as your "main", but it really doesn't matter so long as you find a setup that works for you. If you'd like to go more in depth with this, feel free to start a new discussion. :)

  • jpgoldberg
    jpgoldberg
    1Password Alumni

    @mehmetbozatli asked the very reasonable question:

    @jpgoldberg: why do you regret [setting up a separate Master Password for each team]?

    Well first of all in addition to my primary (local) vault, I am a member of one Family and three Teams. Not only was I trying to remember those five Master Passwords but I had to remember which one went with which. So my case may be atypical, but I think that even when it was "only three" (instead of five) I still found it burdensome.

    You are, however, absolutely correct that someone may very much wish to pick Master Passwords that are appropriate for the needs of each vault. There is, under plausible threat models, a genuine security gain in using separate Master Passwords and that is why I started out with separate Master Passwords for each. (Plus, I enjoyed playing with the wordlist password generator.)

    So if you do not find using separate Master Passwords a particular burden, then you are better off doing so. But if insisting on separate Master Passwords stops you from using 1Password as much as you ought, then it would be better to just pick one.

  • mehmetbozatli
    mehmetbozatli
    Community Member

    Thanks to you both for the replies! So another question pops up: from a security standpoint is there a difference in (a) having Master Pass^1 and storing team Master Pass^2 and ^3... in your primary vault and (b) having Master Pass^1 ^2 and ^3... be the same wordlist
    (and (c) would adding some entropy such as capitilizing one word in pass phrase between Master Passes make any real difference?)

  • AGKyle
    AGKyle
    1Password Alumni

    Hi @mehmetbozatli

    First, I'm assuming that in b) you're using the same base master password like: yarmouth spatter zeppelin ahab leprosy prithee

    Then each would have some variation like (for c): yarmouth spatter zeppelin ahab leprosy PRITHEE

    If this is not what you meant then the information below may not be relevant :)

    If you factor in the Account Key, and the base Master Password is strong then the difference there is probably going to be minor enough that it might be that the convenience aspect should be more strongly considered. I don't have the math to base this on, but if you think about it in terms of security, the Account Key is the part adding a bulk of the entropy for those Teams. Both vault types are very secure, so with sufficiently strong Master Password's, the difference factor might just be to use what is most convenient instead of what might be more secure.

    As jpgoldberg mentioned above, if having separate Master Passwords prevents you from using 1Password then it's definitely not worth the trade off, you should then take the convenience factor instead because the gains you get from using 1Password outweigh not using it.

    For the first option though, your primary vault lacks an Account Key, so, I think it's safe to say the primary vault would be the one with the least amount of entropy. It only needs 1 piece of the data, the Master Password, while the separate Master Passwords based on the same words would require both the Master Passwords and the Account Keys for each (which are all different).

    I would hazard a guess that @jpgoldberg probably has some more insight here but as busy as he is it might be awhile before he can respond, which is why I jumped in here. I also suspect that the real answer might come down to what kind of attack you're trying to prevent also.

  • lee_kai
    lee_kai
    Community Member

    After scanning this conversation, I'd just like to confirm something that seems to confuse people/me.

    1) Every team member has a different account key and master password, even if they are signing up for the same team.

    2) There is no one and only special team account key.

    3) Therefore, given that a team has multiple members and more than one admin, they can do the restore process. So there is no reason to store a master password inside your vault.

  • Hi @lee_kai,

    1) Every team member has a different account key and master password, even if they are signing up for the same team.

    Yes, correct.

    2) There is no one and only special team account key.

    Correct; the account key is for your account, not the team.

    3) Therefore, given that a team has multiple members and more than one admin, they can do the restore process. So there is no reason to store a master password inside your vault.

    That is one perspective on it, certainly. Another though is that we hear far too often from folks who have set up Touch ID access and so they do not regularly type their Master Password. As such some of them eventually forget it altogether. They may still have access to their account via Touch ID though, and could look up their Master Password if stored in their vault without going through recovery. Whether there is any real benefit to that I suppose is up to each team / team member.

    Ben

  • lee_kai
    lee_kai
    Community Member

    @Ben That makes sense! Thanks for the reply!

  • You're very welcome. :)

    Ben

This discussion has been closed.