An issue remains where/how to store the nsec.

Browsers do not have a secure storage method at present. I’m not sure how native client choose to store private keys currently, but they are almost certainly better than storage options in browsers that exist now.

The one pattern for key management that shows the most promise is creating key objects using the WebCrypto API and storing the unserialized objects in indexdb for use in signing/encryption.

https://gist.github.com/saulshanabrook/b74984677bccd08b028b30d9968623f5

Even so, this relies heavily the security of the code which β€œlocks” these objects from being imported and on the browser’s single-origin policy browser.

This may not be that much worse than the current state with native apps, but it remains to be proven by folks much more experienced with browser security than me.

As with most clients, the best course going forward is going to be some combination of hardware signers and nsec bunker to get the keys off the critical execution path.

Reply to this note

Please Login to reply.

Discussion

Apologies. Typos abound.

Horrid creatures those typos.

Someone already mentioned Nostore but there’s also nsecBunker. So a new key would be created that gets signed access via your master key.

I still want it to be called nsequestr. 😁

How about β€œnsequitur”? 😏