100 sats \ 6 replies \ @crrdlx OP 12 Jul \ parent \ on: Nostr subkeys nostr
Hadn't heard of NIP-26 before, interesting. Even if it wasn't dead, a weakness is that it would be an opt-in or not thing by clients...they can implement it or not (isn't that the case for all NIPS?). That's great and all, but if your nsec got compromised, you're out of luck regardless of any NIP-26 or not.
Wouldn't this same weakness exist for "revocable access tokens"? If I understand, I grant access to dapp X with this token. I might revoke it in the future, but for now, dapp X can sign events on my behalf. This is great. But...Bad Actor Jim got my nsec and thus has control of "my nostr account". I don't see how a token access system resolves this.
Changing to entirely new keys is the only way (I think). With the Hive example, if someone gets my private keys, we both can do anything...post, move funds, etc. Effectively, it becomes a race to see who changes to new keys first. Whoever switches first then has exclusive control and the other person is totally locked out and cannot do anything.
Also hadn't heard of the "Sanctum" project you link (I'm guessing you're building or working on this?). Awesome. I'll be keeping an eye out for sure.
Overall, I guess my concern is for newer nostroids and people who sometimes make dumb login decisions or have in the past (ahem, me, allegedly 😊). It's so simple for someone to create a fake "dapp" that looks nice and include a "logic with nsec" here button that does nothing but gathers private keys. People who have been around and understand keys a bit should know to login with signing extensions or bunker, but it's a learning curve to get there and not always doable in every case and every browser, os, etc.
We need a "change my nostr private keys to new keys" nostr dapp.
weakness is that it would be an opt-in
Fiatjaf makes a good point in that its effectively not opt-in, its the nostr analogue to a hard fork because all the lift is on the clients
if your nsec got compromised
There's no way to handle this gracefully in public key systems where your public key is your identity, you can abstract all you like but you're still building a new identity when its all said and done rolling keys... there are proposals for pre-defining a rollover key, but its pretty stupid imo as a compromised key could still just attest to a fake rollover key
This is a tale as old as time, whether its a yubikey ssh pgp btc or whatever... if you're keys are compromised your fallback is some out of band redundancy and repointing
Bad Actor Jim got my nsec
The point of revocable access tokens is to not let bad actors get your keys in the first place by keeping them in a secure remote signer, not pasting them into countless apps and hacky browser extensions.
If an app is misusing its access you revoke that access and that's the end of it, there's no need to roll a new key... the app only ever had a token to the signer not the key itself.
dumb login decisions
Pretty much everyone that has used nostr has made a dumb login decision because that's all that's been readily available. My nsec has been pasted into a couple apps and extensions just to play with them, and so I personally plan on starting from scratch with a Sanctum originated key once I consider Nostr usable enough for social to care
It would be a bad look to run an enterprise-class auth service and then have my key exploited later because I had pasted it into some apps before building a secure signer.
We should consider Nostr completely custodial at this stage because of how insecurely keys have been used. (Browser extensions are just as bad as pasting into a web app).
Only once secure remote signers (Sanctum and Bunker work similarly) are standard can it begin to secure valuable identities.
We need a "change my nostr private keys to new keys" nostr dapp.
Such an app won't be able to do anything more than make a post that says you're burning the current key, follow me at the new key... there's no way around the fact its going to be a new identity that requires repointing.
reply
Appreciate the thoughtful reply.
and so I personally plan on starting from scratch with a Sanctum originated key once I consider Nostr usable enough for social to care
I've considered this as well, and might do it at some point.
Such an app won't be able to do anything more than make a post that says you're burning the current key, follow me at the new key... there's no way around the fact its going to be a new identity that requires repointing.
You know way more about this stuff and me so I yield to your expertise. The thing I don't understand is how it is done over at Hive. I changed my private keys there after the fork from Steem (the Hive private keys were the same as with Steem and Tron, yikes! talk about scary). Though I changed to new keys, I'd saved the old ones. I just tried those old ones, and as expected they no longer work. I don't know, maybe Nostr a different animal altogether.
reply
Hive is a unique client using Nostr but not necessarily compatible with other Nostr clients, that's where the hard fork analogy comes in re: NIP26, which is how they do it
It's possible they end up doing really well with it and other apps start to use NIP26 to benefit from shared network effect, but as of now there's a lot of reasoning outlined above for other Nostr apps try other things
reply
Wait what? I was referring to the hive.io chain. There's a Hive "unique client using Nostr" with that name?
reply
Conflation on my end, I mean Minds... somehow transposed those names in my head
reply
✅
reply