White Paper thoughts
It was cool to see/read your whitepaper. It'll be nice to see your next draft and see some other things fleshed out.
From the "Key derivation overview" onward (until the 2nd half of the whitepaper), I was mildly concerned because it's mentioned that the encryption key is bound to a user's e-mail address. The fear was that one would never be able to change their e-mail address. It would be nice to see a small section on how e-mail address changes are handled, as well as a note in that early section to referencing that, although "tightly bound", they can be changed.
Also, I'd much rather see something like Shamir's Secret Sharing used (at least as an option) to enforce a "two-man rule" than the current recovery group mechanism, so that one hacked recovery group computer doesn't release such havoc onto the whole system.
And an aside: I can't switch over until there's a Windows 7 version, so make sure that doesn't take too long. ;-)
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
Thanks @Philippe23!
I realize that the talk about the "tightly bound" email address was left more than a little bit vague. The goal is so that only the user themselves can change their email address. This is so that someone who gets control of our database can't change the email address for your account to something under their control and expect to be able to get anything useful from doing so.
It does make the change of email address procedure involve much more work for us. And at the time that that part of the paper was drafted, we didn't have such a mechanism (hence the vagueness). Now we do, and so that can be documented in future versions.
I love Shamir Secret Sharing. Indeed, we were looking at that for the way that the Master Password and Account Keys are "merged". But this would have involved us "writing our own crypto" more than we would have otherwise wished to. I hope that we can do this someday for exactly the reasons you suggest, but I must acknowledge that it isn't something that is being actively developed at this point.
Cheers,
Jeffrey Goldberg
Chief Defender Against the Dark Arts @ AgileBits0 -
Thanks for the context and insight @jpgoldberg.
I'm sure you're aware of them, but there's a library http://point-at-infinity.org/ssss/ (though it's POSIX & GPL) and a JavaScript module https://github.com/amper5and/secrets.js (MIT License). Just in case you circle back at some point. ;-)
0 -
Hey, @Philippe23 -
I'm sure that @jpgoldberg will come along and respond a bit further to your questions. I'm going to capture all of your suggestions for our white paper and create an internal issue to explain things better. We do have the ability to change the email address associated with an user, so things aren't super-tightly-bound.
There are a number of possible improvements we might make to the 1Password cloud hosted platform. I understand the need for policies such as the "Two-Person Rule" to prevent a single rogue employee, or single broken account, from having too much power. Many of the accounts we have at present are small groups of people, teams and Families, and "two-person" policies would be overly burdensome. Perhaps in the future, as accounts have more members, that would be a great idea.
I can see from your profile that you're a long-time 1Password supporter. Thanks for the great feedback and I hope we can get you the Windows 7 support you want sooner than later. It's been a pleasure working on the White Paper with Jeff and I look forward to any further comments and suggestions you may have to offer.
0 -
I should also say that we are very interested in Shamir Secret Sharing to help with "what happens if the last member of the Recovery Group gets hit by a bus".
So there are lots and lots of very useful things that can be done with Secret Sharing. It's also just really cool math as well.
0
