sam on Nostr: Let's talk about nostr security really quick: AFAIK, each nostr "account" is a ...
Let's talk about nostr security really quick:
AFAIK, each nostr "account" is a public/private key pair. When "signing in" to an account on the various clients, you paste your private key into the client and trust that the client doesn't compromise your key. This is really bad key management and opsec. If these accounts are going to have any value over time, they must be managed correctly by users and proper key management must be enforced through a hardened UX design.
Perhaps the better way to do this is by using something like hierarchically deterministic keys. You're master key or seed is kept secret and hidden (perhaps in your password manager or safe/vault at home). Then, you derive a single use private key for the first client you sign into. Then, a new NIP defines a protocol for other clients to sign into your account from the first client; an interact between the second client and the first client will result in the second client having a new derived private key from the first derived key. With this setup, if the second client is compromised, the first client should be safe.
Each note shared could attach some client identifier in order for followers to be able to derive the public key necessary to verify signatures/decrypt notes. This identifier also allows the master key owner to be able to revoke a client key in the event it is compromised. A new key could be derived for the client again and a protocol could be defined in order to recover notes that were compromised within the use of the client.
This scheme describes a sort of sign-in architecture not unlike access keys which may be created by centralized services like Twitter, GitHub, etc. The access keys are permissioned and the actual user's private key stored in a colder fashion. At any point the master key stored by the user is the ultimate recovery key.
I'm sure there is a lot to unpack here, and I left a lot of details out. But, I think this is a general good conversation starter and would like to work on it a bit more if it seems like a good idea to the nostr devs (jb55 (npub1xts…kk5s) npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s fiatjaf (npub180c…h6w6))
AFAIK, each nostr "account" is a public/private key pair. When "signing in" to an account on the various clients, you paste your private key into the client and trust that the client doesn't compromise your key. This is really bad key management and opsec. If these accounts are going to have any value over time, they must be managed correctly by users and proper key management must be enforced through a hardened UX design.
Perhaps the better way to do this is by using something like hierarchically deterministic keys. You're master key or seed is kept secret and hidden (perhaps in your password manager or safe/vault at home). Then, you derive a single use private key for the first client you sign into. Then, a new NIP defines a protocol for other clients to sign into your account from the first client; an interact between the second client and the first client will result in the second client having a new derived private key from the first derived key. With this setup, if the second client is compromised, the first client should be safe.
Each note shared could attach some client identifier in order for followers to be able to derive the public key necessary to verify signatures/decrypt notes. This identifier also allows the master key owner to be able to revoke a client key in the event it is compromised. A new key could be derived for the client again and a protocol could be defined in order to recover notes that were compromised within the use of the client.
This scheme describes a sort of sign-in architecture not unlike access keys which may be created by centralized services like Twitter, GitHub, etc. The access keys are permissioned and the actual user's private key stored in a colder fashion. At any point the master key stored by the user is the ultimate recovery key.
I'm sure there is a lot to unpack here, and I left a lot of details out. But, I think this is a general good conversation starter and would like to work on it a bit more if it seems like a good idea to the nostr devs (jb55 (npub1xts…kk5s) npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s fiatjaf (npub180c…h6w6))