how are client apps storing nsec keys? are they? 🤔 what are the risks of massive leaks that could compromise sec keys (making them unusable)? #asknostr
Discussion
On our app, nsec get encrypted through a user-defined password that is only stored in memory and never to disk.
In case of leak, you'd need the passwords to make decrypt them. It is also possible to add salt on them to make extra difficult to decrypt by bruteforcing, however, this kind of step isn't implemented yet.
thanks. and how about the largest nsec pools like nostr:npub12vkcxr0luzwp8e673v29eqjhrr7p9vqq8asav85swaepclllj09sylpugg nostr:npub18m76awca3y37hkvuneavuw6pjj4525fw90necxmadrvjg0sdy6qsngq955 nostr:npub1nz64zngcqm8vj8nhrdkcjpfwn2rcaqysnxec88tqfclp5afrpglsqm0w5y nostr:npub1plstrz6dhu8q4fq0e4rjpxe2fxe5x87y2w6xpm70gh9qh5tt66kqkgkx8j etc?
usually, #asknostr and #introductions spark a lot of engagement, but not so much on this topic.
anyone willing to dive into how client apps store nsec keys? what are the risks of large-scale leaks, and how do we minimize them?
i’d love to understand how these 100,000,000 nsecs is/ will be secured
nostr:nevent1qqstzqtwjd560vegdkzwekdem904flkxwtzzs34gdlgn7dlv4gapq3s6d9l2h
Yesterday at Nostriga, I heard that FROST enables you to switch to a new quorum of keys that controls the same npub.
If true, which I still have to check up on, there's some cool potential there for normie-friendly key storage (and rotation!).
this project, right? it’s extremely promising! nostr:npub1zach44xjpc4yyhx6pgse2cj2pf98838kja03dv2e8ly8lfr094vqvm5dy5 🤙
nostr:nevent1qqszlav4jw5wxl6mpn7n4w42la42en88ttzh3a4kjmzwy5jqtjtsseqf2vum5
Yeah this is something I care deeply about. I'm pretty paranoid when it comes to this stuff, which is why I build a tool I call NVault, it puts my nsec behind multiple layers without the code to extract it, ever. I think nvault is a pretty ideal solution for paranoid desktop users for the isolation benefits. Only remote signers can help mobile users and that has it's costs too.
That said, I'm not a mobile developer, but to me, having an nsec on a mobile device is identical to a hot bitcoin wallet. Often apps will store the nsec with symmetric encryption derived from a password, however this still requires the nsec be available in memory and accessible within the same process's memory space. I'm not usually concerned with keys at rest on modern mobile devices with asymmetric encryption. It's what can happen when the nsec is available in plaintext in the applications memory space.
So yes when the nsec is local to an app, I think you should have slightly higher concerns. However generally speaking it's more likely that keys will leak based on user error or phishing than though an application flaw, at least in the short term. For example, copy/paste to another app and you forget to clear your clipboard, or you accidentally pasted in a form or something like that. With browser clients they can be open to XSS attacks that can also leak keys. The handwoven part is that well it's secure as any other key or password you likely already use.
Also feel free tag me any time you maybe have questions like this I could probably answer more in depth, because most of these apps are open source
interesting that you brought up the hot wallet analogy because one of my questions is:
what’s the equivalent of a cold wallet for nostr?
i see nvault moving things forward here, but i’m still thinking about broader adoption.
imagining millions of users spread across a bunch of dominant clients. when there’s a massive leak of credentials in centralized systems, it’s somewhat manageable, but with nostr… that could be a protocol killer with no way to fix things.
but — just to confirm, clients don’t store nsecs outside of the device, correct? if not, then it makes sense that phishing or user errors are the bigger risks.
thank you!
Does salt and pepper add any security if the key is already perfectly uniformly random?
You need salt, otherwise dictionary attacks are easy.
How can you compute s dictionary for all possible nsecs? Salting is needed for human memorizable passwords which have much lower entropy than nsecs
In 99% of the apps it will be a valid nsec when the decoded string is matched to begin with text "nsec". That is the confirmation you need to know that the decoding without salt went OK.
The vector of attack is to use a large dictionary of known user-typed password against an encrypted nsec without salt nor using the hex version.
I really like the idea of social key recovery. Leveraging the trust relationships in the web of trust to back up, secure and help recover each other keys. Eg doing frost multisignatures with some trusted npubs (frens) automatically cosigning. In case of key compromise we fall back to the human social layer to recover, invalidate, roll over, attest new sec keys.. That way it could be more safe to allow the mess.
> human social layer 🧡
i think the concept of frost/frens cosigning as a way to restore one’s identity could be a huge step toward broader adoption!