Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We all dodged a bullet

xeiaso.net

Post reply on HN
Print view View original

341–350 of 498 posts

Re: We all dodged a bullet

#341

Post by foxglacier »

Zak wrote: 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.

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.

Re: We all dodged a bullet

#342

Post by foxglacier »

jowea wrote: post #309
gcau wrote: post #267

Earlier quoted context omitted.

"'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.

I feel that most everyone has some 0.0001% chance of falling for a stupid trick. And at scale, a tiny chance means someone will fall for it.

That's true but it's like saying most everyone has a small chance of crashing their car. Yet when someone crashes their car because they were texting while driving, speeding, or drunk, we justifiably blame them for it instead of calling them unlucky. We can blame them because there are clear rules they are supposed to know for safety when driving, just as there are for electronic security. The rule for avoid phishing is called "hang up, look up, call back".

Re: We all dodged a bullet

#343

Post by foxglacier »

duxup wrote: post #130
viraptor wrote: post #26

Earlier quoted context omitted.

That's what the Australian Tax Office does. Just a plaintext message that's effectively "you've got a new message. Go to the website to read it."

All my medical places I use do that, with the note that you can also use their app. Good system.

Unfortunately, my doctor's office texts me their bank account number saying "please pay $75 to this account". It told them that's putting people at risk of phishing but they didn't care.

Re: We all dodged a bullet

#344

Post by joe_the_user »

_fat_santa wrote: post #13

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"

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).

Re: We all dodged a bullet

#346

Post by keyle »

"saved by procrastination!" made me smile.

One of the common cases of being offline first, disconnected etc. pays off.

Don't rush. Work on Hawaiian clock!

Re: We all dodged a bullet

#347

Post by chrismorgan »

Zak wrote: 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.

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!

Re: We all dodged a bullet

#348

Post by zer00eyz »

RVuRnvbM2e wrote: post #290
kardianos wrote: post #277

Earlier quoted context omitted.

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

Fucking this. I have seen so many takes lamenting how this kind of supply chain attack is such a difficult problem to fix. No it really isn't. It's an ecosystem and cultural problem that npm encourages huge dependency trees that make it impractical to review dependency updates so developers just don't.

> It's an ecosystem and cultural problem that npm encourages huge dependency trees

It is an ecosystem and culture that learned nothing from the debacle of left pad. And it is an affliction that many organizations face and it is only going to get worse with the advent of AI assisted coding (and it does not have to be).

There simply arent enough adults in the room with the ability to tell the children (or VC's and business people) NO. And getting an "AI" to say no is next to impossible unless you're probing it on a "social issue".

Re: We all dodged a bullet

#349

Post by 0xDEAFBEAD »

SahAssar wrote: post #226
sega_sai wrote: post #97

It seems to me that having an email client that simply disables all the links in the email is probably a good idea. Or maybe, there should be explicit white-listing of domains that are allowed to be hyperlinks.

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?

Presumably Gmail already has anti-spam features which trigger based on domain name etc.

They could add anti-phish features which force confirmation before clicking a link to an uncommon domain. Startups could pay a nominal fee to get their domain reviewed and whitelisted.

Re: We all dodged a bullet

#350

Post by mrbluecoat »

quectophoton wrote: post #99
mrbluecoat wrote: post #80

Does the Go ecosystem have a similar security screening process as NPM? This was caught because a company was monitoring a centralized packaging distribution platform, but I worry about all those golang modules spread across GitHub without oversight..

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

Thanks. It took a little more digging from that link but I eventually found https://go.dev/doc/security/vuln/#vulnerability-detection-fo...
Post reply on HN