EOSIO Recovery WASM Contract

[arhag]

With PR #2893 any contract developer has the tools necessary to implement a lost password recovery feature for those accounts who choose to opt into such a feature by setting their owner permission appropriately.

This issue is about developing (and testing) a standard WASM contract for EOSIO blockchains that supports the recovery features that used to be implemented as native actions (these were recently removed).

The recovery contract needs to support two mechanisms of recovery.

One mechanism is inactive recovery. This is the situation in which the user has lost access to their keys which control access to their owner and active permissions, but no adversaries have access to such keys. (Alternatively, the user has died or has otherwise been incapacitated indefinitely, and their beneficiaries want to work with the user's recovery partner to get control of the user's account.)

In such a situation, the user (or beneficiary) needs to simply wait until both the owner and active permission of their account has not been used for over 30 days. After that precondition has been met, anyone satisfying the "recovery" permission of the account can request a change of the owner authority of the account which will go into effect after a 7 day delay. It should be possible to cancel this delayed effect any time in those 7 days with the authorization of either the owner or active permission of the user.

The second mechanism is active recovery. This is the situation in which the user has lost access to their keys which control access to their owner permission (and no adversaries have access to such keys), but the user does still have access to keys which control access to their active permission. In such a situation, the user should be able to recover access to their owner permission unilaterally (without needing to work with their recovery partner).

The user would be able to submit a transaction authorized by the active permission and delayed by at least 30 days which, when it finally goes into effect, would replace the owner authority of the account. The user could of course cancel that delayed transaction as usual with authority of the active (or owner) permission of their account.

[cipherzzz]

@arhag or @bytemaster - could you expound on the statement?

With PR #2893 any contract developer has the tools necessary to implement a lost password recovery feature for those accounts who choose to opt into such a feature by setting their owner permission appropriately.

Specifically, what is involved in a user setting their owner permission appropriately.

I would like to be able to test this recovery feature out with a recovery partner but have not found anything useful online. Thanks!

[boid-com]

More clarification on account recovery implementations would be great.

[ghost]

The problem with delayed recoveries is that non-active accounts are vulnerable to fake recoveries through major EOS applications.

For example, let an EOS based application "AppExample" become viral. If AppExample creates accounts using the app's account as a recovery partner, non-authorized users could scan the network to find which accounts created by AppExample have been inactive for 30 days or more. Then, the non-authorized user could send a recovery request to AppExample and eventually, if the real owner doesn't cancel, this user would be able to gain access into the account.

In order to prevent this from happening, recovery roles should only be given to trusted close friends and relatives. On the other hand, EOS applications such as AppExample which create accounts and set themselves as a recovery partner should include a verification method such as the classic password reset confirmation email before initiating the recovery delays.

This could also be prevented by not allowing the creator of the account to set itself as the recovery partner while setting up the user's account. However, the application could still request the user to add them as a recovery partner after creating the account and it is to my understanding that most people would allow the application to do this as they would essentially be "securing" their own accounts.

Conclusion: Poorly managed viral applications could mistakenly recover inactive accounts (not lost) to external non-authorized users if they do not ask for user verification before submitting the recovery request on the network.

[boid-com]

Thanks @enriquejr99 Is this the same method that steem/steemit uses to recover stolen accounts? It seems like a fair tradeoff to improve usability for major apps aiming for mass-adoption.

[goral09]

@enriquejr99

Then, the non-authorized user could send a recovery request to AppExample and eventually, if the real owner doesn't cancel, this user would be able to gain access into the account.

but in the very first post @arhag says:

After that precondition has been met, anyone satisfying the "recovery" permission of the account can request a change of the owner authority of the account

So it's not possible for non-authorized user to recover inactive account.