SnowCait
Security issue with NSEC in the session storage. The NSEC is very easy to find and its a risk!
Hi guys, how you doing?
I found a issue on the nostter.app client....
When we use the dev-tools of the browser, we can easily find the NSEC in the sessionStorage... its just a raw NSEC, without being encrypted o locked with a password...
I think its a problem, beacuse its very very easy to access the sessionstorage... someone can take advantage of this problem to take the NSEC of the users...
I did the same test in the SNORT.SOCIAL, and I cant find... I dont know how the snort social did to keep this NSEC secure, but I think we need to review this.
Thanks for your time.
Best regards!
Hi,
I also don't think it's a good idea to store private keys in local storage, but there's no way for others to access local storage except through extensions or XSS. And if you use extensions, you can use NIP-07. Please let me know if there are any other ways to access it. I'm careful to avoid XSS, but if you find any, please let me know.
Thanks.
Hi!
I'll try to figure out how to encrypt these nsec's on the sessionstorage. I know that there's a way to do it, but I still don't know how to do it. It seems that we need to use a "password/passphrase" to decrypt the nsec just in the moment that we are going to sign an event. I'll try to understand how to do it and I'll tell you latter.
Have a good day!
By the way... se you there, follow me if you feel confortable to.
npub1du57w98d4sgjzeqz8wntk7w09855txtk87m45s4r9uy7xeare96qrat5sk
Before considering using a password, could you please prove that there is a way for others to access the local storage? I'm not a frontend expert, so I don't know if it's really possible to access local storage from extensions. If there isn't a way, it is meaningless.
I don't want to use a password if possible, as it would ruin the simplicity of Nostr.
I'm not a frontend expert, so I don't know if it's really possible to access local storage from extensions. If there isn't a way, it is meaningless.
Web extension content scripts run in the same window context. They have access to the page's local storage and session storage tmk
That said, extensions, always have the authority to intercept and access just about any part of a running web app, that's the entire purpose of extensions! You will never really be able to completely hide things. Extensions can access cookies and even intercept http requests if needed.
@VnUgE Can the extension access local storage directly? I'd like to know the specific code. If not, it seems pointless to encrypt nsec with a password, since it can't be completely hidden as you say.
Content scripts seem to have minimal access to the window and dom they are running in (usually all windows). However, content scripts can inject other scripts (blobs) into the running window and marshal data using the messaging api. This is how nip07 works.
My Example: https://github.com/VnUgE/NVault/blob/develop/extension/src/entries/contentScript/util.ts
This has the power to inject local scripts (as blobs) into all running doms which will have access to local and session storage for any site that is loaded. That script is designed to modify the window object, which can see window.localStorage and window.sessionStorage. The data still must be marshaled out of the window,
I was fairly confident that both content scripts and background scripts also had this power, through other APIs, but I cannot find the API among mozilla docs.
So that said, I think it's fair to assume an extension could always have the power to access all or most attributes of running windows if it wants. I'd argue that's the point of client side extensions. But I also don't think it's a web-app's responsibility to guard against (work against) malicious web extensions either.
@julianomarx @VnUgE After some research, I confirmed that it is possible to access local storage from the content scripts of the extension. However, as mentioned above, since nsec is stored in memory from local storage or other sources (even if it is protected by a password), it is impossible to completely hide it, and using password is not a fundamental solution.
I also checked other web clients, and they also store nsec in local storage. (Including snort.social, which has the raw hex in the sessions key in local storage.)
Some clients offer a password option.
There seems to be no way to solve this issue other than prohibiting login with private key.
I have no plans to disable private key login, so I will close this issue if there are no comments within a few days.