I am Groot on Nostr: ...

quoting naddr1qv…sxan

Last week I opened Damus to check something, and I noticed a notification for a private DM. The DM was from someone who had seen my nsec posted on a public site and wanted to warn me. They did so by logging into my account and sending a message to me from my account??? Kudos to the person who reached out. When I read the message I wasn’t surprised. I’d awoken a couple of weeks prior in a panic. I feared that I’d shared my nsec in a form rather than my npub. I fell back asleep and forgot about it. Turns out my panic was justified.

In thinking about the situation, I am not a typical Nostr user. Twice a week, I switch between accounts in the nos app for user acceptance testing. My default behavior is to copy one of several nsecs.

The brilliance of Nostr is that a user has a single nsec they can use to access a multitude of clients. It’s a bit like a universal login. A single account provides access to the entire Nostr network plus Mastodon, and Bluesky . Bonus is that it is a single string. There’s not a username or email address or password for users to remember. This one string becomes an all access pass.

Email / Usernames & Passwords

Let’s talk a bit about usernames and passwords. Throughout my career, I’ve had the unfortunate pleasure of implementing many single sign-on solutions, or building custom login workflows. If I’m being honest it is my least favorite software component.

First there’s the username vs email address identifier. Software never settled on a single solution. Often login interfaces are vague when it comes to username or email address. (For good reason, but this also creates friction for the user). Users are thus forced to remember for this app I use a username and this one I use an email address. Second, there is the password and the ever changing set of requirements for passwords. Apple’s native password generation and keychain storage are nice. Yet, the elegance of this solution falters for people who log into the same app on other devices outside the Apple ecosystem. Then there’s 1Password. Which could have been cool if they’d hired a UX Designer with empathy for the non-technical user….

What about SSOs which allow people to login with their Google or Facebook account? SSOs require users to remember whether they created an account from scratch or signed up with Google. For those who’ve finally kicked their Meta habit? Untangling an app from the grips of Facebook is no picnic.

Today almost every software requires username/email and password. This results in an ever growing list of credential and application information that needs to be stored or remembered. This problem is about to get 10 times worse as the major platforms drop support of 3rd party cookies for advertising. Brands will no longer be able to follow people across the internet with ads. Instead they will need to rely much more on direct marketing via you guessed it - email.

Lastly, we ask people to create a username and password at an inopportune moment in their onboarding journey. During onboarding the user is focused on trying the software. Users are less likely to store their new credentials at this point, resulting in lost or forgotten credentials in the future.

The simplicity of Nostr’s nsec

In Nostr during sign-up the user’s key is generated in the background. In Nos we automatically store the user’s nsec in the iOS keychain on device. While not a perfect solution for a lost nsec, it does help.

When logging out of many Nostr clients, users are asked each time if they have their nsec backed up. This is the right point in the process when a user wants to take an action to save the nsec in a secure location.

One challenge with Nostr is that many key terms begin with N. These terms are often represented by acronyms / uncommon jargon. In the case of nsec and npub they also closely resemble one another.

A user joining Nostr automatically receives:

• nsec - their private key
• npub - their public key

Then they are asked to create a NIP05 id.

Lastly they need to pick a name or display name.

Three of the four are acronyms or jargon terms that no one new to Nostr understands.

In the case of the nsec and npubid they look virtually identical. A long string of numbers starting with n. There has been a huge amount of work done to tie the nsec / npubid to a user name and password with the hope that it will make Nostr easier for Normies to adopt.

However, when I talk to non-technical Nostr users they are not concerned about a lack of username and password. It never comes up as a thing they would change about Nostr. When we ask them why they are reluctant to invite friends and family - it is also not a concern (lack of diverse content is).

When I talk to technical or Bitcoin Nostr users, the story is very different. They obsess about insuring Normies have an easy username password experience. For Bitcoin enthusiasts this makes sense. The nsec is the only way to maintain access to one’s wallet and is something you absolutely want to protect. Yet, that same level of security around a Nostr nsec on day one might be a bit much. The sky is not going to fall if you lose or compromise your nsec on day one or even day five for the vast majority of users.

When we think about nsec security there are two primary failures we need to help users solve for:

• Accidentally sharing their nsec, as I inadvertently did.
• Losing their nsec.

Preventing inadvertent sharing of the nsec

One of the biggest challenges is that the nsec and npub ID look virtually identical if someone is moving fast. One easy fix would be to visually represent these strings differently.

One option is to maintain the npub as a long string. And store the nsec as 3 rows of strings as follows:

nsec1er0trulkrt7n2zxp 17r57s7ae65y5wrhvhxae 4yd3dh4ccg38w8syqdq89

When a user copies their nsec to save elsewhere - it could also copy over the text:

DO NOT SHARE THIS WITH OTHERS nsec1er0trulkrt7n2zxp 17r57s7ae65y5wrhvhxae 4yd3dh4ccg38w8syqdq89

Thus when a user looks at wherever they’ve pasted their key, the see this reminder to not share with others.

Seed phrases provide another alternative for logging in and out of accounts.

In some clients the option to create an NIP05 in app already exists. It would be beneficial to make this a network-wide option. So users can share their NIP05 id instead of their npub id.

Nsec loss

At nos we automatically store the nsec in the on device keychain. During our Discovery Research round we intentionally met with a user who had “lost” their nsec. We learned that instead of losing the nsec, they had deleted their Nostr app and assumed that their nsec was lost. When they reinstalled, their nsec was saved in their device keychain. And they regained access to their account.

We have plans to extend this to give people the option to store their nsec in the iCloud Keychain.

Generating a new key and storing a new key in the device keychain enables Nostr clients to handle the “boring” aspects of keys and credentials behind the scenes. Thus freeing up the user to explore the Nostr network.

On Android Google Safe Lock can be used. Both also work on desktop web clients.

When and how to remind people to save their nsec somewhere safe

As I mentioned earlier, Nostr clients do a good job reminding people to save their nsec somewhere safe when they log out. However, there’s also an opportunity to make saving nsec’s fun and interesting.

Upon return to a client for a second use, we can prompt users to learn a bit about their nsec and to download a copy of it. Instead of a boring copy / paste action, clients can position nsecs on a well designed card for users to print (or store on their computer).

Going a step further, users could choose a card design for their nsec. By making it fun instead of annoying we can help users protect their nsecs. Users can store printed cards in the same place they store their passport (when not traveling).

Surviving the grift and scam era

Pre-pandemic we worred about our grandparents and employees succumbing to phishing emails. Today all of us are subject to an onslaught of phishing SMS messages, phone scams, Instagram scams. Usernames and passwords are a key element in many of those scams - asking people to log in and compromise their credentials. By opting out of the common credentialing system - we can give people a bit of a reprieve. We can also use this time to think through more creative ways to teach people to protect their nsecs.

Avoiding the maintenance of email / password systems

Because of the never ending scam machine, there’s an entire industry for 2-factor authentication, Okta logins, etc. Cybersecurity jobs may now be the only tech sector jobs still available stateside outside of government. However, as I mentioned earlier, this is not user facing work. It’s not solving problems for people. If anything this burgeoning security industry is only creating more friction, not less.

The creation of extra layers of security requires more maintenance and updates. Today we have teams dedicated to credential management. Instead of solving problems these teams are often adding friction to the experience.

Nostr is the beginning of an amazing decentralized future. Before we incorporate existing software patterns, let’s pause to make sure we understand the problem we’re solving. And then take some time to think outside the box about solutions.

If you’ve made it this far, this will be my last post on my compromised account. You can find me @npub1j60x528w2g2vkq5kae5uhh8y7sezjyj20zcsg0v9muc72cmdpu0s0md7ua where I am happy to hear your thoughts about this proposal.