Two accounts - now needs two different passwords every time you login?

I understand that what is happening in 1Password 8 is a big change for some people and will take some getting used to, but it is a good change. What exists for versions of 1Password prior to 8 is a bit of a mess. (It is slightly different for different platforms, but I will use 1Password 7 (and prior) on Mac as my reference example.

In the beginning there was one vault

When 1Password was first designed more than a decade ago, it supported one vault. This one vault design persisted through the Agile Keychain and OPVault formats. Accounts didn't exist back then, and so in that context "vault" and "account" were really the same thing.

And it was good. Well it was good until people wanted to share certain items with family members or colleagues. But it turns out that people do want to securely share sets of items among colleagues and family members. Who knew?

Some users found ways to cobble together some sharing techniques. These were expert users, who had a strong sense of how data synchronization worked and where data was located and how to get 1Password to read data from different locations. We cobbled together some things to support these expert users, and supported multiple vaults being unlocked at the same time.

The Primary Vault

There were no Secret Keys in these days, so there were more reasons to have different master passwords for different vaults. But most of the people who were doing this multiple vault thing, just wanted to unlock 1Password once. So what we did was designate one of their vaults as their "primary vault". Unlocking the primary vault, decrypted keys that could be used to unlock the other vaults. So for secondary vaults, you only needed to give their master password when you first set of synching to that device.

For a while we even had some UI controls so that people could select which vault would be their primary vault. This just created user confusion and didn't last long. So instead we had a complicated set of instructions that involved removing vaults and setting them back up again to switch primary vaults for the few people who wanted this. Getting master password changes to propagate in a sane way was a tricky thing for primary vaults; it it was even worse for secondary vaults.

Anyway, this worked for expert users. They might even sync some vaults over different channels than they synced other vaults. They understood the relationship among their various vaults.

1password.com

For reasons that should be clear from the above and many others, that system of synching and sharing just wasn't going to scale. It didn't have the security properties that we and our users expected and it was simply hard for people who didn't understand synching in some detail to manage. We launched the 1password.com service beta in late 2015, with full launches for families, teams, individuals throughout 2016. To make the transition as seamless as possible and support a mix of 1Password.com accounts with all of the other ways people were synching their data, we kept the notion of primary vault.

The notion of primary vault doesn't make sense when we move to well-defined accounts. And with the mix that people had, the primary could be a primary account or it could be a primary "local" vault. This was getting less coherent by the day. But we couldn't change it, given the mix of accounts and vaults that people had. Using one set of rules for accounts and another for vaults would have been more confusing.

Account password policies

Some of our customers needed to have password strength and complexity requirements on the account passwords for the members of an account. Often times, those requirements were imposed by auditors, insurers, regulators; but whatever the source and wisdom of such policies, those customers very correctly wanted to know that people were unlocking those accounts with passwords that conforms to their policies instead of through whatever people do with unlocking their primary accounts.

Even without that need, the whole notion of primary account had to die. The 1Password 8 scheme is the right approach.

No account is unlocked without its account password

Suppose you are a member of five different accounts. No account is "primary". No account contains keys that can be used to unlock the other accounts. Suppose also that you use the same account password for A, B, and D, but you use a different account password for C and E. Should C and E unlock when you only use the account password for A, B, and D? Should A, B, and D unlock if you give your account password for C? Should unlocking keys for E be buried in account A? Should we tie ourselves to a design decision that was made ten years ago for experts who were setting up tricky synching situations?

Obviously, I think that the answer to all of those rhetorical questions is "no." Just as obviously, some people who will be reading this will disagree. But if you disagree, I'd like you to think about what would make the most sense for multiple accounts if we were starting from scratch and did not have a history of unlocking through a mysterious primary account.

Making a change

Whether or not what we did with primary vaults ten years ago was a good idea at the time, it is simply not appropriate today. But yes, this does mean real changes in some people's habits and workflows. And that will be annoying. But come back after three month of using the new system and look at this discussion again. I hope that we will all find that the new behavior makes a lot more sense and feels natural and comfortable.

Using the same password everywhere seems to be go against the premise of 1Password — always use unique passwords. However, in this case, it is completely safe and we recommend it. Most of the websites either store your password or a hash of it.

1Password doesn't do that. When you type the password, it is combined with the Secret Key and then processed through the derivation function to create both encryption and authentication keys. This is a one-way operation, there is no way to obtain your account password from the authentication key.

The password never leaves you device. You can use the same account password everywhere and be 100% sure that it is safe.

Thank you @roustem. I see that in the course of the long history lesson, I forget to actually answer the question about the safety of using the same account password for multiple 1Password accounts.

Do not use a password that you use for something other than 1Password else as an account password, but the kinds of attacks against typical login passwords doesn't apply to 1Password. The (analogue of) the hash that we store is truly uncrackable (your Secret Key takes care of that) and no secrets are transmitted during sign-in (SRP takes care of that). So it is perfectly fine to put all of the accounts that you want to unlock together under the same account password.

Mixed messages

Quite honestly we would much rather not have to say, "never do X. Do X in our special case." But the alternative would have been to continue with the whole "primary vault" business, which introduces its own problems. We also try to make 1Password sign-in look familiar to people, and that means obscuring how radically different it really is from signing into a typical service. So thank you to everyone who has asked whether we are giving mixed messages and for the full story. It is an excellent question.

This seems like a really stupid decision on Agilebits' part. My wife has my 1password account in case something happens to me but I can't go through and set up all my clients' accounts to use the same password as it would violate my contracts with them.
I think the development team really didn't think this through.
It is also impossible to explain to a Board how this is secure. I always recommend 1password when I go into a new client but with the advent of version 8, I really can't do that.

The other issue is just the fact that 1password recommends using the same password across accounts will make people question the competency of the architecture. If you guys recommend this one bad practice, what did you do in the code that no one can see?

@shadcollins In your case, our recommendation would be for you to use the same password across all of the 1Password accounts you own, while each of your client's would set their own unique password for their account, which they could reuse with any other 1Password accounts they have. As @jpgoldberg discussed earlier, this is safe because each account has a unique Secret Key that is combined with the password, effectively making each password unique. In addition, our use of SRP means we do not store a representation of your password on our server, like most other companies, so an attacker cannot crack your password if they were to compromise our server.

1Password goes to great lengths to demonstrate the security of our product including providing a https://1passwordstatic.com/files/security/1password-white-paper.pdf that details how our system works and documents the shortcomings of our system. In addition, we conduct routine third-party penetration tests and regularly https://support.1password.com/security-assessments/ the results. You can read more about how we handle security https://1password.com/security/.

There is no way I can justify using a single password for all my clients, There is no way I could explain to a client that oh it isn't awful practice because you see 1password does this unique thing you have never heard of that uses a secret key and.... do you see how ridiculous this sounds?

@shadcollins I think I may be misunderstanding your particular use case. Are you creating and managing 1Password accounts for each of your clients?

@shaywood I have clients that I have put 1Password into and I have an account into their systems. I don't understand why Agilebits changed this functionality, didn't call it out as a huge red-flag related to a major change. I also don't understand how you guys/gals think telling people to set their passwords to the same thing is going to fly with an IT audit.
Before my fingerprint or Hello(Windows) would unlock things and now it doesn't. I have to log into everything individually. This is a nightmare to manage. I think the team didn't think this through at all before they decided to change everything.

I have been using this product for 11 years and I have never seen a build like this come out before.

Hi @shadcollins:

Touch ID or Apple Watch on macOS, or Windows Hello on Windows will still be able to unlock all of your accounts, but that does require that each account is unlocked first with an account password prior to being able to unlock that account using Touch ID / Apple Watch / Windows Hello after starting 1Password.

Jack