RE: LeoAuth Login Method Update | Security and LocalStorage vs. Cookies
You are viewing a single comment's thread:
One big thing I want you to understand about sending the keys over the network. Someone else having access to your keys means that they can transact as if they were you, up to the key's permission level. The highest level key that I saw leo request was active key, which has the ability to transfer funds. By transmitting the keys over the network, there are some potential issues:
- The obvious, Leo could purposefully store keys on their server when they get it on their server.
- Leo could accidentally store keys on their servers by having misconfiguration logs that are fully logging the requests.
- Leo uses cloudflare. Cloudflare could be storing logs of the requests which include the keys.
- There can be a proxy between the user and the endpoint that the user is connecting to that's logging(think workplace proxy, a lot of those even do HTTPS decryption) the requests with the keys.
This isn't a full list. While some of the work I do on a day to day basis includes security, I'm by no means a security professional.
Onto a bit of responses:
All of the solutions in this post were proactively developed and deployed.
I would call this reactive, not proactive. You made a change due to issues found by other. From what I can quickly tell, there was multiple days between initial report and Leo disabling the keys based auth from their site. I'm not fully following what's going on in MM at all times, and I'd seen the conversation happening there, but wasn't reading it entirely(I did skim it briefly afterwards though), and the first time I truly saw the issue was @engrave's post on it.
There have been no security leaks of any kind.
User's keys were sent over the internet. I would say there was a security leak. Anyone who entered keys on inleo to log in using your login method SHOULD change their keys immediately. See above section for possible issues.
24 hours ago, a statement was posted in Mattermost (a platform similar to Discord where Hive devs and community members gather around various topics) which said (paraphrased) "INLEO is storing your keys on their servers".
For my particular side I never said that, only said it was a possibility of what could be happening. You guys did have other issues where you were doing that though(via cookies that @louis88 pointed out in comments. Your initial response wasn't to take it seriously but to call it misleading? I don't understand where any of what I said was misleading. You were transmitting the keys to the backend.
Here's your own sentence with the highlighted part that you did. Which is a lie.
I'm going to be honest. I will have an insanely hard time trusting any leo product on the security side after this. Multiple trusted devs were pointing out the issue and you chose to say this instead.
Just out of curiosity, how common is this lind of vulnerability outside of cryptocurrency? Is it something that occurs with commerce sites or banks or social media?
Or is it just not up to the highest standard?
Vulnerabilities are pretty common out and about I'd say. A lot of applications have been getting better about it. I work in the finance sector and we do care a ton about security a lot. While my day job doesn't involve crypto at all, customer data leak would require at a minimum talking to lettered agencies.
While not writing vulnerable code is important, what I see as equally important is how companies respond when they get told about the issues. If they try to downplay it, or act like it doesn't exist(which happened here) then that tells me that they don't actually take security seriously.
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.