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
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