Master passwords are now inherently online? And q's about an upgraded install
My understanding of the way 1P worked, up through version 6, was pretty simple: passwords were stored in the vault, encrypted with the master password. It was therefore safe to store the vault on line, as the encrypted data was useless to anyone else.
It's not clear to me how things stand now. As of V7, there's a "Secret Key" which is meant to stay offline. I have my problems with this scheme - it's not clear to me how my security is improved by needing an unmemorizable secret that must be stored somewhere. But more immediately, it seems that now we're expected to expose our master password to your servers. It's required to log into your web site, which means you're either storing it, or some hash of it, but in any case you're getting the clear text in flight (well, in your server, not on the wire, because https), which means anyone capturing your web server will then capture at the least the master passwords of anyone who logs in (if not the entire user base). How is this good?
When I converted to 1P V7, It seems to have created a "master password" for logging into the web service, but my old master password was retained on the Mac I was upgrading. How does that work? Vault items are encrypted on my disk with my local (old) master password, but encrypted on your server with the new password? Or something else?
I just got a new Mac and installed 1P V8 while moving things over. This 1P insists on using the master password that matches the online password. Is there some way I can change my LOCAL 1P vaults to the older master password, while leaving the online password alone, so this Mac will behave like my other Mac?
Is there a clear document that describes your current security model?
Your "Emergency Kit" is, in fact, a "steal my life" kit if anyone ever gets their hands on it. I think that at the very least you should have the ability to use key splitting to generate multiple kit parts, so that different parts can be stored in different locations (or with different third parties), allowing for a generalized n of m scheme (say, I give out key parts to all six siblings and cousins, and can reconstitute the secret key from any four parts).
1Password Version: 8.8.0
Extension Version: Not Provided
OS Version: Not Provided
Browser:_ Not Provided
Comments
-
Great questions!
It's required to log into your web site, which means you're either storing it, or some hash of it, but in any case you're getting the clear text in flight (well, in your server, not on the wire, because https), which means anyone capturing your web server will then capture at the least the master passwords of anyone who logs in (if not the entire user base). How is this good?
We use a protocol called Secure Remote Protocol. In short, while it looks like my.1Password.com is a standard authentication based website, where the credentials you enter are sent to the server and verified on the server, that is in fact not the case. The client, in this case your browser, and the server both can derive a shared session key from secrets they have that stay on either the client, or the server. In other words, neither your account password, or full Secret Key is ever sent to us.
When I converted to 1P V7, It seems to have created a "master password" for logging into the web service, but my old master password was retained on the Mac I was upgrading. How does that work? Vault items are encrypted on my disk with my local (old) master password, but encrypted on your server with the new password? Or something else?
1Password 7 unlocks using this set of rules:
- If a Primary vault exists, then it unlocks using the Master Password for that vault, regardless of what, if any, 1Password accounts are signed in
- If a single 1Password account is signed in, then it unlocks using the Master Password for that account
- If multiple accounts are signed in, then it unlocks using the Master Password of the first added account
It sounds like when you created your 1Password account, you continued to have your Primary (standalone) vault added to 1Password for Mac. This would mean that 1Password on your Mac would continue to unlock using your Primary vault password, but signing in to my.1Password.com would use the account password for your 1Password account.
Is there some way I can change my LOCAL 1P vaults to the older master password, while leaving the online password alone, so this Mac will behave like my other Mac?
Because 1Password 8 doesn't support local vaults, 1Password 8 unlocks using only your account password (the one you use on my.1Password.com) or biometry like Touch ID or Apple Watch unlock.
For a look at our security model, we have this page here: About the 1Password security model
You're more than welcome to use sharing algorithms to split your Secret Key and share it with family members, but it's important to note that if you lose access to all your devices and don't have access to your Secret Key, it cannot be reset or recovered by us. Family organizers in a 1Password Families account are able to recover their family members, so that may be an option you'd like to take as well.
Jack
0 -
Jack, thanks for the detailed response. Your analysis of my older machine is exactly correct, I believe (I still have a local primary vault, though it's now completely empty, all items migrated to your cloud). But still one thing's not clear. On that machine, when I unlock with my master password, I'm not providing the master password known to my.1password.com - instead, as you say, it's the master for my local vault. So... how is my local 1Pv7 client signed into your service? [Edit: 1p7 is clearly keeping a separate copy of the cloud password; when I changed the pw and opened 1p7 on the old mac, it immediately complained about not being able to log in, so I had to give it the new master password.]
When I asked about my local vaults in 1p8, I meant the local cache (hm, is that a false assumption?? I assumed you keep a local cache in case of network failures reaching your cloud. No?). However, in light of your use of SRP, while I'm still not thrilled with feeding my master PW to your javascript (as per a previous discussion, this is not quite as secure as a local native app), I will live with that, changing the new master PW to match the old one.
My comment about supporting keysplitting should be taken as a feature request, and I suggest that this should take priority, since it addresses a key security issue that 1password has so far ignored: the security of the "emergency kit". By supporting n of m keysplitting, you would allow customers to never have a single stealable document that completely reveals the contents of their vaults, while still allowing a means of recovery should the master PW and/or secret key be lost. (For those following along who don't know what keysplitting is, it's sort of like using a RAID to protect your key. You chop it, with redundancy added, into "m" pieces, but you can fully reconstitute it from fewer ("n") pieces.)
0 -
Hey @alexisrosen:
You're very welcome. In the situation you have with 1Password 7, 1Password 7 effectively stored a copy of your 1Password account keys encrypted with the password for your primary vault. Changing your account password means that the account keys changed as well.
To clarify, when I was referring to 1Password 8 not supporting "local vaults", what I meant in that case was standalone vaults, and I'd like to apologize for the confusion there. 1Password 8 keeps a copy of your data locally, so you can unlock 1Password, and view or edit items when you're offline, like on a plane for example.
I've shared your thoughts about using Shamir's Secret Sharing or similar to store your Secret Key with your family as a feature request. While I can't promise anything, we use feedback like yours to help inform the future of 1Password.
Jack
ref: IDEA-I-1619
0 -
Thanks.
You know, if you do implement a generalized SSS-type feature, you could use it to generate multipart emergency kits, but it could also be a useful general security feature for customers who have some file they want protected this way. Make it a menu item in the client, or a separate helper app, that just takes a file and splits it into parts, based on user choices of number of parts and number required to reconstitute. It would of course also be able to reconstitute.
However, whether you do that general feature or not, I strongly urge you to implement this for the emergency kit. It's a huge security hole in your current scheme. Not technically, but in terms of human factors, and that's just as important.
0 -
Thanks again for your feedback! 😀
Jack
0
