Oddbean new post about login | logout Let's say I wanted to make an application built on nostr, and I want to utilizes nostr auth. To take some burden off more normie users, I was thinking the service could store an ncrypt for the user. From the users perspective, they just have to remember a password like any other site. But under the hood, the ncrypt can be sent down an stored in local storage (if missing). And then the user can unlock it with the password to sign events client side. I'm trying to think from a security perspective if there's any harm in the server storing the ncrypt. It's basically like storing a hashed password, but if the key is ever leaked, then someone with access to the DB could reveal the nsec.
You are basically describing NIP-46, but the private key never leave the provider, it is just used to sign the events. A particular implementation is https://nsec.app where the provider is actually the user's browser, so it's completely custodial.
Makes sense. I've never been able to enjoy the nip-46 bunker setup. I love the idea, but the UX around having to change browser tabs (plus wonkiness in brave browser) leaves a lot to be desired for a mobile login usecase. I want to make an experience where basically a user can slowly "opt in" to more control over their key management, without compromising the security of their key.
This (slow opt in) is what we're working on now with nostr-login widget, signup starts with a local key and then when user has actually used the keys and signed something etc we'll be nudging them towards "key backup" - importing into a nip46 service etc. You're suggesting a new kind of service where user enters a password and app sends ncrypt to a server so that if local copy of nsec is lost (or they want to use another app) then ncrypt is downloaded, password is entered and nsec is again stored locally. Right? This kind of "ncrypt store" is actually part of nsec.app setup (we store ncrypt on server so you could "login" into nsec.app in another browser/device), but you're proposing to make it a separate thing. Sounds interesting. The problem of apps having raw access to nsec still holds, but at least you're not copying it around, and password can live inside the password manager. Still a step forward over "nsec login", I would say.