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