5 Days ago
On Thursday I wrote this post about revoking my permissions from @threespeak and how annoying it was that I couldn't actually see which account was signing my transactions. The entire ordeal ended up somewhat as a mystery. Wasn't sure why upvotes would be cast by @threespeak considering that they don't really run a curation service like that, or at least not one that I was aware of.
Turns out that post actually sent alarm bells ringing over at 3speak (wasn't sure they'd notice), so they wanted to get to the bottom of what had actually happened. I was pulled into a private Discord party line and we figured it out pretty fast on Saturday after the CTT broadcast. I was going to write a post on this back then as the issue seemed pretty pressing, but I was asked very nicely not to do that until a solution was in place, which is fair.
A recap of what happened.
- My account was casting 40% upvotes without my permission.
- My posting authority was granted to @ecency.app and @threespeak.
- I revoked authority from @ecency.app
- The upvotes coninuted.
- I revoked my authority from @threespeak.
- The upvotes stopped.
This was an extremely weird situation because @threespeak is a very trustworthy entity on Hive and they aren't even running one of these curation trains in the first place. With that in mind I felt like it was very appropriate to tiptoe around the issue and not throw any accusations around because surely something very strange was going on in the background here.
In the comments of that post
You can't daisy chain the authorities.
So @mahdiyari was in there and he's super knowledgeable about Hive core code and proved to be a quite valuable resource. Apparently we can rip a public key by running the signature of an operation through a function (which was the exact answer I was looking for in that post without even realizing it). Of course @fulltimegeek and @proofofbrain ended up downvoting the thread... which was... again weird. Seriously though what is going on here?
So my witness partner @rishi556 solved this problem almost immediately at first glance. He told me to take a look at http://hive.vote/ and see if I had signed up with that service because @threespeak was giving @steamauto posting key authority, and @steamauto is the account that hive.vote still uses from the old days.
So I headed on over to Hive.vote but it's telling me to "register" or "log-in" using Hivesigner and I immediately decide this is a dead end. I never use Hivesigner for anything (it's been years). Authorities can't be daisy chained and it's been years since I used any kind of automated curation service.
But it like... wasn't a dead end doe.
In fact... @rishi556 even found the code to back up that we absolutely can daisy-chain authorities.
So @eddiespino ran some tests to confirm.
So... mystery solved!
Authorities can be chained (like trusting friends of friends).
https://gitlab.syncad.com/hive/hive/-/blob/master/libraries/protocol/include/hive/protocol/sign_state.hpp
So this code that was authored a year ago and committed 9 months ago seems to allow recursive additions to the posting authority based on "depth". With a max depth of 2, it would seem that we are not only trusting friends of friends with our authorities, but also their friends as well.
I'm sure there is a reason for doing this and is convenient in a fair number of scenarios, but I gotta say it just seems like a bad idea. If I give my authority to @xyz account then I expect @xyz account to have my authority and no one else. I'm truly a little confused as to how @blocktrades and other Hive Core devs signed off on this.
I have to say I'd be pretty furious if I gave an alternate account of mine ACTIVE_KEY authority for @edicted not knowing that if giving ACTIVE_KEY authority on my alt to someone else would give that person full access to all my liquid funds. Isn't that the entire point of permissions? The ability to segregate and carefully pick who you trust and who you don't? A recursive depth 'solution' that can potentially exponentially expand that breadth without users realizing it seems like a disaster waiting to happen. Very much dumpster-fire vibes here. #ThisIsFine.
It looks like I gave posting authority to @steemauto in 2020.
Maybe even 2019. Only after @threespeak added them to their trusted list did the curation trail become reconnected. If I'm being honest I'm a bit floored that I was the one to find this "bug". But it's not a bug is it? Working as intended. It's right there purposefully embedded into the core code of the network... for whatever reason. And you know I'm having this vision of the future being told what the reason is, and I don't care. I just want to hear that, "yes, that was a terrible idea," and have it rolled back. Because obviously. I'd be floored if anyone was able to convince me otherwise.
It's also worth noting that in many circumstances our system of posting/active authority granting is quite clunky. Needless to say the most popular form of authority permissions are curation trains (the ability to upvote with an account). However, granting this authority[posting] also allows comments, custom-JSONs, and downvotes to be signed to the chain on that same account, which is often not something the user wants that entity to do. Authority is very much an honor-system in this regard, and the vast majority of players on Hive do indeed play by the rules because they don't want to nuke their own reputation over trifles.
So the question we have to ask ourselves is if it's really worth it to make the system we have here even more complex in order add these kinds of options to the chain. Very much on that fence on that one as I feel like I don't know enough about how Hive works on the base-level to really forge an opinion on the matter. I lean toward "it's fine the way it is" but if there's little drawback to a particular implementation then why wouldn't we change it? The devil is in the details.
Conclusion
It all makes sense. Mystery solved. @fulltimegeek's downvote on @mahdiyari is a particularly nice touch. Imagine being told how to rip the pubkey from a signature only to find out that the pubkey you ripped from a "fraudulent transaction" just so happened to be an account run by the guy that helped you figure it out. Hive has a weird sense of irony.
Posting and Active Key Authority can be chained to other accounts... twice. You've been warned. When you grant an account your posting key you're implicitly also granting it to whoever they give their posting key to, and whoever the next wave gives their posting key to as well. Again, I'm not sure how anyone on this network is cool with that, but here we are.
So don't forget to grab your torches and pitchforks and demand that this recursive expansion of the authority gets rolled back to the intended acceptable position. @threespeak isn't the only one that grants posting authority to @steemauto. @leofinance does as well, and @khaleelkazi has been informed of this situation personally by yours truly so there aren't going to be any surprises (especially because that particular hole has already been plugged).
But still it doesn't matter that one frontend fixes a small bug. I was looking at potential double-jumps the other day and it looks like @gerber might have posting-key access to every single account that gives their authority to @leofinance, and may be able to sign transactions for @leo.voter as well. Is that a problem?
Is anything bad going to happen? No, @gerber is cool... but it is not a robust and scalable solution. Eventually someone will exploit these double jumps and it will really be nobody's fault but our own. Luckily a posting key exploit wouldn't be too bad under the current infrastructure, but who knows what we might build on top of this powerful network in future years to come.
Just my two cents on the matter.
This isn't really a big deal right now but it could be a big deal one day.
To be honest maybe the curation bot even saved me money by not allowing my account to go up to 100% voting power. But I feel like the principal of the thing is more important right now, and what might happen if devs continue unknowingly building atop such foundations.
P.S.
Shoutout to everyone who participated in helping me figure this all out.
@eddiespino
@mahdiyari
@starkerz
@fulltimegeek
@rishi556
Perhaps one day I'll have enough dev experience to rival a single person in this list :D
Cheers.
Posted Using LeoFinance Alpha
This was fun and more fun because the first start of my research was done on my phone as I was eating in a Chinese restaurant.
The update by @mahdiyari worked. My mom's (@dagmardeeke) account stopped following the trail from @aliento. Her last vote following the trail vote was on Saturday, as you can see here. The two recent votes were manual.
It's good that this was solved because it would have affected many users. Now if the user has not given the posting authority to @steemauto, the trails will not be activated.
The behavior of recursive authority has always existed in Hive. Your link to the recent code is a red herring: it's just a refactor of previously existing code. You can easily see that by looking at earlier code in the repo where you can see that the constant HIVE_MAX_SIG_CHECK_DEPTH has long existed. Nonetheless, I briefly reviewed the code with the guy who wrote the code you mentioned and we confirmed to a reasonable level of certainty that the original code behaved the same way.
It's an intended behavior, and it existed in BitShares as well. I wasn't personally involved in the design of hierarchical authorities, but I vaguely remember discussions about it back in the day. The ability to indirectly delegate authority was considered an important function, since BitShares was designed to support organizations. I suppose these features aren't so important for Hive, since Hive accounts are generally just owned by individuals. But I don't think it is a good idea to change this behavior now: it is not a minor change and could have unintended consequences.
If you've given your authority to anyone else, they can always indirectly delegate your authority anyways by setting up a bot. In the end, I think the most important lesson should be that anyone who is accepting authority from a lot of other people should be very careful who they then delegate authority to.
Ah yeah I assumed it would be a minor change.
Like changing
HIVE_MAX_SIG_CHECK_DEPTHto 0 or 1.But I certainly know what it's like to rock the boat and realize you just broke a dozen other things that need fixing.
Thanks for the clarity!
It's surprising how many people on Hive don't realize this is a thing.
Yes, I meant it is not a minor change in terms of potential consequences, not in coding effort. For example, someone may be relying on this behavior (it is an intended behavior, after all) or at least planning on using it in the future. At minimum, it would require a hardfork, since we know that such transactions have already been added to the blockchain. On balance, I don't think it is worth changing.
That's fair.
I'm just over here doing my thing being overdramatic as always.
I always appreciate you coming in here to set the record straight...
And apologize for being an annoyance while producing potentially sensationalist content.
Cheers. 🍻
Is it time to introduce custom authorities? I really love that feature of EOS :o)
While it adds complexity, it also gives a lot more control over what type of permissions you are giving to others, so over time we could get rid of current dangerous "all or nothing" permission chain practices.
As I recall, I proposed the idea a long time back to other devs (at least BT ones and maybe others as well), and I don't recall there was much interest at the time. If apps devs come up with some good use cases, I don't see why not, but I think we should wait for that.
I've seen it mentioned couple of times on Mattermost, last time a year ago. The only problem I have with the idea is that I think it will be very popular (I know I'd immediately create separate authorities for each application I use), which would result in sudden increase of memory consumption, so I'd prefer we do it only after some aggressive optimizations around accounts that I've described in one of articles. Since introduction of state provider moved those optimizations from realm of "if" to "when" (with strong inclination for "soon"), I'm much more optimistic on the possibility to implement custom authorities in not too distant future. The use cases are already present - treat each application as a separate contract and only give them authority to perform actions that you want them to have. Apps would also most likely move away from attaching themselves to one of main authorities in favour of creating separate authorities for themselves. Now we have another reason - reduce depth of redirection to one. We can't do that on existing authorities, but we can on new.
@edicted
@eddiespino
@mahdiyari
@starkerz
@fulltimegeek
@rishi556
Nice job of sleuthing to all involved! This is a VERY important fact that all Hivers should be aware of.
Oh my ... pass the key will you :)
I'm a bit confortable becouse I have ever only gave authority for the posting key, and I guess many here do the same. But if it was the active key, then thing can get very serious.
Btw, a lot of hive engine tokens and games require only the posting key for transfering assets, so that can be an issue even under the curent level of development.
Good point!
They should probably change the code as that is the entire point of the active key.
But yeah it's little things like that can lead to a big problem down the road.
I could be wrong here but I think they almost exclusively use custom JSON. RIP 💀.
You are right and wrong.
Seems like you don't know yes that there is an option for custom JSON to require either either the posting key or the active key for signature. Most custom JSONs on HE that move money around require active key authority. I've actually tested this functionality myself with the API.
Yeah but I think it's because it is a hierarchical structure. Active key has all permissions except for owner permissions.
So in my mind the posting key is just a limited scope of active. If it is entirely separate there's nothing to worry about, maybe.
Also, would the "depth" parameter not apply to active? Either way there's a whole lot of trust given there.
The thing being worried about is devs creating tokens and allowing them to be transferred with posting key authority using custom JSONs.
Interesting developments. And good to see so many putting their heads together respectfully.
You missed out on the perfect opportunity to use the Cartman "Respect my authority" meme so for that I must deduct 2 points.
2 point demerit confirmed
Why don't you use Hive signer? Any particular security reasons?
Exposing one's keys to multiple places is in itself a security issue.
Hivesigner is fine I'm sure but I just try to use keychain for everything.
Eventually I'd like to see an airgap solution for active key signing.
I have no problem exposing my posting key to a lot of places.
I do that with hivesigner.
I’m glad you got to the bottom of this, it was cool seeing this come full circle. After the first post I went through and cleaned up some of my permissions as well…or at least I think I did lol - anyway yeah this was really cool I’m glad it was resolved!
So, it was just a code within a code.
Not sure of what I said there, but it's really weird to see something like that happen. I guess it's just a thing that occurs. One thing to keep in mind when following trails, but also a good point in favor of the team who managed the situation with precision and haste.
The inception of code.
Exactly.
The problem was fixed at lightning speed which was nice.
I made a Poe reference to the poem A Dream within a Dream
"That all what we live
is just code
stacked upon code"
Stellar work and reporting.
Thanks!
Does this make the proxy setting for witnesses possible?
I could set a proxy that proxies all the proxies I've got?
Voting witnesses takes active key authority, does setting a witness proxy give the receiver active key access?
Is this active key access segregated from moving funds?
Thanks for the reminder about being careful with your account security.
While I follow curation trails on my posting account when the VP is high enough, I am glad my main Hive 'wealth' resides on an account that doesn't delegate any authority and I hardly ever use it except for powering up and delegating HP.
Please help me when I login using my private key on hivesigner for giving authorisation to steemauto they want me to create new password for hivesigner but after inputting password it wont go forward please help help please help.