Live data from Hacker News

We all dodged a bullet

xeiaso.net

461–470 of 498 posts

Re: We all dodged a bullet

#461

Not a security expert but I don’t think that requesting a reset of your 2FA credentials is reasonable. I would be very worried about my 2FA provider if they asked me to do this. And so I would not rate this phishing email a 10/10 at all.

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…

> Yes, the article's insistence that anyone would have fallen for the phish, and that anyone who disagrees is simply "wrong," is unfortunate

I think that's overstated. This phishing attempt had some obvious red flags that many people here would have noticed, sure. So not everyone is going to fall for this phish.

But the principle is better expressed as "Everyone will fall for a phish", somewhere. Even you. Human engineering is human engineering and we're all fallible. All that's required is that someone figure out which mistakes you're likely to make.

Re: We all dodged a bullet

#462

The nx supply chain attack via npm was the bullet many companies did not doge. I mean, all you needed was to have the VS Code nx plugin installed — which always checked for the latest published nx version on npm. And if you had a local session with GitHub (eg logged into your company’s account via the GH CLI), or some important creds in a .env file… that was exfiltrated. This happened even if you had pinned dependenc…

wow. i uninstalled the nx plugin a few weeks ago after completing the migration to pnpm.

Re: We all dodged a bullet

#463

I know this isn't really possible for smaller guys but larger players (like NPM) really should buy up all the TLD versions of "npm" (that is: npm.io, npm.sh, npm.help, etc). One of the reasons this was so effective is that the attacker managed to snap up "npm.help"

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] I'd be suspicious of anything registered with Porkbun discount registrar. 4 days ago, means it's fake.…

> 4 days ago, means it's fake.

Heuristics like this one should be performed automatically by the email client.

Re: We all dodged a bullet

#464
post #231

> If you were targeted with such a phishing attack, you'd fall for it too and it's a matter of when not if. Anyone who claims they wouldn't is wrong. I like to think I wouldn't. I don't put credentials into links from emails that I didn't trigger right then (e.g. password reset emails). That's a security skill everyone should be practicing in 2025.

Anyone can be fallible in the right circumstances. Maybe you're tired, unwell, in a rush, or otherwise distressed and not thinking straight. Maybe a malicious actor accidentally crafts a scam that coincides with specific details from your life. Perhaps the scam centres around some system you have less expertise in.

The point of not assigning blame isn't to absolve people of the need to have their guard up but to recognise that everyone is capable of mistakes.

Re: We all dodged a bullet

#465
post #394
post #280

Daily reminder that no one can easily impersonate you if you sign your commits and make it easy to discover and verify your authentic key with keyoxide or similar.

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

Fair. I should have expanded.

If everyone signed commits with well published keys, -and- if NPM would stop rejecting every PR and feature request for clients to verify signatures from authors that opt in, this problem would not exist for packages from those authors.

Unfortunately the official position of NPM since 2013 is that hashes solve the same security problem as signatures and that the signatures might make non signing package authors second class citizens. So no security for anyone, to avoid scaring off lazy maintainers.

https://github.com/npm/npm/pull/4016

Re: We all dodged a bullet

#466

Earlier quoted context omitted.

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 workload…

In the meantime you had for years a car without connecting your iphone, so you completely didn't have that feature! There are pros and cons everywhere, but I'm more prone to change often and fix things that wait for feature to be stable and meantime do without them. Of course, when I can afford it, e.g. not in changing my car every two years :')

> In the meantime you had for years a car without connecting your iphone, so you completely didn't have that feature!

Such a feature can be added.

Re: We all dodged a bullet

#467
post #333

Earlier quoted context omitted.

Gotcha. When I was, we actively curated our dependencies and maintaining them was a regularly scheduled task that one team member in particular was in charge of making sure got done.

most teams I've been around have zero or one person who handles that (because they're passionate) (this is usually me) - tbh I think that's probably the majority case. exceptions totally exist, I've seen them too. I just don't think they're enough to move the median away from "total chaotic garbage" regardless of the system

This is why I secretly hate the term software engineer. "Software tinker" would be more appropriate.

Re: We all dodged a bullet

#468

Earlier quoted context omitted.

Absolutely not. Ops are the ones who imposed those constraints. You can't impose absurd constraints and then say you are acting reasonable by abiding by your own absurd constraints.

How do you even know it was a single individual’s decision, let alone who exactly imposed the constraints?

I don't, and I never said that.

I'm not dumping on the ops person, but the ops and security team's processes. If you as a developer showed up to a new workplace and the process was that for every code change you had to print out a diff and mail a hard copy to the committee for code reviews, you would be totally justified in calling out the process as needlessly elaborate. Anyone could rightly say that your processes are increasing friction while not actually serving the purpose of having code reviewed by peers. You as a developer have a responsibility to point out that the current process serves no one and should be changed. That's what good security and ops people do too.

In the real world case I am talking about, we can easily foresee that the end result is that the exemption will be allowed, and there will be no security impact. In no way does the process at all contribute to that, and every person involved knows it.

My original post was about how people dislike security when it is actually security theater. That is what is going on here. We already know how this issue ends and how that can be accomplished (document the false alarm, and click the ignore button), and have already done the important part of documenting the issue for posterity.

The process could be: you are a highly paid developer who takes security training and has access to highly sensitive systems so we trust your judgment, when you and your peers agree that this isn't an issue, write that down in the correct place, click the ignore button and move on with your work.

All of the faff of contacting different fiefdoms and submitting tickets does nothing to contribute to the core issue or resolution, and certainly doesn't enhance security. If anything, security theater like this leads to worse security since people will try to find shortcuts or ways of just not handling issues.

Re: We all dodged a bullet

#469
post #435

Earlier quoted context omitted.

>maybe we shouldn't let registrars sell npm. regardless of the TLD Cool, get big enough, become friends with the right people and you can squat an entire name on the internet. What, you're the Nepalese Party for Marxists, you've existed for 70 years and you want to buy npm.np ? Nope, tough luck, some random dude pushes shitty javascript packages over there. Sorry for the existing npm.org address too, we're going to e…

> Cool, get big enough, become friends with the right people and you can squat an entire name on the internet. What, you're the Nepalese Party for Marxists, you've existed for 70 years and you want to buy npm.np ? I think you and I have drastically different ideas about how dramatic a response is warranted by the scenario of needing to buy a domain with a different three letters or maybe even four or more letters bef…

[dead]

Re: We all dodged a bullet

#470
post #372
post #272

Earlier quoted context omitted.

If Kevin mitnick shows up or is referenced then I’m pretty sure it’s performance art

If only, it would've been an honour to get phished by Mitnick. Rest in peace...

Years of useless knowB4 trainings with him in the video have given me a twitch whenever I hear him referenced
Post reply on HN