You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Had a good discussion with a friend, and came to the conclusion that the recovery system (effectively multisig) is vulnerable. If an attacker can convince M of N recovery executors that attacker is you, then attacker can effectively gain control of the identity. Educating every executor (could be tech-illiterate friends, parents, or even lazy institutions) to perfectly verify the identity of the attacker each time could be mitigated through interfaces (ie, "Before signing this request, ask the recoveree a question only they would know the answer to") but this is still imperfect.
One main solution came to mind: like a revocation certificate, one would pre-generate a signed recovery request and store it securely. Generation of a new recovery request would require full access to the identity. This makes it impossible for an attacker to arbitrarily initiate recovery. And because recovery requires initial setup anyway, this doesn't add much more complication.
Another option is to embed the identity with recovery questions where the answers generate a private key that can be used to sign a recovery request. This alleviates the burden of storage of a separate pre-signed recovery request.
The text was updated successfully, but these errors were encountered:
Had a good discussion with a friend, and came to the conclusion that the recovery system (effectively multisig) is vulnerable. If an attacker can convince M of N recovery executors that attacker is you, then attacker can effectively gain control of the identity. Educating every executor (could be tech-illiterate friends, parents, or even lazy institutions) to perfectly verify the identity of the attacker each time could be mitigated through interfaces (ie, "Before signing this request, ask the recoveree a question only they would know the answer to") but this is still imperfect.
One main solution came to mind: like a revocation certificate, one would pre-generate a signed recovery request and store it securely. Generation of a new recovery request would require full access to the identity. This makes it impossible for an attacker to arbitrarily initiate recovery. And because recovery requires initial setup anyway, this doesn't add much more complication.
Another option is to embed the identity with recovery questions where the answers generate a private key that can be used to sign a recovery request. This alleviates the burden of storage of a separate pre-signed recovery request.
The text was updated successfully, but these errors were encountered: