RE: LeoAuth Login Method Update | Security and LocalStorage vs. Cookies

Hey @rishi556,

I completely understand your concerns and where you are coming from. I also appreciate that you took the time to come here and give your candid feedback. As many know, I am big on feedback and always doing better - especially in the face of any missteps. As it was built by the LEO team, I understood our session creation (based on Cookies) system as being as secure or possibly better than the SessionStorage-based system.

First, I want to acknowledge that you’re absolutely right in saying that sending private keys over the network—even temporarily—introduces potential attack vectors. Whether it’s through intentional storage, misconfigured logging, third-party services like Cloudflare, or network-level interception, there are real risks that users should be aware of when interacting with any platform that requires key-based authentication. Even if no malicious intent was involved, the fact that keys were transmitted this way understandably raises trust concerns, and I respect your caution in addressing this issue.

We evaluated both systems and decided on the cookies system. Specific to LeoAuth logins (users pasting their posting keys to login - which is never recommended). About 48 hours ago is when I first saw a message that was clear enough to cause concern for me to look deeper. Whether or not this is something you and others believe, that moment is when I realized we should take a second look at our security approach vs. the LocalStorage security approach.

The buck stops with me and any fault here lies with me and not my team. I should have done better in understanding the trade-offs from the beginning and implementing this superior approach to security. My team and I cannot go back in time to when we decided to do this but we quickly shut off the login method and changed the implementation to the LocalStorage method - which is now live on INLEO.io.

On the proactive vs. reactive debate, I can see how from your perspective, the response to this issue appears reactive rather than proactive. I do not want to litigate over terminology as we've done in the past so I will just leave it at this: I understand that this can be seen as a reactive move and yes, I believe some of it is reactive. However, I consider some of these steps we've taken to be proactive as we are proactively securing users. No malicious intent was involved and no keys nor funds were stolen. The second that this became a security concern is the very same second I shut things down so my team and I could investigate and either determine our original approach was satisfactory or change directions and implement something that has superior security. We chose the ladder.

That being said, I do think it’s important to recognize that security improvements—whether prompted by internal reviews or external reports—ultimately make the ecosystem safer for everyone. My #1 priority is user security while onboarding new users and having them join the Hive ecosystem.

Regarding whether this constitutes a “security leak,” I think this comes down to definitions. No unauthorized party has been shown to have accessed user keys, but at the same time, the act of transmitting private keys outside of local client-side execution is itself a security risk that should have been avoided from the start.

I also understand why your trust has been shaken here. Security is built on transparency, and when concerns were first raised, the immediate response should have been more open to acknowledging the issue rather than disputing terminology. I truly hope this serves as a learning opportunity for improving security practices, as well as for handling community feedback in a way that reassures users rather than making them feel dismissed. My understanding and belief of our implementation was that it had some attack vectors but that they were ultimately less of a concern than potential attack vectors on LocalStorage.

The LEO Team and I can do better. It's my responsibility to see that change through. Especially with us open sourcing our technologies now and in the future. It's important that we always ensure security while we innovate. My team is hard-charging and very talented. We are not immune to making mistakes and I am fully willing to accept this one as a mistake on our part in how we chose to implement LeoAuth. Going forward, I want my team and I to have more open dialogues with you and others in the Hive ecosystem that may have a better understanding of existing security practices and possible things we can do better in the design-phase of our innovations.

As we move to Open Source these technologies and others that LEO has built for Hive, I hope to have more people like you involved in ensuring that they are safe for users and helping us improve them in every possible way.

I appreciate your deep understanding of security principles, and I hope that future discussions around these concerns can be approached with a shared goal: making Hive applications as secure and trustworthy as possible. Let’s work towards that together.