N on Nostr: ...

日本のcoracleユーザーはぼくと他に数名しかいないと思いますが秘密鍵でログインしていた人の秘密鍵が漏洩した可能性があるようです。以下の投稿とスレッドを見て詳細と秘密鍵の扱いについての対話をチェックすることをおすすめします。

quoting nevent1q…2s9h

Here's a quick postmortem on the Coracle vulnerability from this morning. If you haven't heard about it, please see below.

nevent1q…9r8a

First off, the offending line of code was incredibly stupid. It only took a glance to realize that something was incredibly wrong. I went back and git-blame'd the line, and discovered that it was the result of a refactor, where a local variable named `session` was replaced by an imported variable with the same name. The former was a random string (in keeping with my attempts to anonymize users). The second was a user session object, complete with private key.

This leads me to my first observation, which is that no one is auditing nostr apps (just as no one is auditing most software out there). In many cases, there isn't even a code review step, because many of us are solo devs. Just because something is open source doesn't mean you can trust it. Just because you wrote something doesn't mean you can trust it! My key was leaked right along with those of my users.

Code review aside, there were some mistakes I made that resulted in the incident being worse than it could have been:

1. I used analytics and error reporting.
2. I did not self-host my analytics and error reporting.

Because I was using a hosted error reporting service, their servers were implicated in my mistake. Had I been self-hosting, I could be more confident that the data I have deleted is actually gone (even if my users don't have the same assurance).

Action item number one: analytics and error reporting are important enough to being able to develop Coracle that I'm not planning on getting rid of them, but I am moving immediately to self-hosted options. If you want to opt-out of that data collection, there is a setting for that within Coracle.

Another mistake I made is that I trusted myself to safely handle my users' private keys. This is more than just my mistake; despite the growth in use of remote signers, it's still very common for nostr applications to offer private key login or generation. But after this incident I'm of the opinion that no one should be handling unencrypted private keys, except for signers.

Applications should not generate private keys or allow users to sign in with them. Period. In fact, I propose we sunset the term "nsec" entirely. There's no need to make a friendly encoding for something that users should never see. Instead, users should be asked to export their private keys in the password-protected ncryptsec format only. This prevents clipboard attacks or poor key management from compromising users.

This is action item number two: I've already removed private key login from Coracle, and will shortly be re-working my onboarding process to redirect users to set up a remote signer instead of generating a key.

This will have implications for UX, and might make things more difficult for new users in the short term. But as Braydon Fuller (nprofile…4qru) pointed out, the longer we allow users to treat keys like passwords, the longer they're forming poor habits for keeping their keys safe, because the two are categorically different. Removing support for private keys will cause pain in the short term, but will force us to improve our integrations with remote signers, improving security and UX in the long term.

That's all I've got for now. Thank you to everyone for your graciousness, I appreciate all the support. I'm honestly glad this happened, and I hope it will galvanize all of us into action to continue to improve nostr's security.