Unlocking Multiple Vaults

mikeswimm

My experience is precisely the same as michalkulakowski. I will also add that while it is irritating and inconvenient on a desktop computer, it's completely unacceptable on a mobile device.

I'm worried that 1P employees are too close to the product to realize what a misstep this is. The product is called 1 Password. While the people at my company are irritated about it this is a non-starter for less technical folks. It has taken me years to get my parents on your platform; now, they just think your software is broken.

After months of dealing with it, I have reverted to 1P7. This issue needs to be fixed, or I will look into other options for myself and my company.

Jack.P_1P

Hi @micahbf / @mikeswimm:

I'm going to level with you both, and ask a seemingly obvious question that I'm failing to understand on my end.

From a usability perspective, is there anything different between these two scenarios:

• Account A unlocks accounts B...Z, even though accounts A....Z all have unique account passwords (we'll call them Pₐ and so on)
• Pₐ unlocks accounts A...Z, as they all have Pₐ as the account password.

From my perspective anyway, a simple mapping of "Pₐ unlocks all accounts with Pₐ" is significantly easier to understand. I don't have to remember whether I added account A or account B first on my phone compared to my laptop.

The current behavior allows for more clarity on what unlocks what. If account B doesn't have any password requirements, then it's possible to use Pₐ for both accounts A and B, resulting in the same behavior as with 1Password 7. If password strength requirements are enforced for account B, then the administrator of the 1Password account should be able to trust that the password being used for B actually does meet those standards. With the prior method, Pₐ could be significantly weaker (and in fact not meet the password requirements), but if account A was added prior to adding account B, the 1Password app would unlock with Pₐ. At minimum this goes against the spirit of enforcing the password requirement, if not the letter of that password requirement. In this case, if you wanted to use Pₐ for both accounts A and B, strengthening Pₐ to meet account B's password requirements and using it for both accounts A and B would ensure that the password strength policy is still being followed for account B, while allowing both A and B to unlock when Pₐ is used.

Jack

esquared

Simplest answer against reused "P", and as has been described before: some organizations (and people) cannot, for reasons of corporate policy or imposed (government) regulations, use the same account password for both accounts, regardless of any attempted arguments about security of accounts (e.g. given account names, secret keys, etc).

Ben

@esquared

Do they also prevent you from using the same first half of a password across accounts? 🤔 That's effectively what we're talking about here, given 1Password's security model.

Ben

mikeswimm

Hi @Jack.P_1P

The rarest of internet forum events have happened. I considered your argument, read through all of @jpgoldberg 's posts on the other thread, and agree with you. Since the accounts use keys, there isn't a difference between your two scenarios. I appreciate you taking the time to lay out the argument. I plan to unify my passwords.

If you'll humor me, I have some constructive criticism regarding how 1P handled this.

1. v8 is a significant update. No one I know likes the Electron version, and many things are very different, most notably the settings section. Now is a terrible time to make major changes to long-term functionality, as almost everyone will chalk differences up to bugs.
2. There was nothing to tell me that vault unlocking had changed. 1P could have easily detected that I was using a deprecated method and popped a message letting me know what had changed. That would have been a much better user experience.
3. When I emailed support about this issue, I got ZERO responses. Nothing. That is unacceptable for any customer, let alone a corporate customer with nearly 100 users on the account.
4. As many people have pointed out, this runs entirely counter to what non-technical people have been taught (by 1Password!) to do with different accounts. Almost no one works with keys unless they are developers and would not understand the difference.

I know the technical team is not responsible for most of those decisions. But I feel like 1Password has done an awful job of rolling this out. Many of these decisions (Electron, this change, etc.) feel like they are to the company's exclusive benefit, not the users. Given what we've all read about your ownership and funding, this trend is a little concerning for long-time users and evangelists like myself.

esquared

@Ben (and @Jack.P_1P) - Trust me when I say I understand the technical arguments (e.g. made by @jpgoldberg in this now [in]famous post) about how each password should be required for each separate vault, and that the "password" as typed by the user is only one element used to secure the content. However, to claim that we should reuse the same password for multiple accounts, even with the "only a portion of the complete password" logic is not a winning argument against corporate policies and (US) government regulations. Logic has no place, sadly, in these conversations, and there is nothing you or I can do to topple those windmills as there is no-one who will listen to such arguments. So, we are stuck.

And counter to that ideas of reused passwords, I can construct scenarios in which reusing the same password is a bad idea: what if I put my password in "trust" (safe deposit box) for my spouse in the event of my untimely demise? That's great for my spouse, but not so great for my company if I use the same password for both. Same thing in the other direction in which I grant my business partner access to my 1Password password for our company account in the event of my death - now my spouse's information is available to him. Now I trust both of them to "do the right thing", but that's not the point - there may be analogous situations where that trust is unwarranted, e.g. in a multi-client situation where you work with potentially competing clients simultaneously.

Additionally, as also noted by @mikeswimm, the entire idea of reusing the memorized portion of the password goes against everything people have been taught for years - namely, don't reuse passwords. That's the whole point of your product, in fact - use ultra-complex unique passwords for every login. So to do a perceived about-face and say, "trust us. It's ok to use the same password in this one case" is not very far off from the con-artist's or scammer's claims. For you to do so will, IMO, erode trust in your company/product.

Furthermore, since the account key or secret key, the "other half" of the complete, "true" password, is not really treated with the respect it deserves if it is really to be held securely by all parties. If it is really combined with the memorized/typed portion, then it must exist in some unencrypted form at some point, likely on one's computer, and certainly in the "emergency recovery kit" as generated by 1P itself. That makes that portion of the "whole password" much less of a password. It's just "salt" to make the decryption and collisions harder to overcome.

Finally, I appreciate the corner you (ABits collectively) have found yourselves. The "right" thing is to require all account passwords each time you unlock. I'll never disagree with that. I can even see myself agreeing that storing the keys to one vault in another vault is a bad idea. But the solution is not to suggest people use the same password for all accounts. That's against wise convention, opens individuals to liability, and simply untenable for some of us subject to rules we cannot change.

Instead, I urge you to reconsider some aspects of the UI/UX that make it uncomfortably hard to unlock each vault/account after that two-week window expires. Many suggestions have been brought up, including that 1P at least iterate through all the vaults that were open before the timeout, asking for the password for each in turn. As it stands now, I type one of the many passwords for one of my vaults, 1P unlocks that vault, but then I have to mouse and click and mouse and click (yes, several steps), just to type the password for the next vault, and then repeat, ad nausea, for additional account I need to open. And therein lies much of the frustration that many of us express.

Simply put, make the multi-vault unlock process simpler for those of us who cannot or will not reuse master passwords. Please!.

Jack.P_1P

Hi folks,

Thanks for continuing to have this discussion. Since we don't have telemetry in 1Password, feedback like this is the best way of figuring out where we could improve.

@mikeswimm:

I'm glad to hear that my explanation was able to make a difference here. As for your constructive criticism, you're absolutely right. While I've used the same account password for my accounts prior to even starting here, I can see how it would be handy to have seen a toast after unlocking to the effect of "1Password 8 unlocks differently....". How to pick an strong account password and using it for multiple accounts is something we talk a little about here and here, but you are right that we don't emphasize enough both that we recommend this, and that in this specific case, the reuse of passwords isn't a risk. I can't speak to your support experience specifically, but if you're able to share a support ID you received, I can take a closer look to see what may have happened.

ref: IDEA-I-1894

@esquared:

You're absolutely right that if in a case where there's "law" (where you can take law to be government, corporate policies, or what have you) against re-using passwords, you shouldn't reuse a password to avoid being punished by the implementers of that law. By the same token however, the unlock method of 1Password 7 seems to go against the spirit of that requirement. If access to a 1Password account has a security requirement that it be unlocked with a separate password, that should be enforced. If anything, 1Password 8 follows that restriction more strongly, as it was possible to use password123 on the first account added to the 1Password app and have that unlock all other accounts.

As for quicker unlocking of accounts B...Z after unlocking A, I've shared your feedback with the team.

ref: IDEA-I-1895

Jack

esquared

@Jack.P_1P - Thanks for the followup, but I still feel compelled to emphasize that you should not be suggesting the reuse of master passwords across accounts. That is poor form and convention breaking, regardless of any of my other arguments. It breaks the general rule against reused passwords and encourages those who don't think deeply about these things to feel like it must be ok in other situations as well.

As for the arguments that it is "secure" to do so because of the account key aspect, I still disagree with that as well. The key is not treated with the respect that a (portion of a) password requires, and that is how you treat it in your logic of password reuse.

IMO, a good adjustment to the UI/UX allows you to claim that the tool is more secure and as easy as it can be to permit the more secure model of requiring each account's (unique) password every N days...

jpgoldberg

Thank you @esquared,

You are absolutely correct that "just use the same password for your different accounts" is not something that anyone should be entirely happy with. And it is more than a bit ironic coming from us, given our stance on the evils of password reuse.

But, as I've argued and you've noted, we believe that the alternative is worse.

And my apologies to @mikeswimm. It is more than likely that I am responsible for you not getting a response to your support query. It is quite possible that queries of that form were passed to me and I dropped the ball. You are also absolutely correct that a lot of changes happened with 8. As a consequence we struggled to communicate those effectively. It is a difficult task given that different changes affect different people differently. For example, people with just one account would never notice the change in multi-account unlocking.

I think we may have to disagree on whether bundling all of these changes into one major update was a good or bad thing. From a development point of view it very much was a good thing. The big, underlying change, is that 1Password 8 is built on a common Rust core that is shared across all of our platforms. It's literally been years in the making.

Now consider the multi-account unlocking logic. Should we have introduced the new logic before 1Password 8, requiring us to build it all of the separate code bases for 1Password 7 for all of the different platforms, knowing that we are also going to be move to 1Password 8 "any day now"? Alternatively, should we have tried to build the logic that we wanted to move away from into 1Password 8 so that we could move to the fixed (and yes, we do see it as fixing something that needed to be fixed) behavior at some point after 1Password 8 is released, thus writing code and complicity into the Rust core that we knew we would be dropping as soon as we could.

What I have described is an example of the reasons from a development point of view that all of these changes came at once. And there are lots of things that are like this. There are lots of places where we didn't bring what we considered legacy behaviors to the new code base. But this doesn't take away from how this is experienced by you from a user point of view. But the development point of view isn't just about coding effort and time. If we had tried to roll out the fixed unlocking logic in all of the other platforms, we would have things working differently on different platforms for 1Password 7. All 1Password 8 apps behave the same way as each other, and so you can make your choices about your account passwords that will work across all of your devices.

By using the Rust core development structure, we can get new behaviors and features out to the different platforms much more closely to simultaneously. And this is a very good thing for users. So yes, a lot of new or changed behaviors were coded into the Rust core, and so these all came out at once, but by working this way, we should be able to reduce confusing inconsistencies in the future.

esquared

@jpgoldberg - I appreciate you providing insights into the development process, and I'll not disagree with any of your logic w.r.t. the choices you faced re: Rust core and legacy products. I'll even agree with the premise that each account's password must be provided (every N days), and that no one account is primary. If the passwords happen to match, then you can unlock all the accounts at once.

HOWEVER, you are still not addressing the elephant in the room: I (and others) cannot reuse master passwords, and the UX around unlocking multiple accounts that have different master passwords is, bluntly, absolutely terrible. As soon as I enter a password that unlocks one account, the others remain locked (assuming the passwords don't match), and I have to manually visit each account and unlock them. It's exceedingly cumbersome. I encourage you to try it with M (M>=2, ideally 3 or more) accounts with different passwords for a few months and the timeout set to, say, 1 week, and I think you'll agree.

Also, I still disagree with AgileBits' continued suggestion that people reuse passwords. Sure, it's the easy thing from your perspective, but there are at least two major issues with that from my perspective:
* the (ironic) appearance and downstream effects that would have on novice users notions of password reuse,
* the security w.r.t. the lack of respect for the account number (the other "half" of the "whole" password)

All of that is completely independent of the back-end Rust core, and even of the logic that unlocks any given account. It's entirely in the UI, and the UI is not supporting the users. As I've said elsewhere, the level of unnecessary "friction" in the UI has increased greatly from 1P7 to 1P8, and unlocking multiple accounts yet another example. Again, bluntly, the tool (1P8) doesn't support and help the user, it now forces the user to understand or at least intuit the back-end implementation to successfully accomplish tasks, thus forcing the user to conform to arbitrary and cumbersome extra steps to accomplish the same tasks that in 1P7 were fluid and simple.

Again, I'm not advocating returning to allowing any password unlock all accounts, but rather that the UI be reworked to simplify the UX when multiple accounts are being unlocked. See my suggestion in an earlier post in this topic.

timdossor

This change makes me want to stop using 1Password altogether - out of pure frustration and rage. I use older macs without biometrics, so unlocking all vaults at the same time isn't an option. I use work and personal accounts that I don't want to use the same password for. At least give the user an option of unlocking a second vault via the first.

I've been a promoter of 1Password and introduced it at work, but this is killing me.

lookitsafire

Use the same password for all your accounts AND 2FA THEM via Authenticator App, Yubikey, etc. You can have a strong password but what will keep you safe is that second factor.

AndreaBarghigiani

But still, using 2FA to open my vaults seems annoying to me because each time I need some info stored in it I will have to look for my phone, open the app and so on...

Can't they just make an option inside preferences that will unlock all vaults with the main master password and call it a day?

In a different thread I read about 'company polices' where they require you to set a different password from your personal account, thats sound great to me but still give to the company the ability to allow this kind of behaviour or at least find a way to make simplier the vault unlocks.

UX decision are up to the team but for now I am stuck in this loop:
1. open first vault with main psw
2. get other vault psw stored in main one
3. open 1 Passord
4. take the mouse and move to Vaults
5. from dropdown chose the Vault I want to open
6. rinse & repeat

TBH the points I found most annoying are 3, 4, 5 (especially 4 since I am so used to work with the keyboard 😂) and get out from Quick Access brakes the workflow.

If password and unlock all vauls at once is not a viable option, can we at least make easier to unlock one by one?

Ben

But still, using 2FA to open my vaults seems annoying to me because each time I need some info stored in it I will have to look for my phone, open the app and so on...

2FA is not required to unlock a 1Password account in our apps after initial setup. Only the initial setup of the app on each device requires 2FA.

Ben

cssmith07

Adding my voice of HUGE dissatisfaction of Version 8 with the loss of unlocking multiple vaults functionality. I upgraded 1 PC to version 8 and stopped. I will not change from Version 7 on my other PCs or iphone until this is reinstated. PLEASE listen to your user base!

(PS. 2FA is NOT the answer to the problem).

eriko

I will add my main critique is a UI problem. When the 2 weeks expires and I unlock, I get NO feedback that both vaults aren't unlocked and then there is no indication when I search for passwords that vaults are locked.

The UI/UX of this is terrible, if you don't want to change the implementation at least fix the UI: (1) let people know which vaults are locked still more prominently when searching for passwords and (2) let people unlock multiple vaults during the 2 week check in.

Dave_1P

@cssmith07

Thank you for the feedback, I see that my colleague has passed along your comments to the team from the other thread: https://1password.community/discussion/comment/676649/#Comment_676649

@eriko

We do have an internal work item open to look into how we can better surface to a user that not all accounts are unlocked after a user enters their account password to unlock one of their accounts. I've added your feedback there. In the meantime, our recommendation is that you use the same password for every account so that they all unlock at the same time: How to use multiple accounts

-Dave

ref: dev/core/core#12642

cssmith07

May I make a intermediate suggestion, that comes part way. When logging into a "secondary vault" why not allow the 1PW pop-up (fill-in option pulldown) come up at the login password stage (like happens for any other website login). See attached picture (version 8) that comes up when trying to login to the second vault. We have to type in the password. There is no ability to "select" the login password we want for that vault.

Dave_1P

@cssmith07

I'm sorry but I don't quite understand the suggestion, can you clarify a little further? What specifically would you like to see added to the 1Password 8 lock screen? You've used the phrase "second vault" but do you have multiple 1Password accounts? Are you storing the account password for one account inside of the other account?

I look forward to hearing from you. 🙂

-Dave

cssmith07

I would have to demonstrate the function. Could we do a quick zoom call where I can show my screen? Or a phone call might also help.

Dave_1P

@cssmith07

We don't offer phone or screen sharing support, could you send an email to support+forum@1Password.com? We'll be able to discuss the issue in more detail and the support team can ask you to send in a screen recording to better explain the issue. After emailing in, you'll receive a reply from BitBot, our friendly robot assistant with a Support ID that looks something like [#ABC-12345-678]. Post that here, and I'll be able to locate your message and make sure it's gotten to the right place. 🙂

-Dave

esquared

I think if you read back in the comments in this and similar threads, you'll see many suggestions for how to improve the current situation with multiple accounts and no shared password between accounts. Some of which I've written, so I know I'm biased. That said, the current situation is really as bad as @cssmith07 and @eriko describe. The fundamental problem is that there is NO feedback and no support from 1Password when requested to unlock multiple accounts. Instead, the tool opens only one account and the others remain closed, silently, and thus the user gets no feedback nor clues that there are items in other accounts that may match a search or auto-fill.

IMO, fundamentally, some number of the Dev and support teams have to subject themselves to the multiple-accounts w/ different passwords scenario to "dog food" the usability and they'll quickly see how bad the experience really is.

Dave_1P

@esquared

Thank you for the feedback. I had a conversation about this with some members of our development team last week and there is agreement internally that we can do a better job at how multiple locked accounts are presented to the user by the 1Password app. While I don't have any specific plans to share at the moment and can't make any promises, hopefully this is something that the team can improve in the future.

I won't repeat the points that have already been made by my colleagues in this thread aside to say that, for most folks, following our guidance to use the same password for all of your 1Password accounts is the best option: How to use multiple accounts

If you're unable to use the same account password for each 1Password account then it's worth mentioning that biometric unlock really helps reduce the number of times that you'll be asked to unlock each individual account using that account's password. And if, in the app's preferences, you set "Require password" to "Never" then you'll be able to extend the time between moments where you're asked to unlock each account using that account's password. Just make sure to remember your various account passwords since not typing them in regularly may result in you forgetting them over time.

Your comments are heard and appreciated by our development team. Please keep the feedback coming, it helps our developers better understand where 1Password can be improved and made into an even better experience for everyone.

-Dave

edit: Grammar.

esquared

@Dave_1P - I appreciate the comments, and am hopeful that a bit more attention to the issue will result in a better user experience. However, I really feel compelled to add a few comments in response.

First, the suggestion that we use the same (master) password across accounts simply does not work for some of us where (government) regulations, employer policy, or even just paranoia, dictate that we cannot do so. Extending the time frame between required master password entries helps, sort of, but is not a substitute for a better designed UI/UX solution.

Following on that, for any user who does not use the same master password for all accounts, the current usability of the tool is very poor, for two reasons:
- the tool does not provide any feedback when some accounts are locked and others unlocked.
- the tool does not support unlocking multiple accounts at the same time, e.g. serially.

The former you acknowledged as a problem - which is good. But the latter is really equally important to address as well. Suggestions have been made, including by me. I'll not elaborate too much more, but some I really believe that 1P needs some way to prompt for each locked account rather than just open one and silently leave the other(s) closed.

I know you'll all do your best to address this, as it can fit into the dev cycle. IMO, the best way for the tool to improve is to subject the dev-team to the problem directly. Basically, make several people have multiple accounts with different passwords, and see how much they dislike the current model.

Dave_1P

@esquared

Thank you again for the detailed feedback, it's been passed along to the development team.

-Dave

cssmith07

@Dave_1P

@esquared raises a valid point.... are the right people (development team / user experience team at 1PS) experiencing what we users are with this issue? I am aligned with @esquared that possibly not. Further, how many employees at 1PS have different accounts with the same password? I also suspect none.

I am not trying to pile on with the issue. But, for what ever reason we users are not communicating correctly the problem at hand and more importantly the impact to US, the users.

Dave_1P

@cssmith07

I can confirm that the feedback in this thread has been passed along to the internal team responsible for account unlock in the client apps and that the team is aware of the suggestions made by yourself and others.

-Dave

ref: dev/core/core#12642

amorton

I'm very mindfully piling on, finally upgraded and regret it intensely. All the other work on UI changes are wasted: the only thing I think about now that i have v8 is that it has this stupid thing where I have to enter in multiple passwords (on macos, laptop lid closed, using external monitors, no biometrics) and do more work or be less secure than previously to get the same experience.

I would happily downgrade, and will leave other devices on the old version as long as possible. I have three accounts and 1Password has changed from an useful tool to a painful part of my workflow.

Dave_1P

@amorton

Thank you for the feedback. I recommend that you use the same account password for all of your 1Password accounts, you can find more information here.

1Password 8's architecture is more secure than previous versions since no account is unlocked without its account password. When you use the same account password for all of your 1Password accounts the following remains true:

• Your account password is never sent over the network: How Secure Remote Password protects your 1Password account
• Each of your 1Password accounts are protected by both your account password and their own unique Secret Key: About your Secret Key

One of my colleagues posted more details about the security of using the same account password for each account here: https://1password.community/discussion/comment/608291/#Comment_608291

-Dave

amorton

So you are saying we should re-use passwords across accounts ? I thought avoiding that was the whole point of paying for this https://blog.1password.com/how-to-protect-yourself-from-password-reuse-attacks/