> We need some deeper changes in the ecosystem.

I avoid anything to do with NPM, except for the typescript compiler, and I'm looking forward to the rewrite in Go where I can remove even that. For this reason.

As a comparison, in Go, you have minimum version spec, and it takes great pains to never execute anything you download, even during compilation stage.

NPM will often have different source then the github repo source. How does anyone even trust the system?

The VS Code ecosystem has too much complexity for my tastes. I do keep a copy around with a few code formatting plugins installed but I feel more comfortable with Emacs (or Vim for my friends who are on that side of the fence).

I am a consumer of apps using npm, not a developer, and I simply don’t like the auto updates and seeing a zillion things updated. I use uv and Python a lot, and I get a similar uneasy feeling there also, but (perhaps incorrectly) I feel more in control.

Yeah, Editor extensions are both auto-updated and installed in high risk dev environments. Quite a juicy target and I am surprised we haven’t seen large scale purchases by bad actors similar to browser extensions yet. However, I remember reading that the VsCode team puts a lot of effort in catching malware. But do all editors (with auto-updates) such as Sublime have such checks?

The key thing needed is a standard library which includes 100000 of these tiny one function libraries (has-ansi, color-name).

I usually make sure all the packages and db are local, so my dev machine can run in Airplane mode. And only turn on internet when use git push

Another main issue is how large (deep and wide) this "supply chain" is in some communities. JavaScript and python notable for their giant reliance on libs.

If I compare a typical Rust project, with a same JavaScript one, JavaScript project itself often has magnitudes more direct dependencies (wide supply chain?). The rust tool will have three or four, the JavaScript over ten, sometimes ten alone to help with just building the typescript in dev. Worsened by the JavaScript dependencies own deps (and theirs, and theirs, all the way down to is_array or left_pad). Easily getting in the hundreds. In rust, that graph will list maybe ten more. Or, with some complex libraries, a total of several tens.

This attitude difference is also clear in Python community. Where the knee-jerk reaction is to add an import, rather than think it through, maybe copy paste a file, and in any case, being very conservative. Do we really need colors in the terminal output? We do? Can we not just create a file with some constants that hold the four ANSI escape codes instead?

I'm trying to argue that there's also an important cultural problem with supply chain attacks to be considered.

To be fair, the advantage of Deno here is really the standard library that includes way more functionality than Node.

But in the end, we should all rely on fewer dependencies. It's certainly the philosophy I'm trying to follow with https://mastrojs.github.io – see e.g. https://jsr.io/@mastrojs/mastro/dependencies

This is how I feel about my Honda, and to some extent, Kubernetes. In the former case I kept a 2006 model in good order for so long I skipped at least two (automobile) generation's worth of car-to-phone teething problems, and after years of hearing people complain about their woes I've found the experience of connecting my iphone to my '23 car pretty hassle-free. In the latter, I am finally moving a bunch of workloads out of EC2 after years of nudging from my higher-ups and, while it's still far from a simple matter I feel like the managed solutions in EKS and GKE have matured and greatly lessen the pain of migrating to K8S. I can only imagine what I would have gotten bogged down with had I promptly acted on my bosses' suggestion to do this six or seven years ago. (I also feel very lucky that the people I work for let me move on these things in my own due time.)

Not in the "npm ecosystem". You're hopelessly behind there if you haven't updated in the last 54 seconds.

Works great for new exploited packages. Not so great for already compromised software getting hit by a worm.

"Just wait 2 weeks to use new versions by default" is an amazing defense method against supply chain attacks.

I'll reply to you tomorrow

Yes, the article's insistence that anyone would have fallen for the phish, and that anyone who disagrees is simply "wrong," is unfortunate. My old corporate phishing training drilled it into my head pretty effectively that you don't follow links in emails if the emails aren't direct responses to actions you've just taken: registering an account, resetting a password, and so forth.

To this day, I don't follow links in other kinds of emails. I mouse over the link to view the domain as a first step in determining how seriously to take the email. If the domain appears to match the known-good one, I copy the link and examine the characters to see if any Unicode lookalikes have been employed.

If the domain seems legitimate, or if I don't recognize it but the email is so convincing that I suspect the company truly is using a different domain (my bank has done this, frustratingly), I still don't click the link. I log in to my account on the known-good domain -- by typing it by hand into the browser's address bar -- and look for notifications.

If there are no notifications, then I might contact the company about the email to verify its authenticity.

If anyone reading thinks that seems like a lot of work, I agree with you! It stinks. But I humbly submit that it's necessary on today's Internet. And it's especially necessary if you're in charge of globally used software libraries.

To adopt the tone of the article's author, if they aren't willing to do that, they're wrong, and they're going to keep getting phished.

> You're a criminal with a one-in-a-million opportunity. Wouldn't you invest an extra week pushing a more fledged out exploit?

Because the way this was pulled off, it was going to be found out right away. It wasn't a subtle insertion, it was a complete account take over. The attacker had only hours before discovery - so the logical thing to do is a hit and run. They asked what is the most money that can be extracted in just a few hours in an automated fashion (no time to investigate targets manually one at a time) and crypto is the obvious answer.

Unless the back doors were so good they weren't going to be discovered even though half the world would be dissecting the attack code, there was no point in even trying.

Stolen cryptocurrency is a sure thing because fraudulent transactions can't be halted, reversed, or otherwise recovered. Things like a random dev's API and SSH keys are close to worthless unless you get extremely lucky, and even then you have to find some way to sell or otherwise make money from those credentials, the proceeds of which will certainly be denominated in cryptocurrency anyway.

Get in, steal a couple hundred grand, get out, do the exact same thing a few months later. Repeat a few times and you can live worry free until retirement if you know to evade the cops.

Even if you steal other stuff, you're going to need to turn it all into cryptocurrency anyway, and how much is an AWS key really going to bring in.

There are criminals that focus on extracting passwords and password manager databases as well, though they often also end up going after cryptocurrency websites.

There are probably criminals out there biding their time, waiting for the perfect moment to strike, silently infiltrating companies through carefully picked dependencies, but those don't get caught as easily as the ones draining cryptocurrency wallets.

The pushed payload didn't generate any new traffic. It merely replaced the recipient of a crypto transaction to a different account. It would have been really hard to detect. Ex-filtrating API keys would have been picked up a lot faster.

OTOH, this modus operandi is completely inconsistent with the way they published the injected code: by taking over a developer's account. This was going to be noticed quickly.

If the payload had been injected in a more subtle way, it might have taken a long time to figure out. Especially with all the levenshtein logic that might convince a victim they'd somehow screwed up.

It is not a one-in-a-million opportunity though. I hate to take this to the next level, but as criminal elements wake up to the fact that a few "geeks" can possibly get them access to millions of dollars expect much worse to come. As a maintainer of any code that could gain bad guys access, I would be seriously considering how well my physical identity is hidden on-line.

You give an example of an incredibly targeted attack of snooping around manually on someone's machine so you can exfiltrate yet more sensitive information like credit card numbers (how, and then what?)

But (1) how do you do that with hundreds or thousands of SSH/API keys and (2) how do you actually make money from it?

So you get a list of SSH or specific API keys and then write a crawler that can hopefully gather more secrets from them, like credit card details (how would that work btw?) and then what, you google "how to sell credentials" and register on some forum to broker a deal like they do in movies?

Sure sounds a hell of a lot more complicated and precarious than swapping out crypto addresses in flight.

> You're a criminal with a one-in-a-million opportunity. Wouldn't you invest an extra week pushing a more fledged out exploit?

The plot of Office Space might offer clues.

Also isn't it crime 101 that greedy criminals are the ones who are more likely to get caught?

API/SSH keys can easily be swapped, it's more hassle than it's worth. Be glad they didn't choose to spread the payload of one of the 100 ransomware groups with affiliate programs.

> My work laptop, depending on the period of my life, you could have had access to stuff you wouldn't believe either.

What gets me is everyone acknowledges this, yet HN is full of comments ripping on IT teams for the restrictions & EDR put in place on dev laptops.

We on the ops side have known these risks for years and that knowledge of those risks are what drives organizational security policies and endpoint configuration.

Security is hard, and it is very inconvenient, but it's increasingly necessary.

Because it's North Korea and crypto currency is the best assets they can get for pragmatic reasons.

For anything else you need a fiat market, which is hard to deal with remotely.

Seems possible to me that someone has done an attack exactly like you describe and just was never caught.

What makes you so sure that the exploit is over? Maybe they wanted their secondary exploit to get caught to give everyone a sense of security? Their primary exploit might still be lurking somewhere in the code?

i fell for this malware once. had the malware on my laptop even with mb in the background. i copy paste and address and didn't even check it. my bad indeed. those guys makes a lot of money from this "one shot" moments

There's nothing wrong with staying focused (on grabbing the money).

Your ideas are potentially lubricative over time, but first it creates more work and risk for the attacker.

As long as we get lucky nothing is going to change.

Maybe their goal was just surviving, not getting rich.

Also, you underestimate how trivial this 'one-in-a-million opportunity' is; it's definitely not a one-in-a-million! Almost anybody with basic coding ability and a few thousand dollars could pull off this hack. There are thousands of libraries which are essentially worthless with millions of downloads and the author who maintains is basically broke and barely uses their npm account anymore. Anybody could just buy those npm accounts under false pretenses for a couple of thousands and then do whatever they want with tens of thousands (or even hundreds of thousands) of compromised servers. The library author is legally within their rights to sell their digital assets and it's not their business what the acquirer does with them.

> find it insane that someone would get access to a package like this, then just push a shitty crypto stealer

Consumer financial fraud is quite big and relatively harmless. Industrial espionage, otoh, can potentially put you in the cross hairs of powerful and/or rouge elements, and so, only the big actors get involved, but in a targeted way, preferring to not leave much if any trace of compromise.

yeah a shitty crypto stealer is more lucrative, more quickly monetized, has less OPSEC issues for the thief if done right, easier to launder

nobody cares about your trade secrets, or some nation's nuclear program, just take the crypto

one in a million opportunity? the guy registered a domain and sent some emails dude. its cheap as hell

Then you have companies like AWS, they were sending invoices from `no-reply-aws@amazon.com` but last month they changed it to `no-reply@tax-and-invoicing.us-east-1.amazonaws.com`.

That looks like a phishing attempt from someone using a random EC2 instance or something, but apparently it's legit. I think. Even the "heads-up" email they sent beforehand looked like phishing, so I was waiting for the actual invoice to see if they really started using that address, but even now I'm not opening these attached PDFs.

These companies tell customers to be suspicious of phishing attempts, and then they pull these stunts.

There's like 1500 TLDs, now some of them are restricted and country-code TLDs but now it makes me wonder how much it would actual cost per year to maintain registration of every non-restricted TLD. I'm sure theres some SaaS company that'll do it.

There are way too many TLDs for this to be even practical: https://data.iana.org/TLD/tlds-alpha-by-domain.txt

I agree that especially larger players should be proactive and register all similar-sounding TLDs to mitigate such phishing attacks, but they can't be outright prevented this way.

This won't work - npm.* npmjs.* npmjs-help.* npm-help.* node.* js.* npmpackage.*. The list is endless.

You can't protect against people clicking links in emails in this way. You might say `npmjs-help.ph` is a phishy domain, but npmjs.help is a phishy domain and people clicked it anyway.

First thing I do is check any domain that I don't recognize as official.

  Domain: NPMJS.HELP (85 similar domains)
  Registrar: Porkbun, LLC (4.84 million domains)
  Query Time: 8 Sep 2025 - 4:14 PM UTC  [1 DAY BACK] [REFRESH]

  Registered: 5th September 2025  [4 days back]
  Expiry: 5th September 2026  [11 months, 25 days left]

> It sets a deadline a few days in the future. This creates a sense of urgency, and when you combine urgency with being rushed by life, you are much more likely to fall for the phishing link.

Any time I feel like I'm being rushed, I check deeper. It would help if everyone's official communications only came from the most well known domain (or subdomain).

That seems like a bad idea compared to just having a canonical domain - people might become used to seeing "npm.<whatever>" and assuming it is legit. And then all it takes is one new TLD where NPM is a little late registering for someone to do something nefarious with the domain.

That’s like insane proportion.

npmjs.help not npm.help - the typo is also in the article.

I don't think that particular measure would help but NPM are the people who brought us the LPad crisis and their wikipedia page has a long string of security failures mentioned on it. Given this, it seems likely their attitude is "we don't care, we don't have to" and their relative success as the world's largest package manager seems to echo that (not that I have any idea whether they make any money).

all that is inside the extension. meaningless if the extension got the changed address.

Exactly! Extremely lazy conclusion.

Yeah, I feel that bit is just wrong, in three ways for me:

1. Like you, I never put credentials into links from emails that I didn’t trigger/wasn’t expecting. This is a generally-sensible practise.

2. Updating 2FA credentials is nonsense. I don’t expect everyone to know this, this is the weakest of the three.

3. If my credentials don’t autofill due to origin mismatch, I am not filling it manually. Ever. I would instead, if I thought it genuine, go to their actual site and log in there, and then see nothing about what the phish claimed. I’ve heard people talking about companies using multiple origins for their login forms and how having to deal with that undermines this aspect, but for myself I don’t believe I’ve ever seen that, not even once. It’s definitely not common, and origin-locked second factors should make that practice disappear altogether.

Now these three are not of equal strength. The second requires specific knowledge, and a phish could conceivably use something similar that isn’t such nonsense anyway. The first is a best practice that seems to require some discipline, so although everyone should do it, it is unfortunately not the strongest. But the third? When you’re using a password manager with autofill, that one should be absolutely robust. It protects you! You have to go out of your way to get phished!

"'such' a phishing attack" makes it sound like a sophisticated, indepth attack, when in reality it's a developer yet again falling for a phishing email that even Sally from finance wouldn't fall for, and although anyone can make mistakes, there is such a thing as negligent, amateur mistakes. It's astonishing to me.

Yes, that was a bit defeatist about phishing and tolerant of poor security. Anyone employing the "hang up, look up, call back" technique would be safe. It sounds like the author doesn't even know that technique and avoids phishing by using intuition.

I've had emails like that from various places, probably legitimate, but I absolutely never click the bloody link from an email and enter my credentials into it! That's internet safety 101.

Is the fundamental problem with npm still a lack of enforced namespacing?

In the Java world, I know there’s been griping from mostly juniors re “why isn’t Maven easy like npm?” (I work with some of these people). I point them to this article: https://www.sonatype.com/blog/why-namespacing-matters-in-pub...

Maven got a lot of things right back in the day. Yes POM files are in xml and we all know xml sucks etc, but aside from that the stodgy focus on robustness and carefully considered change gets more impressive all the time.

Linux distributions packages are also very trust driven — but you have to earn trust to publish. Then there is whole system to verify trust. NPM is more like „everything goes”.

In a case like this, the package maintainer's account itself has been hacked, so I'm not sure if that would be meaningful.

The only solution would be to prevent all releases from being applied immediately.

Someday, someone, hopefully, will fix xkcd 1200.

Should be - open another browser window and manually log into npm whatever, and update your 2fa there.

Definitely good practice .

The Microsoft ecosystem certainly makes this challenging. At work, I get links to Sharepoint hosted things with infinitely long hexadecimal addresses. Otherwise finding resources on Sharepoint is impossible.

> I just try to avoid clicking links in emails generally...

I don't just generally try, I _never_ click links in emails from companies, period. It's too dangerous and not actually necessary. If a friend sends me a link, I'll confirm it with them directly before using it.

And who would control that whitelist? How would it be any different than the domain system or PKI CA system we have now?

Do you think there would be the time to properly review applications to get on the whitelist?

I've always thought it's insane that anyone on the planet with a connection can drop a clickable link in front of you. Clickable links in email should be considered harmful. Force the user to copy/paste

URLs are also getting too damn long

I'm rather convinced that the next major language-feature wave will be permissions for libraries. It's painfully clear that we're well past the point where it's needed.

I didn't think it'll make things perfect, not by a long shot. But it can make the exploits a lot harder to pull off.

Yeah, there's an entire community dedicated to cleaning up the js ecosystem.

https://e18e.dev/

Micro-dependencies are not the only thing that went wrong here, but hopefully this is a wakeup call to do some cleaning.

It wouldn't be a problem if there wasn't a culture of "just upgrade everything all the time" in the javascript ecosystem. We generally don't have this problem with Java libraries, because people pick versions and don't upgrade unless there's good reason.

Yes. It is a bit painful this is not rather obvious by now. But I do have, every code review, whine about people who just include trivial outdated one function npms :(

Working for a bank did make me think much more about all the vulnerabilities that can go into certain tools. The company has a lot of bureaucracy to prevent installing anything or adding external dependencies.

I've nixed javascript in the backend in several places, partly because of the weird culture around dependencies. Having to audit that for compliance, or keeping it actually secure, is a nightmare.

Nixing javascript in the frontend is a harder sell, sadly

Throwback to leftpad!

Hey that was also on NPM iirc!

What I'd like to know is why anyone thinks it's a good idea to have this level of granularity in libraries? Seriously? A library that only contains "a utility function that determines if its argument can be used like an array"? That's a lot of overhead in dependency management, which translates into a lot of cognitive load. Sooner or later, something's going to snap...and something did, here.

It wasn't a "normal person" it was a developer that put this into a README of his package

> But beyond the technical aspects, there's something more critical: trust and long-term maintenance. I have been active in open source for over a decade, and I'm committed to keeping Chalk maintained. Smaller packages might seem appealing now, but there's no guarantee they will be around for the long term, or that they won't become malicious over time.

I expect him to know better.

To state the obvious, one ends with "help" on with "com". It effectively is phishing awareness 101 that domains need to match.

You still don't know then of course. When in doubt you shouldn't do the action that is asked through clicking on links in the mail. Instead go to the domain you know to be legit and execute the action there.

Having said all that, even the most aware people are only human. So it is always possible to overlook a detail like that.

For TOTP it's as simple as scanning a new QR code.

I agree that rotating 2FA should ring alarm bells as an unusual request. But that requires thinking.

The claim is valid -- it is legit from npm.help

If you think npm.help is something it isn't, that's not something DKIM et al can help with.

My man, it has...in the worse direction...

Agreed; the rich standard library from Microsoft is one of the many things I appreciate about C#.

The article's author seems to be under the misapprehension that standard libraries should or have to be community-driven like Node's and that falling for phishing attacks is inevitable over a long enough period of time. Neither notion is accurate.

Log4Shell didn't light up all the beacons because Java is "enterprisey", it was because it was probably the worst security vulnerability in history; not only was the package extremely widely used, the vulnerability existed for nearly a decade and was straightforwardly wormable, so basically everybody running Java code anywhere had to make sure to update and check that they hadn't been compromised. Which is just a big project requiring an all-out response, since it's hard to know where you might have something running. By contrast, this set of backdoors only existed for a few hours, and the scope of the vulnerability is well-understood, so most developers can be pretty sure they weren't impacted and will have quite reasonably forgotten about it by next week. It's getting attention because it's a cautionary tale, not because it's causing a substantial amount of real damage.

I do think it's worth reducing the number of points of failure in an ecosystem, but relying entirely on a single library that's at risk of stagnating due to eternal backcompat obligations is not the way; see the standard complaints about Python's "dead batteries". The Debian or Stackage model seems like it could be a good one to follow, assuming the existence of funding to do it.

Heartbleed? Solarwinds? Spectre/Meltdown? Stuxnet? Eternal Blue? CVE-2008-0166 (debian predictable private keys)?

Solarwinds?

When we do the phishing awareness training at $WORK, we are told any sense of urgency is suspicious, especially from an established org. Most would give you at least a month before something as draconian as locking your account.

Deno has taken steps in this direction. It’s probably doable for pure js packages, but nearly impossible for packages with native extensions.

That's exactly what I do, and have caught quite a lot of other phishing emails this way. They queried my npm email via the public API and sent it there.

Didn't expect things to grow how they have, that's for sure! Hope you've been well :)

This page has a short explanation of the default way in which Go downloads modules, with links for more details: https://sum.golang.org/

Anecdotally throughout all this, contacting npm got me a response from githubsupport.com. I had to double check if that was even real.

Facebook sends legit account secuirty emails from facebookmail.com. Horrible.

of all people my mortgage servicer is the worst about this. Your login is valid on like 3 different top level domains and you get bounced between them when you sign in, eventually going from servicer.com to myservicer.com to servicer.otherthing.com! It's as though they were training you to not care about domain names.

What about aka.ms, which is a valid domain for Microsoft. Why didn't they use microsoft.com, or windows.com? I always wonder if this aka is short for 'also known as'.

    Authentication-Results: aspmx1.migadu.com;
        dkim=pass header.d=smtp.mailtrap.live header.s=rwmt1 header.b=Wrv0sR0r;
        dkim=pass header.d=npmjs.help header.s=rwmt1 header.b=opuoQW+P;
        spf=pass (aspmx1.migadu.com: domain of ndr-cbbfcb00-8c4d-11f0-0040-f184d6629049@mt86.npmjs.help designates 45.158.83.7 as permitted sender) smtp.mailfrom=ndr-cbbfcb00-8c4d-11f0-0040-f184d6629049@mt86.npmjs.help;
        dmarc=pass (policy=none) header.from=npmjs.help

This was a domain "legitimately" owned by the adversary. They controlled that DNS. They could set any SPF or DKIM records they wanted. This email probably passed all DMARC checks. From some screenshots, the email client even has a green check probably because it did pass DMARC.

`Symbol` wasn't supported when I wrote `is-arrayish`. Neither were spreads. It was meant to be used with DOM lists or the magical `arguments` variable.

Password managers are still too unreliable to auto-fill everywhere all the time, and manually having to copy paste something from the password manager happens regularly so it's not something that feels unusual if it doesn't auto-fill it for some reason.

Better yet, use password manager as the store of the valid domain and click there to go to resource.

I don't think this really helps. I use Bitwarden and it constantly fails to autofill legitimate websites and makes me go to the app to copy-paste, because companies do all kinds of crap with subdomains, marketing domains, etc. Any safeguard relying on human attention is ultimately susceptible to this; the only true solutions are things like passkeys where human fuckups are impossible by design and they can't give credentials to the wrong place even if they want to.

Passkeys are disruptive enough that I don't think they need to be mandated for everyone just yet, but I think it might be time for that for people who own critical dependencies.

what do you mean bankofamericaabuse.com isn't a real website!? It's in the email and everything! The nice guy on the phone said it was legit...

> Always use password manager to automatically fill in your credentials

Absolutely not.

https://www.malwarebytes.com/blog/news/2025/08/clickjack-att...

https://thehackernews.com/2025/08/dom-based-extension-clickj...

https://www.intercede.com/the-dangers-of-password-autofill-a...

I'm not sure whether the compromised packages were the source of Kiln's API compromise, but it's plausible. It lead to theft of $41M worth of SOL. https://cointelegraph.com/news/swissborg-hacked-41m-sol-api-...

According to a crypto tracking site linked indirectly via the other popular submission, about $500 worth of crypto.

5 cents of eth and $20 of a meme coin.

Who should have stopped this from happening and how should they have gone about doing so?

That kind of fake self-aggrandizement-delusion-driven story telling is part of the autistic trans subculture. That particular subculture tends to speak of themselves as goddesses, wizards, or other higher beings. Their websites are usually dark themed with pastel or neon forecolors and you'll find anime girls inserted every now and then .

As far as I can tell it isn't a joke per se, but it is tongue-in-cheek and the ego is often very real.

Hi, said person who clicked on the link here. Been wanting to post something akin to this and was going to save it for the post mortem but I wanted to address the increase in these sort of very shout-ey comments directed toward me.

> What does that even mean? That's not something that can be updated - that's kind of the point of 2FA.

I didn't sit and read and parse the whole thing. That was mistake one. I have stated elsewhere, I was stressed and in a rush, and was trying to knock things off my list.

Also, 2FA can of course be updated. npm has had some shifts in how it approaches security over the years, and having worked within that ecosystem for the better part of 10-15 years, this didn't strike me as particularly unheard of on their part. This, especially after the various acquisitions they've had.

It's no excuse, just a contributing factor.

> It would be very unusual to write like that in a formal security notification.

On the contrary, I'd say this is pretty par for the course in corpo-speak. When "kindly" is used incorrectly, that's when it's a red flag for me.

> What does "temporarily locked" mean? That's not a thing. Also creating a sense of urgency is a classic phishing technique and a red flag.

Yes, of course it is. I'm well aware of that. Again, this email reached me at the absolute worst time it could have and I made a very human error.

"Temporarily locked" surprises me that it surprises you. My account was, in fact, temporarily locked while I was trying to regain access to it. Even npm had to manually force a password reset from their end.

> Any nonstandard domain is a red flag.

When I contacted npm, support responded from githubsupport.com. When I pay my TV tax here in Germany (a governmental thing), it goes to a completely bizarre, random third party site that took me ages to vet.

There's no such thing as a "standard" domain anymore with gTLDs, and while I should have vetted this particular one, it didn't stand out as something impossible. In my head, it was their new help support site - just like github.community exists.

Again - and I guess I have to repeat this until I'm blue in the face - this is not an excuse. Just reasons that contributed to my mistake.

> NEVER EVER EVER click links in any kind of security alert email.

I'm aware. I've taught this as the typical security person at my respective companies. I've embodied it, followed it closely for years, etc. I slipped up, and I think I've been more than transparent about that fact.

I didn't ask for my packages to be downloaded 2.6 billion times per week when I wrote most of these 10 years ago or inherited them more than five ago. You can argue - rightfully - about my technical failure here of using an outdated form of 2FA. That's on me, and would have protected against this, but to say this doesn't happen to security-savvy individuals is the wrong message here (see: Troy Hunt getting phished).

Shit happens. It just happened to happen to me, and I happen to have undue control over some stuff that's found its way into most of the javascript world.

The security lessons and advice are all very sound - I'm glad people are talking about them - but the point I'm trying to make is, that I am a security aware/trained person, I am hyper-vigilant, and I am still a human that made a series of small or lazy mistakes that turned into one huge mistake.

Thank you for your input, however. I do appreciate that people continue to talk about the security of it all.

full of red flags present in many non phishing emails

> However security ignorant companies do send emails like this

exactly

The blog author is also the creator of Anubis

I used to share this article with students https://david-gilbertson.medium.com/im-harvesting-credit-car...

Artifactory works fairly well. Although admittedly, when a user grabs a new dependency, they're downloading from the npmjs registry like anyone else.

Really, the killer combo would be to have some kind of LLM-based tool that would scan someone's artifactory. Something smart enough to notice that code changed, and there's code for accessing a crypto-wallet, etc. This would be too expensive for npmjs to host for free, but I could see this happen to hosted artifactory dependencies.

Artifactory. Nexus. I believe AWS/GCP/Azure have offerings.

No bank, and almost no large corporations go directly to artifact/package repos. They all host them internally.

I'm looking at Verdaccio currently, since Artifactory is expensive and I think the CE version still only supports C++. Does anyone have any experience with Verdaccio?

Something like this? https://jfrog.com/artifactory/

the company that first found this vulnerability also has a tool for this https://www.npmjs.com/package/@aikidosec/safe-chain

This wasn't a repository takeover. I do sign my commits.

I think it's quite good, there's a sense of urgency, but it's also not "immediately change it!" they gave more than a day, and stated that it would be a temporary lock. Feel like this one really hit the spot on that aspect.

You should still never click a link in an email like this, but the urgency factor is well done here

I go through those trainings several times a year. That email is as close to perfect for a phishing email as I've ever seen.

> the email wasn't that great

It was obviously good enough.

Snark aside, you only need to trick one person once and you've won.

I'm not a top-level expert in cybersecurity nor email infra....but the little that i know has taught me that i merely have to create a similar-looking domain name...

Let's say there's a company named Awesome...and i register the domain name of AwesomeSupport.com. I could be a total dark hat/evil hacker/neverdoweller....and this domain may not be infringing on any trademark, etc. And, then i can start using all the encryption you noted...which merely means that *my domain name* (the bad one) is "technically sound"...but of course, all that use of encryption fails to convey that i am not the legitimate Awesome company. So, how is the victim supposed to know which of the domains is legit or not? Especially considering that some departments of the real, legit Awesome company might register their own domain name to use for actual, real reasons - like the marketing department might register MyAwesome.com...for managing customer accounts, etc.

Is encryption necessary in digital life? Hellz yeah! Does it solve *all issues*? Hellz no! :-)

I might be missing the joke, but there are several layers like SPF and DMARC available to only allow your whitelisted servers to send email on the behalf of your domain.

Wouldn't help in this case where someone bought a domain that looked a tiny bit like the authentic one for a very casual observer.

100% solved and has been for a very long time. The PGP/GPG trust chain goes CLUNK CLUNK CLUNK. Everyone shuts it off after a week or so of experimentation.

Please don't copy-paste comments on HN. It strictly lowers the signal/noise ratio.

> 1. NEVER EVER login from an email link. EVER. There are enough legit and phishing emails asking you to do this that it's basically impossible to tell one from the other. The only way to win is to not try.

Sites choosing to replace password login with initiating the login process and then clicking a "magic link" in your email client is awful for developing good habits here, or for giving good general advice. :c

> 1. NEVER EVER login from an email link.

I receive Google Doc links periodically via email; fortunately they're almost never important enough for me to actually log in and see what's behind them.

My point, though, is that there's no real alternative when someone sends you a doc link. Either you follow the link or you have to reach out to them and ask for some alternative distribution channel.

(Or, I suppose, leave yourself logged into the platform all the time, but I try to avoid being logged into Google.)

I don't know what to do about that situation in general.

> 2. U2F/Webauthn key as second factor is phishing-proof. TOTP is not.

TOTP doesn't need to be phishing-proof if you use a password manager integrated with the browser, though.

> U2F/Webauthn key as second factor is phishing-proof. TOTP is not.

Last I checked, we're still in a world where the large majority of people with important online accounts (like, say, at their bank, where they might not have the option to disable online banking entirely) wouldn't be able to tell you what any of those things are, and don't have the option to use anything but SMS-based TOTP for most online services and maybe "app"-based (maybe even a desktop program in rare cases!) TOTP for most of the rest. If they even have 2FA at all.

Urgency is also either phishing (log in now or we'll lock you out of your account in 24 hours) or marketing (take advantage of this promotion! expires in 24 hours!).

Just ... don't.

NPM needs to do better. Almost think there needs to be regulations / fines unfortunately.

If I sell corn syrup for downstream food consumers and dont lock my factory doors and let whoever walk in, isn't it reckless?

I watched a presentation from Stripe internal eng that was given I forget where.

An internal engineer there who did a bunch of security work phished like half of her own company (testing, obviously). Her conclusion, in a really well-done talk, was that it was impossible. No human measures will reduce it given her success at a very disciplined, highly security conscious place.

The only thing that works is yubikeys which prevent this type of credential + 2fa theft phishing attack.

edit:

karla burnette / talk https://www.youtube.com/watch?v=Z20XNp-luNA

Is there somewhere you'd recommend that I can read more about the pros/cons of TOTP? These authenticator apps are the most common 2FA second factor that I encounter, so I'd like to have a good source for info to stay safe.

I agree that #1 is correct, and I try to practice this; and always for anything security related (update your password, update your 2FA, etc).

Still, I don’t understand how npmjs.help doesn’t immediately trigger red flags… it’s the perfect stereotype of an obvious scam domain. Maybe falling just short of npmjshelp.nigerianprince.net.

#1 is the real deal. Just like you don't give private info to any caller you aren't expecting. You call them back at a number you know.

Here's the actual root cause of the issue:

1- As a professional, installing free dependencies to save on working time.

There's no such thing as a free lunch, you can't have your cake and eat it too that is, download dependencies that solve your problems, without paying, without ads, without propaganda (for example to lure you into maintaining such projects for THE CAUSE), without vendor lockin or without malware.

It's really silly to want to pile up mountains of super secure technology like webauthn, when the solution is just to stop downloading random code from the internet.

Most mail providers have something like plus addressing. Properly used that already eliminates a lot of phishing attempts: If I get a mail I need to reset something for foobar, but it is not addressed to me-foobar (or me+foobar) I already know it is fraudulent. That covers roughly 99% of phishing attempts for me.

The rest is handled by preferring plain text over HTML, and if some moron only sends HTML mails to carefully dissect it first. Allowing HTML mails was one of the biggest mistakes for HTML we've ever made - zero benefits with huge attack surface.

No, the solution to a security problem is not to radically increase the vulnerable attack surface.

> Where is this entitlement coming from? They hide that behind some fictional persona, as if that changes anything.

I hardly think a polite request is entitlement.

NPM should promptly email everyone to upgrade their 2FA

Furries tend to be high in curiosity, high in trait-openness, and lower in social conformance. It's a good recipe for learning, thinking and questioning.