Replying to Avatar PABLOF7z

Here is a demo of a new onboarding flow for nostr applications. I started working on this after watching nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240's keynote "Nostr for normies" at nostr:npub1nstrcu63lzpjkz94djajuz2evrgu2psd66cwgc0gz0c0qazezx0q9urg5l; which I highly recommend watching.

My goal here was to create a way to onboard new users without requiring them to:

* install a browser extension

* copy/paste a secret

* explain npub/nsec stuff

* without losing interoperability with other nostr applications

This flow resembles a lot an OAuth style (e.g. "Login with twitter") flow:

* You create an account in one site (e.g. Twitter)

* You can "login" to another site with that account

* You can revoke access from using your account

Behind the scenes this is using NIP-89 to find nsecBunkers that allow people to register an account in their domain.

This means that any nostr application can offer a signup/login flow on any nsecBunker domain. The application itself doesn't take custody nor ever see the generated key.

And what's cool is that any nsecBunker provider can create their own flow; they can use passwords, or not, they can require a payment or proof-of-work to create an account. They can brand their "signup/login" popup page in whatever way they want.

Here is a demo video of this new building block that is now available to nostr applications.

https://cdn.satellite.earth/2e2e353ac5f69caffdc73da81c4e735c19579432967323564924c585819e6ef9.mp4

Looks truly groundbreaking, but it seems like there could be serious key security concerns here... What's creating their nsec, & how is it being stored?

It could also use some tooltip-style "this is what is happening" explainers throughout.

Reply to this note

Please Login to reply.

Discussion

With nsecBunker, the key is encrypted on the client side.

I think this has the potential to change the way we think about network security. The ride or die freaks think about security differently from organizations. We are all about Szabo's famous quote, "trusted third parties are security holes," and take extreme measures to ensure no one else has access to our keys.

A hospital or any other business has a gazillion people working for them that all need passwords, 2fa, etc. These are often smart people, but they know about as much as cybersecurity as I know about brain surgery.

The way places deal with this is host files in the cloud with a trusted third party who has the most liability they can find. All the hashes of the passwords are stored in a central location, making them an easy target.

From what I understand, this does the opposite. The keys are encrypted on the client, not the server. An attacker needs pysical access to the computer for the key. This mitigates the risk of social engineering attacks. If there is a breach, the key can be revoked.

This won't stop nprmies from writing their password on a post-it under the keyboard, but that's okay. Most of the people in the office have a password of their own. It's still a bad idea, maybe a jealous co-worker finds your password and searches porn sites, but it's less likely to end up on the news.

That's what I think anyway. Please correct me if I'm wrong. I am sure there are some things I've missed too.