LeoAuth Login Method Update | Security and LocalStorage vs. Cookies
Hey everyone! You may have seen some of the debates around the implementation of LeoAuth and Keystore sign-ins on INLEO. If you haven't, this post will briefly describe the situation and the solution that we have deployed in response to the situation.
We appreciate everyone's feedback during this and we put the utmost value on User Security and ALSO User Experience. All of the solutions in this post were proactively developed and deployed. There have been no security leaks of any kind.
INLEO's goal is to provide the end user with the functionality they desire. This means giving them security but it also means giving them usability options. Sometimes, you trade-off security for more ease-of-use.
It should be up to the end user to decide what kind of trade-offs they want to make when it comes to user-friendliness and security. We will do our best to provide the options in the most secure way possible and the proper education around those options.
As part of our DHF Proposal, we are open sourcing all of INLEO's Onboarding, Sign Up and Sign In Protocols. It's important we hammer out these details and nuances before fully open sourcing these protocols. Our #1 priority is user security. Our #2 priority is User Experience. A great product is one that can merge the two and give the user the features, functionality and experience that they desire.
In this post, we will talk about this situation and also share some info about how we improved INLEO's LeoAuth and Keystore implementations going forward. Giving users more security and unburdened access to Hive through INLEO.
Thank you to everyone who has provided us feedback over the past 24 hours. We have deployed the solutions mentioned in this post. Additionally, we are inviting some trusted Hive developers to start reviewing our codebase for Onboarding methods, sign up and sign in protocols. This is the first step in our mission to Open Source INLEO's Onboarding methodologies so that all Hive UIs can use them.
Having some private reviews of the codebase before we go Open Source will help ensure more safety. We're also actively conducting various security audits on the login methods to add another layer of third-party verification that they are secure.
The Situation | Are Your Keys Being Saved When You Login With Keystore or LeoAuth?
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".
This is not true. We do not store your Keys on INLEO's servers.
A few points of clarity:
- The login methods being discussed are LeoAuth and Keystore (this does not include any other login methods such as Hive Keychain or Hivesigner). If you use Keychain, it is still one of the most secure options for logging in to Hive and we highly recommend it as one of the best Hiver login methods - however, not all users are Hivers. Especially when they first start on the platform. This is key to understanding why more login options are desired by potential new users of Hive
- INLEO does not store LeoAuth/Keystore users' keys on our servers and we never have
- We utilized (past tense as we have now changed this) a cookie session creation method for logging users in with LeoAuth / Keystore as we investigated the various security tradeoffs of Cookies vs. LocalStorage and decided that Cookies would be a more secure implementation (more on this below)
- While your keys are not stored on ANY INLEO servers, there is a passthrough vulnerability where your keys are utilized to log you in via session creation. The keys are not saved but they are technically passing through the network. This is the concern raised by those in MatterMost (again, we never saved and will never save your keys for these two login methods. However the keys need to transmit in order to initalize the session. We implemented this as an alternative to something like PeakLock which uses SessionStorage on the user's browser. Each implementation has its own security and usability trade-offs)
- The solution implemented resembles PeakLock. Now, users logging in with LeoAuth/Keystore will have an identical security matrix to when they use PeakLock on PeakD. Your key is held encrypted in your LocalStorage (NEVER broadcast over the network) and is unlocked via a Pin Code
- The INLEO team values User Security but we also value User Experience. We would never put users at risk and will always aim to do our best to provide users with an experience that fits their values from both a security and user-friendliness standpoint
The Solution | LocalStorage With Pin Code Encryption, Posting Key-Only
Our team has stayed up around the clock for the past 24 hours to develop, test and deploy a solution. Over the past few hours, we've invited a few third-party audits from devs on Hive to confirm the security of this implementation.
Instead of using our Cookies-method for logging users in, we are now using the same LocalStorage method for logging users in that other methods like PeakLock are doing.
How LeoAuth Works:
- Your Posting Key is encrypted locally in your browser and is unlocked via your Pin Code
- Your Keys are NEVER broadcasted over any network
- While convenient, LeoAuth is not the most secure method for logging in. We recommend Hive Keychain as a more secure alternative. Learn More
Many long-time Hivers know that pasting your key into a site to login is a less secure form of logging in. However, we remind and educate users continuously throughout our UI Prompts about this fact. A lot of users utilize features like PeakLock, LeoAuth and now Keystore Logins.
To reiterate our goal:
"It should be up to the end user to decide what kind of trade-offs they want to make when it comes to user-friendliness and security. We will do our best to provide the options in the most secure way possible and the proper education around those options."
Again: we always recommend that users consider Hive Keychain as a more secure alternative. If a user chooses this method, we have ample displays for them to acknowledge that this is a less secure (but possibly more convenient) means of logging in to Hive.
Keystore Users
Our Keystore implementation functions similarly to LeoAuth. It allows Keystore users to sign-in using their Keystore File + a Decryption Password.
How Keystore Works:
- Your Posting Key is derived from your Keystore file when you sign in with it
- Your Posting Key is encrypted locally in your browser and is unlocked via your Decryption Password
- Your Keys are NEVER broadcasted over any network
Again, this offers a lot of ease of use, but using Keychain (because of the nature of sandboxed Extension environments) will always offer superior security.
The update to use LocalStorage + Encryption of ONLY the PostingKey applies to Keystore Users as well.
If you missed the last INLEO AMA on 3/4/25, we talked about how we are developing a fully open source extension for Hive that will allow even more access, functionality and security to our Onboarding and Sign-In Methods. We will release a post soon with more details and a roadmap. This open source contribution is a part of our Onboarding Proposal.
New Feature for LeoAuth | Sign in With Multiple Accounts!
One side benefit of developing LeoAuth in this way is being able to utilize multiple accounts either with the same Pin Code or (Recommended) different Pin Codes.
Again, we always recommend using something more Secure like Hive Keychain but if you choose to use LeoAuth because you find it more convenient, we are providing that login option in the most secure way we are capable of. We will continue to improve this method and once our codebase is open source, we hope to see Hive contributors offer more solutions to further enhance security.
Conclusion | More Security, Progress Toward Our Roadmap to Open Sourcing INLEO
INLEO's onboarding methods are expanding to include many other wallet options. These frameworks utilize LeoAuth as the sign-in method.
Our #1 priority is always user security. We shifted 100% of our dev team to focusing on deploying this solution over the past 24 hours.
We re-iterate that there are more secure options available (Hive Keychain) when a user becomes more familiar with the platform as it is widely understood and agreed upon that a new potential Hive user may not make their first action downloading Hive Keychain.
Asking a brand new user to download and learn a whole new wallet extension in order to interact with our blockchain of apps is a big ask. Instead, we invite users to join Hive through our Onboarding technology that meets the user where they are. This means allowing them to seamlessly sign up and sign in to Hive with one-click.
There is a convenience and security trade-off here. We will continue to make these methods as secure as possible and to-date there have been no security leaks of any kind. All of the solutions in this post were proactively developed and deployed.
As we continue to improve our codebase, we are inviting Hive devs and security auditors to privately audit the codebase before we open source it. As part of the INLEO Proposal on the DHF, we are open sourcing all of INLEO's Onboarding Technology so that other Hive UIs can integrate it. Our #1 priority remains user security while our #2 priority is user experience - meeting users where they are and offering more alternatives to signing up and signing in to Hive so that we can grow our great ecosystem.
Hive is an incredible place with many talented devs and community leaders. Shout out to everyone who came together to provide positive and constructive feedback to improve INLEO's Onboarding Methodologies before we release it Open Source.
Many more updates on INLEO's shift toward Open Source contributions on Hive to come 🦁
Posted Using INLEO
That was a fast response. Good for the team.
So when people want to do transactions that require the Active Key, like transfers and power ups, they will be prompted to download keychain / install the extension, in orden to proceed, right?
Great question @tsunsica! For LeoAuth, it will prompt you to paste your active key and sign for that singular transaction. No remnants of that key will stay in LocalStorage or be broadcast in any way
For Keystore, it will ask you to select your Keystore file and Decryption Password in order to sign for the transaction. Similar to LeoAuth, no keys are getting broadcast and no remnants will remain in your browser
The dialogue that reminds users that they are using a convenient but slightly less secure method to sign transactions than Keychain will be present
Awesome! That is great for LeoAuth, an improvement since the previous version didn't have that option and you had to log out again, adding the active key. More secure but also more convenient!
The proactive approach to a potential risk is a big step for Hive ecosystem.
Hive community cares about the open source mindset and sustainable growth. The support on DHF proposal reflects the faith in the project.
Thanks for updates on the LeoAuth log in method. The pin code encryption is both secure and user friendly as we prefer!
Hive On ✌️
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:
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:
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.
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.
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.
I didn't bother myself to know how LeoAuth works, but today I learned about it, and it's good to know how it works. It's interesting to learn something new.