Master passwords of different vault when the vaults were updated to the OPVault format
Hi! I have just updated my 1password 4 app to 1password 7. I found out that when my vaults were imported into 1password 7, all data from different vaults can be got access to with the master password of the vault that I imported first. However I still want to use different master passwords for different vaults. What can I do? Thanks.
1Password Version: 7.0.532
Extension Version: Not Provided
OS Version: Windows
Sync Type: Dropbox
Comments
-
Also interested in this. I don't use separate vaults as some sort of "really super serious folders", but for separate security contexts. It's unacceptable to me that access to one grants access to all of them. I don't need my tax returns and foundational identity documents made available every time I want to log into the AgileBits forums.
I would like to be able to select which vault I'm unlocking in the unlock screen, and then unlock only that vault.
There's also, confusingly, no way to open or select vaults from the unlock screen - the open option is grayed out?
0 -
@nucleardog, @Hahaxu: Thanks for reaching out. I'm sorry for the confusion there, but this is very much by design: A single long, strong, unique Master Password is going to be easier to remember (both for the brain and the fingers) and type than multiple passwords. But, more to the point, having to juggle multiple passwords like that is the reason most people (if not all) went to 1Password in the first place. And, frankly, having to deal with a lot of passwords was how I and many others (can't speak for you, but...) ended up using such awful passwords in the first place. Having to remember and type only one means its easier to use a great one, and there's less incentive to use something weaker. And...I have to say it, but the app is called 1Password for a reason, after all! Again, I apologize if this came as a bit of a surprise to you if you'd been trying to maintain that kind of workflow for a long time, but it's not a use case we've ever designed for, and not something we want to encourage. I'm sorry that probably isn't the answer you were looking for, but that's the situation so I thought I should give it to your straight. :blush:
0 -
@brenty Thanks for the heads up.
I get the ease-of-use factor here, but I find the security tradeoff of having to memorize 2-3 (strong) passwords to be worth the added benefit for me. I guess the strongest use-case for this feature I could present is 2FA backup codes - you're basically losing the second factor if those codes or your OTP secret is stored alongside your password. And if I don't put them in my program for storing secure information, I don't know where I'd keep them. ¯_(ツ)_/¯
0 -
I get the ease-of-use factor here, but I find the security tradeoff of having to memorize 2-3 (strong) passwords to be worth the added benefit for me.
@nucleardog: I hear you, but it isn't something we can expect most people to do, so it isn't something I think we should be designing around.
I guess the strongest use-case for this feature I could present is 2FA backup codes - you're basically losing the second factor if those codes or your OTP secret is stored alongside your password. And if I don't put them in my program for storing secure information, I don't know where I'd keep them. ¯(ツ)/¯
Exactly. And you raise a good point. Certainly there are other good apps specifically for that use case, like Authy, that are both secure and potentially give you the additional property of being separate. But I say "potentially" because in order for it to truly be a "second factor" in the sense you're suggesting, you'd need to have that setup on a separate device, not on one where you even use 1Password (since your other login credentials for the site will be stored there).
And I think we also shouldn't discount what it is about TOTP that provides the security benefit: it's the ephemeral nature of one-time passwords, which can help protect against replay attacks and some person-in-the-middle scenarios. You don't actually lose that benefit by storing them in Authy on the same device as 1Password, or in 1Password itself. And I'd argue that for most people it's better to store them in 1Password because it can be secured with a single long, strong, unique Master Password, rather than having to try to secure the TOTP separately and risk getting locked out anyway. But ultimately it's a choice that each of us have to make for ourselves. Really interesting to think about. :)
0 -
I discussed a technique to handle this use case in another thread https://discussions.agilebits.com/discussion/comment/409594#Comment_409594 by using a 1Password.com family account with two family members. The normal passwords are in the shared vault accessed by both family members, and the especially sensitive passwords are in the private vault of the second user. So the first user is the one normally used, and the sensitive ones can be briefly accessed by logging into the second family account. I think of this like "sudo" in linux, to get temporary access to higher privileges that normally are kept out of reach.
Now that the Windows beta of 1P7 is coming along, I'm seriously considering going this route for myself, and I have a concrete question. Where is the account-specific secret key stored on the local device? On a Windows 7 machine is it in the browser state (like a firefox profile), or is it in the user state (like \Users\foo\AppData\Roaming\xyz )? To switch (conveniently) to the sensitive passwords do I need to launch a different browser, or do I need to switch to a different windows user account?
Can this approach work too on a mac? How about on an iOS device, or would that require manually entering/changing the secret key on each switch?
0 -
I discussed a technique to handle this use case in another thread https://discussions.agilebits.com/discussion/comment/409594#Comment_409594 by using a 1Password.com family account with two family members.
@bkh: Ah, I remember that now that I look at it again. Good stuff. Thank you. :)
The normal passwords are in the shared vault accessed by both family members, and the especially sensitive passwords are in the private vault of the second user. So the first user is the one normally used, and the sensitive ones can be briefly accessed by logging into the second family account. I think of this like "sudo" in linux, to get temporary access to higher privileges that normally are kept out of reach.
I think this is a solid approach. My only hesitation is in recommending something like this to most people. But I appreciate you sharing this since others may find it fits their needs. :sunglasses:
Now that the Windows beta of 1P7 is coming along, I'm seriously considering going this route for myself, and I have a concrete question. Where is the account-specific secret key stored on the local device? On a Windows 7 machine is it in the browser state (like a firefox profile), or is it in the user state (like \Users\foo\AppData\Roaming\xyz )? To switch (conveniently) to the sensitive passwords do I need to launch a different browser, or do I need to switch to a different windows user account? Can this approach work too on a mac? How about on an iOS device, or would that require manually entering/changing the secret key on each switch?
There are sort of two ways to accomplish this account switching. Neither of them are something we design around since 1Password is, at its core, a single user app. Sharing between multiple users is something that's important to us, but not within the app itself since that would have a ton of security and privacy implications.
So, getting back to the point here, we live in a time where we've got not only multi-user OSes, but also really great browsers (plural — wasn't always the case) that can help with this, such as:
- Create individual user accounts at the OS level and switch between those to access different 1Password accounts in the app.
- Create separate browser profiles (Chrome calls these "persons", I think) and access one or more 1Password accounts in those through the website.
Of course you can do both too, depending on your preference and workflow.
I was confused about your Secret Key question at first, but I think that's also along these lines: when you sign into a 1Password account in the app, that's stored in the user account in the OS; when you sign into the website, that's stored in the browser, and each profile has separate storage for everything. Profiles are also a great security measure to use if you don't want all of your other extensions which have access to everything you do on a webpage to also be able to see when you use 1Password to save and fill information there.
That all applies equally to Windows and macOS, but I don't believe that mobile browsers have profiles, and while I guess Android has some multi-user support now, I haven't seen it available many places, or found it to be easy to use. iOS technically has something similar, but only in educational deployments. So I'm not sure I'd really count either of those as being viable. You could use completely separate browsers though, and I find I prefer that on the desktop too, though probably just out of habit.
None of those scenarios involve manually entering the Secret Key each session, unless you check the "public computer" box to request that it not be saved. Anyway, I hope this helps. Be sure to let me know if you have any other questions! :)
0
