Note

Your nsec Is Not a Password: Nostr Key Handling and Signers

Your nsec is not a password. A password unlocks an account that someone else holds. On Nostr, the private key is the account: there is no server to reset it, no recovery email, and anyone who copies it can speak as you, indefinitely.

2026-10-16 · nostr, nsec, key-handling, remote-signing, nip-46, nip-49, nip-55, nip-07, identity, sovereign-starter, module-3, civil-liberties

Sovereign Starter · Module 3 of 5 · Nostr key handling

Dark CryptoDecentral hex mesh — one glowing teal key cell held inside a ring on the left, with thin bronze request lines reaching it from several small client cells on the right; the key never leaves its ring; no text.

The Nostr steps in the Sovereign Starter path begin with relay lists, which assume you already have an identity worth routing. This note goes one step earlier, to the key itself.

Thesis, stated once: your nsec is not a password. A password unlocks an account that someone else holds. On Nostr, the private key is the account: there is no server to reset it, no recovery email, and anyone who copies it can speak as you, indefinitely. Good key handling means keeping that key in as few places as possible and letting apps ask for signatures rather than hold the key.

What the key is

NIP-01 is short on this point: "Each user has a keypair." Every event you publish carries your public key and a Schnorr signature over secp256k1. Relays and clients check the signature, and that's the whole of authentication. Your profile, follows, posts and relay list are all events signed by that key.

NIP-19 defines the familiar npub and nsec strings. They are bech32 wrappers "meant for human-friendlier display and input only," with different prefixes "to prevent confusion and mixing between private keys, public keys and event ids." The prefix is a safety feature: npub is safe to share, nsec never is.

Two consequences follow:

Compromise is permanent. NIP-01 defines no way to rotate or revoke a key. If an nsec leaks, the attacker's signatures are exactly as valid as yours, and your followers have no protocol-level way to tell them apart.
Loss is permanent. No relay can restore your key. Your old events stay readable, but you can't sign new ones as that identity.

That's why key handling is a Beginner step and not an advanced one.

The usual mistake: pasting the key everywhere

The easiest way to start is to paste your nsec into each new client. Every paste adds a copy to an app's storage, a clipboard history, and possibly a cloud backup or a browser profile you forget about. NIP-46 states the principle against this: "Private keys should be exposed to as few systems - apps, operating systems, devices - as possible as each system adds to the attack surface."

The alternative is a signer: one component that holds the key and answers signing requests from the clients you use. The NIPs define three ways to do this, each fitting a different setting.

Three signer patterns

Browser extension: NIP-07. NIP-07 defines a window.nostr object with getPublicKey() and signEvent(), plus optional NIP-44 encryption methods. A web client asks the extension to sign; it never sees the key. The trade-off is that the key lives in the browser profile, alongside everything else running there.

Android signer app: NIP-55. NIP-55 describes a signer app "so that the client never needs to handle the user's private key." Clients reach it through Android intents, where "the user approves or rejects the request manually," or through a background content resolver that "only works for permissions the user has previously chosen to remember." The second mode is the convenience/control trade-off made explicit: remembered permissions mean fewer prompts and less oversight.

Remote signer ("bunker"): NIP-46. The key lives on a separate daemon or device. NIP-46 suggests it "could be, for example, a hardware device dedicated to signing Nostr events". The client talks to it over relays using encrypted kind:24133 events. A connection starts from either a bunker:// token (from the signer) or a nostrconnect:// token (from the client). Requests can be scoped: the spec gives the example nip44_encrypt,sign_event:4, meaning the client may encrypt and may sign only kind-4 events.

Two details from NIP-46 are worth knowing before you trust any connection:

The connection uses a disposable client keypair, separate from your identity key, and clients "should delete it on logout."
Client metadata (name, URL, image) "is client-supplied and unauthenticated" and must not be used for authorization. A friendly name on the approval screen proves nothing about who's asking.

A signer doesn't make a malicious client harmless. A client you've let sign kind-1 notes can still post nonsense as you. What a signer does is keep the key itself out of the client, and let you limit and revoke what each client may request.

When you must store the key: NIP-49

Sometimes you have to keep the raw key somewhere, for a backup or to move it to a new signer. NIP-49 defines ncryptsec, a password-encrypted form:

The password is stretched with scrypt, at a cost the user or implementer chooses (LOG_N; the spec's table runs from 64 MiB at 16 to 4 GiB at 22). It then encrypts the key with XChaCha20-Poly1305.
A key-security byte records whether the key "has been known to have been handled insecurely". It's an honest flag that a key once pasted in plain text isn't the same as one that never was.
The spec advises against publishing these blobs to Nostr, because "cracking a key may become easier when an attacker can amass many encrypted private keys."

An ncryptsec is only as strong as its password, and a forgotten password is a lost key. Treat it like the seed backups in our backup note: store it offline and test that you can decrypt it.

What about deriving it from a seed phrase?

NIP-06 defines deriving a Nostr key from a BIP 39 mnemonic at m/44'/1237'/<account>'/0/0. It's currently labelled "unrecommended", with the instruction "prefer a single nsec". Don't assume a Bitcoin wallet seed also covers your Nostr identity. And reusing one seed across both means one leak exposes both.

A short self-check

How many apps, devices and browser profiles hold a copy of my nsec today?
Which clients sign through a signer, and which hold the key directly?
For each signer connection, what is it allowed to sign, and is approval manual or remembered?
Do I have one offline backup (plain or ncryptsec) that I've tested?
If this key leaked tonight, how would the people who follow me find out?

What this is not

This is not a ranking of Nostr clients, extensions or signer apps, and it names none. It is not custody advice, and it doesn't cover payments, zaps or wallets. It doesn't claim any signer pattern is "secure" on its own: every one moves risk to a different place. It contains no prices or trading content. Never paste your nsec into a website or bot that asks for it to "verify" or "recover" your account.

The practical takeaway fits on one line: keep one key, in as few places as possible, behind a signer that asks before it signs, with one tested offline backup.