Hive/Steem have recovery accounts
You know this.
I know this.
Everyone knows this.
Right?
Recovery accounts set our network above the rest.
Even if your keys get stolen you can still get your account back.
Amazing!
Even more amazing is that the recovery process does not compromise security in any way.
It only adds security to the network.
There is no added attack vector for the recovery account to steal your account.
It's actually quite genius when you look under the hood.
But did you know we actually also have RESET ACCOUNTS?
Like many others here, I've seen this variable dozens of times. I always assumed it meant my account had never been reset. I always assumed if one day I needed to recover my account that this reset
variable would just store the date that my account was recovered or something like that.
NOPE!
Turns out my reset account being set to @null means I'm not using this feature.
And neither are you!
So yeah I was snooping around on the dsteem API the other day and stumbled across this:
SAY WHAT?
What does the reset_account_operation do?
Okay, so I have to assume this is a typo.
Clearly it should say reset_account
and not recovery_account
.
If this was true it would mean that any account that goes inactive for 60 days could be stolen by the recovery account... that doesn't sound right.
However when I check the official condenser API documentation (not dsteem) it says the same damn thing. Is this really a typo or can the recovery_account actually change the owner key of 60+ day inactive accounts.
This would have insane ramifications to the platform,
the biggest glaring one relating to the @darthknight/@bittrix debacle.
If the recovery account really can act as the reset account, this implies that Steemit Inc has access to these funds and can simply change the owner key of @bittrix because it has been inactive for years. @darthknight would easily be able to sue Steemit Inc and get the money back.
Still, I have to assume that this documentation is incorrect,
but I will still have to test it myself with my alt accounts.
Master key magic making
Do you guys remember this post? I discussed in depth why it would be so cool to create multiple accounts with the same master key so if anyone loses their keys you could recover it for them easily.
This reset_account feature blows that idea out of the water. All one has to do is change the reset_account from @null to whoever and that person would be able to change the keys after the 60 days of inactively went by.
Is anyone using this feature?
Seriously, go check https://hivebuzz.me/ranking
Account | reset_account |
---|---|
@freedom | @null |
@blocktrades | @null |
@darthknight | @null |
@jamesc | @null |
@theycallmedan | @null |
@ranchorelaxo | @null |
@pharesim | @null |
@roadscape | @null |
@likwid | @null |
@michael-b | @null |
Literally no one is using this feature!
This is fucking mind-blowing.
This is free security!
What happens if you die?
Wouldn't it be nice if someone you trust could recover your account?
Maybe even the lawyer handling your estate in such an event?
What if you simply lose your keys for whatever reason?
Not a typo?
Let's say the documentation is not a typo, and in the event of the reset_account being @null that makes the recovery_account the default reset_account.
This would actually be really bad, because there is an attack vector here that no one is talking about. It would obviously be much smarter for the recovery_account and the reset_account to be different accounts. This way if the reset_account stole the account in question after 60 days, the true owner could still recover said account with the help of the recovery_account.
Why didn't Steemit Inc tell us about this?
I can think of a few reasons. The main one is that a recovery account is a feature that only adds security. The reset_account provides an attack vector to steal accounts that go inactive. This would be an obvious reason to not use reset accounts.
Another reason not to use them would be because if Steemit Inc set themselves as the reset account, they could theoretically become liable for the accounts that went inactive. Technically those accounts would fall under their control, and the legality of certain situations resulting from that dynamic would be highly questionable.
Conclusion
I'm learning more about Hive every day.
It's pretty crazy.
We've all been told that accounts can not be recovered if you lose the keys.
Apparently, even this is a lie.
With reset accounts, we actually can recover accounts that lost their keys.
And no one seems to be using this feature... mind blowing.
I'll be testing this more in the days to come.
Very interested to see what the results of your investigation yield.
Will this be an enormous uncovering? Could be.
The accounts that were frozen, might be able to use the reset to get around what Sun did.
Posted Using LeoFinance
I was thinking the same thing... although I don't think that will work because changing the owner key doesn't really stop the network from freezing the account in question.
I think the only option is for the frozen accounts to sue Steemit Inc.
Steem will be deemed a security.
It's going to get ugly.
Steem is indeed a security by the same criterion Ethereum was not deemed a security by the SEC. Ethereum is decentralized. (Steem is not) Some high-ranking official of the SEC, Hinkley or something, said it in an interview.
All the shit Sun is pulling on Steem could come and bit him in the ass in the future...
I agree, and when everyone realizes it's possible for him to do all those things on Tron, Tron will be ruled a security as well. He's going to get double jacked.
I'd love to see that midget tyrant's empire collapse under its own weight! 😁
Just resteemed this post, thanks bro.
Posted Using LeoFinance
pretty amazing and strange as well that no one is using this feature and every one is just believing what the platforms are saying even though this feature to recover the account is provided by these platforms, thanks buddy keep research on hive and steem and plz do share with us like you have shared this, following you is really very useful for me
Like you, I was confused by the process when I was looking to change my recovery account. I wanted to look it up but lack of time has been a challenge. What you’ve come up with is definitely interesting, knowing Ned I’m not entirely sure it was a legal thing. Guy was a snake I bet it was a steal your shit kind of thing.
Dan though, I would be interested to see if he brought this same thing over to EOS.
This feature happened on HF11,
I'm not sure what the timelines are here.
When did @dan leave?
Hf16 or 17, I think.
You can see in one of the pics I posted the documentation says HF11...
Oh... you mean dan left at HF16?
Didn't realize he stuck around that long.
He was still here when I got here, and I got here just before 16.
I think he may have left over the changes in 17, but my memory slips some.
That would be a great feature, I got some lost accounts.
That was before my time, I have no idea. If it was something introduced, that's suspicious! It's a thin line of being great but also being insidious.
Have you figured out how to set a reset account?
Great insight mate and I must say I didn't know how the recovery account would work and now to hear there is also reset account. This says that HIVE has good bones and is for us to make the most of it!
I intrepret this a little differently.
after 60 days inactivity, the recovery account can set your account ownership to the reset account. In this case it is null. So null will own you lr account.
However, I assume setting it to null means the feature is disabled.
it could be useful if you accidentally lose your keys and were fortunate to choose someone competent and trustworthy to help.
I do not interpret it this way.
The Owner Authority is being changed to a new Owner Authority.
This means the Owner key is being changed.
If what you said is true you wouldn't need to generate a new key,
yet the documentation clearly states the need for an AuthorityType (this is a key)
Well if that is correct, it is much too dangerous to use unless you are your own recovery account which eliminates most use cases anyway. However, there is still a need for a new key and it would work similar to account recovery, except recent owner key wouldn't be necessary.
To clarify, the way I think it should work is if inactive for 6 months, 'owner key' change is permissible by 'reset account' with confirmation from 'recovery account'. 'reset account' would send 'recovery account' a 'public owner key', however unlike recovery account procedure, an existing 'private owner key' that was valid within past 30 days wouldn't be required.
The reason why the recovery account would be required to provide confirmation is if the inactive account was reported as stolen. Also, the recovery account could at least try and contact the inactive person to see if they are alive and agree.
Using the reset account on an alt account would work very well.
You could even save the owner key of the alt account on the cloud.
If you ever lost your keys you could recover your main account with the dummy alt account.
that's a good idea. I'd probably want to share this with a close relative, too. Or there is a service with google that emails various people if you go inactive there. I've set it up with some instructions, but nothing too risky like a private key.
Solid observation. Thanks for the note.
Bookmarked.
Will have to check this out.
It was announced in this post as road map for Fork 0.15:
Seems it was never implemented fully...
At the same time, this does open up to business opportunities.
Indeed, all of the frontends that create accounts (like Splinterlands) can now offer full-fledged account recovery even if the keys are lost.
i look forward to your test results. I wonder if after a reset would the post still be there, or would they be gone? Common sense says they would still be there, but one never knows with hidden tools.
In literally mind blown after reading all of this 🤯
You are digging deep.
I have an account with lost keys. I only have posting and memo key.
Posted Using LeoFinance
Wow amazing, we all need to look into this