**Security Update**
I've got some bad news for you guys. This morning, as I was adding error handling to flotilla, I discovered that Coracle has been sending user session objects to bugsnag when reporting errors.
Who is affected: Users who triggered an error in Coracle while signed in with their private key, since December 5th 2023.
What I've done:
- I immediately released a new version of Coracle, both to web and to zap.store
- I have deleted the affected apks from my releases
- I have deleted all my error data from bugsnag
- I have deleted my bugsnag project and rotated my api key, so lingering error reports will be dropped
- I have audited my code for use of the session object to ensure nothing else like this is happening
What you should do:
- If you're logged in with your private key, log out
- Hard refresh the page to ensure you have the latest version of Coracle
The bottom line is that if you signed in to Coracle with your private key, it has been shared with me and with bugsnag. In practical terms, your keys should still be secure, since they were sent over TLS, and have been deleted. But there is no guarantee I can offer that they are in fact gone.
I take my users' privacy seriously. My error reporting implementation doesn't record user IPs, it redacts identifying data, and it allows users to opt-out. I also warn the user when they attempt to enter an nsec into a text field. In this case, I simply screwed up, and I sincerely apologize. Reply to this note if you have any questions.
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.