Remix.run Logo
0xbadcafebee 5 days ago

At least third major compromise in two weeks. (last comment: https://news.ycombinator.com/item?id=45172225) (before that: https://news.ycombinator.com/item?id=45039764)

Forget about phishing, it's a red herring. The actual solution to this is code signing and artifact signing.

You keep a private key on your local machine. You sign your code and artifacts with it. You push them. The packages are verified by the end-user with your public key. Even if your NPM account gets taken over, the attacker does not have your private key, so they cannot publish valid packages as you.

But because these platforms don't enforce code and artifact signing, and their tools aren't verifying those signatures, attackers just have to figure out a way to upload their own poison package (which can happen in multiple ways), and everyone is pwnd. There must be a validated chain of trust from the developer's desktop all the way to the end user. If the end user can't validate the code they were given was signed by the developer's private key, they can't trust it.

This is already implemented in many systems. You can go ahead and use GitHub and 1Password to sign all your commits today, and only authorize unsealing of your private key locally when it's needed (git commits, package creation, etc). Then your packages need to be signed too, public keys need to be distributed via multiple paths/mirrors, and tools need to verify signatures. Linux distributions do this, Mac packages do, etc. But it's not implemented/required in all package managers. We need Npm and other packaging tools to require it too.

After code signing is implemented, then the next thing you want is 1) sign-in heuristics that detect when unusual activity occurs and either notifies users or stops it entirely, 2) mandatory 2FA (with the option for things like passkeys with hardware tokens). This will help resist phishing, but it's no replacement for a secure software supply chain.

feross 5 days ago | parent | next [-]

Disclosure: I’m the founder of https://socket.dev

Strongly agree on artifact signing, but it has to be real end-to-end. If the attacker can trigger your CI to sign with a hot key, you still lose. What helps: 1) require offline or HSM-backed keys with human approval for release signing, 2) enforce that published npm artifacts match a signed Git tag from approved maintainers, 3) block publishes after auth changes until a second maintainer re-authorizes keys. In today’s incident the account was phished and a new token was used to publish a browser-side wallet-drainer. Proper signing plus release approvals would have raised several hard gates.

smw 5 days ago | parent | prev | next [-]

"2) mandatory 2FA (with the option for things like passkeys with hardware tokens)."

No, with the _requirement_ for passkeys or hardware tokens!

0xbadcafebee 5 days ago | parent [-]

They don't work everywhere, and when they do work they're not a panacea. It's like host-based security: if you get past this one barrier... what, everything is completely pwnd? You need defense in depth. That means the authentication factor(s) must not be the final word in security. So not using a passkey or hardware token shouldn't be a death knell.

4 days ago | parent | prev [-]
[deleted]