Currently NSEC is acting as a one key to rule them all concept. People are plugging their one key into all kind of apps, some secure, many not. If any of those apps are compromised, your entire account and every thing you logged into is compromised.
This is akin to using one password on all your accounts. It's bad OPSEC.
What I mean is we need a way to create multiple keys based on that ONE key pair, similar to creating a unique password for every account. This way, if one Nostr based app is comoromised only that "baby" key is compromised and not the "master" key that it came from. An option to "freeze" these keys or delete would be even better.
Login to reply
Replies (24)
Currently NSEC is acting as a one key to rule them all concept. People are plugging their one key into all kind of apps, some secure, many not. If any of those apps are compromised, your entire account and every thing you logged into is compromised.
This is akin to using one password on all your accounts. It's bad OPSEC.
What I mean is we need a way to create multiple keys based on that ONE key pair, similar to creating a unique password for every account. This way, if one Nostr based app is comoromised only that "baby" key is compromised and not the "master" key that it came from. An option to "freeze" these keys or delete would be even better.
View quoted note →
Like wallets derived from master key?
Yes, it would. It was suggested before and some high level devs shot it down. I sincerely hope they reconsider.
Yup like a master/child keys system
Just allow clients to accept hash of the nsec
Another viable option.
💡🥂
I'd also love to see sub keys that can somehow be neutered or destroyed. I imagine signing an event using something like a 2/3 multisig or whatever that essentially destroys the other keys for signing and replaces it with one only the holder of the master key(s) can see. A password reset like behavior. Of course, someone who gets the master key(s) would still become king. No way to fix that without offline protections like we have for Bitcoin.
100% this. Its the same reason I don't play with nostr apps, clients etc.. I'd love to have my Nostr nsec on, say, a cold card. Creating sub keys now and again, and being able to trash them and create new in the case ifva hack etc..
Oh yeah totally agree! One key to rule them all is a huge problem.
Akin to address reuse in BTC in 2010, we worked hard to solve that the manual direct way long before BIP32 made the issue trivially easy to avoid.
There's more value if folks can get intuitively comfortable with handling multiple keys, not necessarily the hard way but most likely that'll be most effective, before tools make it seem like magic.
TRUST MINIMIZED NSECBUNKER w/ FROST 🔐🥶
Here's a demo of my new Nsecbunker implementation with FROST signatures! This works by creating a 2-of-2 frost signature scheme, which means that unless both a malicious client and bunker conspire to rug you at the same time, you are safe. 🧵
View quoted note →
I saw this. Looks cool. I am proposing something more robust where child keys can not only be derived from the master, but can be locked to an app or client, turned on, off, paused, or deleted.
I'm sure someone has thought of this before... But, you can just generate new key pairs for different things. Why use just one key pair?
I have separate keys for my home, car, work tool boxes, etc.
This has always been my big beef with #Nostr.
Wasn't much of an issue when Nostr was just social media. But now it's growing into much more. So, now it's a big problem
Yes, it would. It was suggested before and some high level devs shot it down. I sincerely hope they reconsider.
View quoted note →
Nip46 remote signer is close to this solution, although a device with the master key needs to be active to complete the signing. I think nip46 has a better trade-off balance because all clients don't need to support the solution to associate those events to your account.
Both your idea and nip46 have a common flooe: the master key must remain a secret.
With certificates/delegates/master-child keys you don't have that problem. Master key can stay in cold storage and you can create 1 certificate/delegate per app or multiple.
Identity trees with optional public links would solve this.
You have a master identity/key which can generate child keys, you use a different child per site/service which you can show only the child identity, or you allow it to follow the tree up to a parent identity.
You only share the private key for the child with the site/service, so if it is leaked the damage is contained. The parent key can also sign messages for the child key, so you could still go in an override anything the child does etc.
The solution is for all clients to accept Amber or other signers. Too bad Apple only has one.
Currently NSEC is acting as a one key to rule them all concept. People are plugging their one key into all kind of apps, some secure, many not. If any of those apps are compromised, your entire account and every thing you logged into is compromised.
This is akin to using one password on all your accounts. It's bad OPSEC.
What I mean is we need a way to create multiple keys based on that ONE key pair, similar to creating a unique password for every account. This way, if one Nostr based app is comoromised only that "baby" key is compromised and not the "master" key that it came from. An option to "freeze" these keys or delete would be even better.
View quoted note →
💯 I think this is the biggest thing stifling next level growth. glad others are concerned and thinking of this. Making it as simple as gmail oauth login is key. pun intended.
There was like Frostr or something
Bunker is slowly becoming an excepted standard, I have it on pollerama as well, will soon have it on formstr too.
Frostr was very promising and would be the perfect solution, but I think it's still very early and haven't really seen any updates in the recent past.
Right. We need a solid step with a solid dev that will actually be adopted. It will be a significant game changer for Nostr adoption—both personal, and business.
I look forward to someone cleverer and more popular than me taking over my account…