Well, yesterday i reported a critical vuln and just found another one... the "__session" for a keychain logged in user and keystore is a none encoded JWT String containing all keys and passphrases... ouch.
Khal, the keys are sent via a network request. That's the problem. They leave the users control. We don't know what happens after they leave from the browser. For all we know, a malicious actor could have compromised the other end(server they are going to) and is harvesting the keys. Or someone could have added an extra log statement and now the keys are being logged somewhere. This is not safe.
That's correct - i double checked that and it's a form sent which leads sent to a destination which is unknown here. And a big + here is that, if someone has already malware and a cookie stealer on the PC, reading the __session Cookie and reveals Keys in readable format.
Sorry, I won't respond to name calling. While there are security trade offs to both login implementations, we decided to calm this conversation by implementing an identical solution to what PeakLock has.
@rishi556 is a talented dev and he and I have had a lot of great interactions with the past. If he wouldn't mind taking a look at these updates (they're now live in production) and letting me know any #feedback he has, I would love to answer anything related to it. We've implemented something similar to PeakLock but with a few extra enhancements on our end.
User security is my #1 priority - past, present and future.
While I do find that to be an oversimplification, you’re right and we did change it to the “LocalStorage” implementation. We added this on both frontend and backend. It’s as secure (hopefully slightly more secure) as something like PeakLock.
To the frontend user, only the posting key is encrypted locally now and a PIN code is set and prompted
Thanks for your feedback during this time. I’m always aiming to improve INLEO for our users
Khal, the point is decentralising the points of failure. Many browsers is a lot better than only having to compromise one website (making it a massive target). PeakLock encrypts it when not in use. If the browser is compromised at the point of setup, neither provides security.
If anyone is reading this Thread - user security is and has always been my #1 priority.
My team and I have worked extensively on security and will continue to. If you think you can find a vulnerability and want to DM it to me along with a proposed solution, I love feedback
I will personally disburse bounties to any vulnerability found that gets patched by my team. If you propose the solution we end up using, the bounty will be higher
I'm confident in our security but always looking to improve it
Transparency is really important to me, so here's an update in case anyone comes in and reads these Snaps. This is us being proactive to investigate the LeoAuth / Keystore methods of signing in - as a reminder: none of the other sign in methods (like Keychain) are impacted
YO WTF! If this is legit, NOBODY should be using the platform.
It's legit! Anyone using the platform should stop immediately. Whoever thought of this should never work with crypto again!
Well, yesterday i reported a critical vuln and just found another one... the "__session" for a keychain logged in user and keystore is a none encoded JWT String containing all keys and passphrases... ouch.
But you're right - they should shut down their service until all founded security issues are ironed out and fieldtested.
This is very misleading @rishi556
I implore you to sign in to other Hive UIs and take the same screenshot
Khal, the keys are sent via a network request. That's the problem. They leave the users control. We don't know what happens after they leave from the browser. For all we know, a malicious actor could have compromised the other end(server they are going to) and is harvesting the keys. Or someone could have added an extra log statement and now the keys are being logged somewhere. This is not safe.
That's correct - i double checked that and it's a form sent which leads sent to a destination which is unknown here. And a big + here is that, if someone has already malware and a cookie stealer on the PC, reading the __session Cookie and reveals Keys in readable format.
@khaleelkazi I fking think @rishi556 knows what the fuck he is talking about. Why are you such a dumb cunt @khaleelkazi ???
Sorry, I won't respond to name calling. While there are security trade offs to both login implementations, we decided to calm this conversation by implementing an identical solution to what PeakLock has.
@rishi556 is a talented dev and he and I have had a lot of great interactions with the past. If he wouldn't mind taking a look at these updates (they're now live in production) and letting me know any #feedback he has, I would love to answer anything related to it. We've implemented something similar to PeakLock but with a few extra enhancements on our end.
User security is my #1 priority - past, present and future.
https://inleo.io/@leofinance/leoauth-login-method-update-security-and-localstorage-vs-cookies-2c6?referral=leofinance
@rishi556
https://inleo.io/@leofinance/leoauth-login-method-update-security-and-localstorage-vs-cookies-2c6?referral=leofinance
From a quick glance, I don't see the keys being sent over the network anymore.
While I do find that to be an oversimplification, you’re right and we did change it to the “LocalStorage” implementation. We added this on both frontend and backend. It’s as secure (hopefully slightly more secure) as something like PeakLock.
To the frontend user, only the posting key is encrypted locally now and a PIN code is set and prompted
Thanks for your feedback during this time. I’m always aiming to improve INLEO for our users
why???
even if I use keychain??
No, this is not accurate and I already responded at length to this.
Got it!
It's when you use plain text key on the site. They shouldn't have access to keys when using Keychain.
Ouch, this is terrible.
There is no need to send the key anywhere else as there are other ways to proof if the user is legit.
What a big security gap :(
This is incorrect and I implore you to look at other Hive UIs. This is actually a more secure way of initiating a session.
The standard practice on Hive UIs is to literally leave the keys in LocalStorage (even when you're not browsing). We do not do that.
Khal, the point is decentralising the points of failure. Many browsers is a lot better than only having to compromise one website (making it a massive target). PeakLock encrypts it when not in use. If the browser is compromised at the point of setup, neither provides security.
Yes I understand this, the implementation was - in our opinion - better in some senses but obviously lacks in others.
We decided to change it to the same implementation as other UIs.
Ours (LeoAuth) now has the same exact setup as PeakLock
https://inleo.io/@leofinance/leoauth-login-method-update-security-and-localstorage-vs-cookies-2c6?referral=leofinance
If anyone is reading this Thread - user security is and has always been my #1 priority.
My team and I have worked extensively on security and will continue to. If you think you can find a vulnerability and want to DM it to me along with a proposed solution, I love feedback
I will personally disburse bounties to any vulnerability found that gets patched by my team. If you propose the solution we end up using, the bounty will be higher
I'm confident in our security but always looking to improve it
Transparency is really important to me, so here's an update in case anyone comes in and reads these Snaps. This is us being proactive to investigate the LeoAuth / Keystore methods of signing in - as a reminder: none of the other sign in methods (like Keychain) are impacted