Limited trust survivorship.
After some searching it sounds like this is a feature request and if this is the wrong place to submit feature requests please let me know.
The goal
- If I die, my survivors will be able to eventually gain access to my accounts.
- I can have multiple survivors with different priorities, the highest priority survivor is most likely to gain access to my account.
Requirements
- No need to trust my survivors while I am still alive.
- No need to trust that my survivors have properly secured their accounts while I am still alive.
Not a requirement
- My survivors and 1Password will not collude. I accept the risk that my survivors may collude with 1Password to gain access to my account while I'm still alive.
Summary difference between LastPass and 1Password survivorship
- 1Password requires that an attacker only has transient read-only access to my email account once they have compromised a survivor's account.
- LastPass requires that an attacker gains write-access (ability to delete/prevent receipt of emails) to my email account over a period of time after they have compromised a survivor's account.
Improvements on LastPass's solution
- Support multiple means of communication when attempting to reach the account holder, rather than just email. Each additional mechanism would be opt-in, but could include email, snail mail, SMS, phone, etc. These could be value-add or add-on services for the security conscious.
The way LastPass solves this problem (high level description) is by encrypting my vault such that either I or a designated survivor can unlock it. However, LogMeIn (LastPass company) does not give my designated survivor the encrypted vault. If a survivor attempts to unlock my account, LogMeIn will attempt to contact me via email and then wait an amount of time I designated before sending the requestor the encrypted vault.
The nice thing about the LastPass system is that if my survivor's LastPass account is compromised while I'm still alive, this will not do any good unless LogMeIn colludes with the attacker and gives them the copy of my vault that is encrypted using my designated survivor's password. If they do compromise my survivor's account, they can initiate a recovery which will involve LogMeIn attempting to contact me and let me know that a recovery is in progress. If I set the recovery delay to a sufficiently long period of time, it becomes very unlikely that the attacker will succeed unless I am dead/incapacitated.
The problem with the 1Password solution to survivorship is that an attacker only needs to compromise my email and my designated survivor's last pass password. Since my designated survivors are not very good at operational security, this means that the "hard part" of such an attack is compromising access to my email, which can be done at the DNS layer, mail server layer, or local computer layer. On top of that, the attacker only needs read access to my email, they do not need write access. This means they can passively sniff email communication from AgileBits to me (which is largely unencrypted when routed over SMTP) to finish the recovery after compromising my account.
With the LastPass solution, the attacker needs to compromise my survivor's account (same with both tools) and they need to compromise my email in a way that makes it so I do not receive the recovery email for the recovery duration (e.g., 2 days, 2 weeks, etc.), but they do. This means if they execute something like a DNS attack it would need to be incredibly well timed such that I fail to notice that email to me is being re-routed and resolve the issue prior to the email coming from LogMeIn.
The LastPass solution could be further improved by adding more ways of attempting to contact me prior to releasing the encrypted vault. For example, if they tried email, snail mail, SMS, phone, etc. all in an attempt to reach me during the recovery window then an attacker would have to attack all of those communication channels in a way that I don't notice, which is incredibly difficult.
I really want to switch to 1Password and recommend it to my friends, but this and a couple other OpSec related issues are currently preventing me from doing so. In this case, 1Password is making the critically incorrect assumption that account recovery keyholders follow at least as good operational security measures as the account holder being recovered. Without that assumption, 1Password's recovery mechanism reduces to a strength that is only slightly better than "as secure as the weakest recovery account". For business use cases, assuming the account recovery team follows better OpSec than everyone else is probably a pretty reasonable thing. However, for the family use case there is almost certainly a wide range of OpSec practices followed across members, yet the data being secured by 1Password may differ in terms of criticalness across those members.
On top of that, in the business and family scenario it is possible (and potentially trivial) for a designated recoverer to gain temporary read access to the account's email, thus allowing them to do the full recovery process by themselves in a short amount of time with no opportunity for intervention.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
Hi @MicahZoltu
Thank you for taking the time to detail your thoughts on this situation. It is indeed a very important consideration, and personally I think perhaps one that arguably cannot (or should not) be completely solved by technology. Have you considered the approach of storing a copy of your Emergency Kit, complete with Master Password, in a sealed envelope with your will and other such documents with instructions regarding how / when / by whom it should be used?
Ben
0 -
The emergency kit is equivalent to writing every password I have, plus every secure piece of information I have, down on a piece of paper and then securing that piece of paper. Securing such a piece of paper to the degree necessary for the amount and type of data that I have secured by my password manager is unrealistic. Off-the-shelf home safes, for example, can be broken into in about 5-10 minutes, sometimes less by an experienced professional. Professional safes are incredibly expensive, difficult to come by and, in my research, all come with a non-removable backdoor!
I could put it in a safety deposit box, but then I need to trust the bank and ensure that my survivors have access to the box in the case of my death but not in the case of me still being alive. Unfortunately, social engineering your way into a bank safety deposit box as a survivor isn't particularly difficult; it usually just requires a death certificate (easy to acquire for a living person) and some paperwork. While some people trust their local banks and survivors with all of their assets (and in some countries that trust is well earned) there are plenty of people in the world who don't trust their local banks (for good reason!). For example, I live in a country where I don't trust my local bank to keep a safety deposit box secure.
I recognize that for some threat models, the emergency kit is fine. However, I think there are some legitimate (not mossad) threat models (particularly outside of the western world) where the LastPass solution to survivorship is significantly better than the 1Password solution to survivorship.
0 -
Thanks for the feedback @MicahZoltu. :) I agree, it certainly isn't the only or most applicable solution for every case, but I wanted to mention it in case you hadn't considered it. While I don't know of any plans to move in the same direction LastPass has taken in this regard it is a topic that comes up with some frequency and we're continuing to brainstorm possible ways in which we can help.
Speaking generally it is important to us that 1Password continues to be a system in which:
- Data is protected by encryption
- 1Password Team Members never have access or the ability to give access to someone else's 1Password data (i.e. we should be "social engineering"-proof; we can't give someone something we don't have)
- Anything that could be construed as "security theater" should be avoided, and if implemented there should be adequate warnings either in documentation or within the apps / service
Ben
0
