The sheer number of people who have submitted their privkey/nsec for verification on https://verified-nostr.com is quite staggering. And that’s despite a bold, red message to only send the pubkey in hex.

Fortunately for them, I ensure those submissions are discarded. That said, there really should be a better way for key management and/or training for new folks to realize the privkey/nsec is basically their password.

Reply to this note

Please Login to reply.

Discussion

Beg pardon, what’s hex?

No worries! I recommend checking out this part on “bare keys”

https://github.com/nostr-protocol/nips/blob/master/19.md

Thank you for the information and kind response. This science escapes me, tho I understand the basics of npub, nsec, note, and not sharing nsec. I will press on, gathering an understanding of the intricacies of computer science.

Maybe we should call it password then.

Or as a compromise write password/nsec in the frontends.

I think telling people to generate their keys with something like Amber is probably the way. Then Amber's UX can ensure the private key is handled correctly.

That's it! If all your apps can delegate signing to Amber (or an equivalent), then the user never has to handle their nsec. And if they do, Amber can make it super clear what the risks are.

Is this available for download through F-droid perhaps?

I use obtainium so not sure about fdroid.

What is this about?

Education for good OpSec

This is a huge problem.

Just block "nsec"

Good point. Could stop form submission if an entry field includes a anything prefixed with "nsec". The only problem is some folks have also submitted the hex version of their nsec 😂 and that's nearly impossible to block

nostr:note12rd2qutc5n77540et4nmvs6vpuef7s5n33uengsn8kh03pzg6z8srrgmcw