-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[LSP11] SocialRecovery Improvement #216
Comments
Looks very nice!
Concerning the ideas and concerns. Just a few points:
Using Zero-Knowledge Proofs (ZKPs) would be an even better solution, but they are challenging to implement in solidity and can be costly.
Glad to hear we are re-opening the LSP11 topic 🚀 |
Yes we can consider this could be one implementation among many, for a specific architecture.
Definitely agree
Yes a singleton contract would lower the barrier of entry for projects. Giving them just the need to deploy a singleton contract onchain that acts as the "backbone of the social recovery service". But there might be risk around this to be looked at. I will have a think in depth about the security concerns it and come back to the discussion. |
was rethinking of
Might need to think it though more Edit:
|
The discussion that happened yesterday with @NBR2807 covered these points:
|
Nice points were brought up!
IMO it should be the recoverer calling the recovery function (after vote of the guardians). Since he will be the recoverer i don't see any pb having him pass any calldata it wants.
Good point, even though it won't improve the security aspect. Makes sense that you may not want to expose the plan secret. Although in my opinion, we would still need to add salt and possibly address the contract we are recovering for to the recovery process to make it more robust. I am pretty sure we could add the view functions that could help with creating the hash (would just need to trust your RPC provider 😛 )
Why not have the option but not sure it should be part of the standard. Anyway, with Let's see 👍 Edit: I think for the recovery process one should use wether it wants to :
|
I have looked at the discussion thread and posted all my ideas and comments below. Firstly, I agree on the fact that LSP11 should be a standard not related directly to LSP6. Because access control could be implemented in any other form depending on the contract or dApp. (I have listed few ideas on top of my head below). How about passing some calldata to the recoverOwnership function? See for instance the two functions at the bottom of this file to see how contracts could register to the Social Recovery service (in this code, this is contract is for installing relayer addresses, but the principle is the same). How can we implement an LSP11 that interact directly with the LSP0 setData function? (Or any function really on the account that subscribed to the Social Recovery service). We could put a social recovery in front of:
Singleton pattern sounds relevant to me. Multiple services could deploy their own social recovery and compete between each other. This would enable users to register / deregister easily, or even subscribe to multiple recovery service at the same time for different purposes. Privacy of addresses could make sense, as an optional extension. For instance, social recovery of vault that hold large amount of digital value would make sense. As you don’t want the guardians to be exposed, especially if they are UPs and their UP address is publicly known. They could be « tracked » and forced to hand over the secret to recover the account so to give access to malicious users. Accepting Guardian invitation —> couldn’t we use here LSP14 (the generic standard interface) with the same functions. But the implementation actually is a contract that has multiple owners that are the guardians? So the owners / guardians are addresses that have to accept ownership on invitation. Something like this. This could be maybe an i teresting example of showing how the LSPs are composable, for different implementation (for different use cases), using the same LSP standard interfaces for interroperability. Relay Execution: maybe the recovery process might not be good to be allowed as a relay execution (although debatable? Why not?) https://docs.uniswap.org//contracts/v2/reference/Governance/governance-reference Very good point from @skimaharvey about "pluging-in" a Social Recovery services as a LSP17 Extension for instance. This could be one of many example of how this can be embedded in contracts and dApps. The salt is definitely a MUST to add imo. As this would reduce the common types of attacks around password cracking like rainbow tables 🌈. However, we should ensure that salt cannot be reused after a social recovery process completed. Otherwise, the salt becomes publicly known (by looking at the transaction on the explorer), leading attackers to be more able to brute force the secret for the subsequent recovery process. See some links about rainbow tables:
Good counter arguments here.
I cannot agree more on this. This MUST be fixed.
That’s a good question here to be looked at. We can discuss this further tomorrow in our meeting. |
The discussion that happened yesterday with @NBR2807 , @CJ42 , @skimaharvey and @b00ste covered these points:
|
Recent Discussion:
|
LSP11SocialRecovery Improvement
I would like to open a discussion on the LSP11 standard, which serves as a social recovery mechanism for users to regain access to their Smart Contracts. While this standard is fully functional, there are several aspects I believe could be improved upon to facilitate better adoption and integration with other LSPs.
Critiques
Lack of Interoperability: The current design of LSP11 fits primarily with an LSP0 owned by an LSPP6. The recovery mechanism functions through a voting system conducted by guardians, and once the secret word is provided in the
recoverOwnership(..)
function, the LSP11 contract sets LSP6 permissions on the LSP0 for the address voted for.This design limits the flexibility of the system and reduces the opportunities for interoperability. Particularly considering the recent integration of LSP20 within the LSP0, where the interaction with LSP0 became owner agnostic, we should aim to design the social recovery system in an owner-agnostic manner too.
Ideally, the social recovery system should function irrespective of the owner and the contract type, potentially not limited to an LSP0. The person elected for recovery should be able to either set LSP6 permissions on the account post-recovery, transfer ownership, set LSPXXX permissions, or maybe even execute another function.
In this way, the vote can happen based on a calldata to execute, or a hash of the calldata.
Deployment Costs: As a standard potentially useful to a wide range of users, ideally each account-contract should have an LSP11. However, the current requirement to deploy a unique contract for each account—even when using proxies—could create a significant cost barrier for companies aiming to provide social recovery options to their users.
To overcome this, we should consider redesigning the standard in a way that enables a single instance of the standard to serve as a singleton. In such a design, a single instance of the social recovery contract could serve multiple users with differing guardian settings, thresholds, and configurations according to the linked contract.
This approach would significantly reduce deployment costs and increase user adoption. If necessary, individuals who desire a unique contract can deploy a separate instance specific to their requirements, preventing the instance from being used with other accounts than the ones they specify.
Ideas and Concerns
Delays: Should there be a time range for a social recovery process that invalidates the votes of all previous guardians? Should it be part of the standard or left optional to be implemented without breaking the function specification ?
Privacy: Some of the social recovery contracts, emphasize on privacy where an account can set guardians but without revealing their addresses, in this case, the account will set a hash of the addresses, and when recovering the guardians are allowed based on their hash of addresses. This could be helpful for privacy of accounts (UniversalProfile)
Secret Word Leak: Since the standard use the secret word to recover access to the contract (either alone or with guardians), there is the possibility of having two people at the same time use the same hash, and one can reveal the plain secret before the other making the other vulnerable to be "hacked" by his guardians. Several ideas are being proposed such as double hashing, registry checking for a duplicate hash, etc .. This needs more research and opinions.
Accepting Guardian invitation: Many social recovery contracts implement the invitation mechanism, where first you invite a guardian and he should accept the invitation. I don't see the reason for implementing this mechanism, as it adds additional cost for the guardian to accept the invitation. As well, some of the contracts to be set as guardians maybe cannot execute until a certain condition is met.
Relay Execution: While it's true that providing functions that work on signed messages is good and makes the execution of a recovery frictionless, it may result in undesired action as a user can be tricked to sign a message and have this message not exposed can be executed later. This might go against the idea that the main account should have the ability of relay execution, not the targets contract. As well, in this way we need to integrate EIP-1271 as we should expect the use of smart contract accounts as guardians. To be discussed.
Cancel the recovery process: Making the account able to cancel a recovery process.
I can see the features listed above as 'standard', other custom features such as recovering based on specific logic can be implemented on top of the LSP11SocialRecovery contract. For example, a contract that works with Custom logic X for recovering can be added as a guardian for the main LSP11SocialRecovery contract.
While I see that these are lots of ideas and improvements, I don't see a reason to not implement these ideas together If they make sense, instead of standardizing several social recovery contracts with different features and interfaces which will not contribute to the Interoperability.
The text was updated successfully, but these errors were encountered: