[cataflam]

Besides the ecosystem issues, for the phishing part, I'll repost what I responded somewhere in the other related post, for awareness

---

I figure you aren't about to get fooled by phishing anytime soon, but based on some of your remarks and remarks of others, a PSA:

TRUSTING YOUR OWN SENSES to "check" that a domain is right, or an email is right, or the wording has some urgency or whatever is BOUND TO FAIL often enough.

I don't understand how most of the anti-phishing advice focuses on that, it's useless to borderline counter-productive.

What really helps against phishing :

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.

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

That is all there is. Any other method, any other "indicator" helps but is error-prone, which means someone somewhere will get phished eventually. Particularly if stressed, tired, or in a hurry. It just happened to be you this time.

[dang]

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

[cataflam]

My apologies, somehow after all these years, I didn't know that (and first time I've done it)!

[nalllar]

> 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

[kyle-rb]

In that case it's the same as a reset-password flow.

In both cases it's good advice not to click the link unless you initiated the request. But with the auth token in the link, you don't need to login again, so the advice is still the same: don't login from a link in your email; clicking links is ok.

[tomsmeding]

Clicking links from an email is still a bad idea in general because of at least two reasons:

1. If a target website (say important.com) sends poorly-configured CORS headers and has poorly configured cookies (I think), a 3rd-party website is able to send requests to important.com with the cookies of the user, if they're logged in there. This depends on important.com having done something wrong, but the result is as powerful as getting a password from the user. (This is called cross-site request forgery, CSRF.)

2. They might have a browser zero-day and get code execution access to your machine.

If you initiated the process that sent that email and the timing matches, and there's no other way than opening the link, that's that. But clicking links in emails is overall risky.

[johnecheck]

1 is true, but this applies to all websites you visit (and their ads, supply chain, etc). Drawing a security boundary here means never executing attacker-controlled Javascript. Good luck!

2 is also true. But also, a zero day like that is a massive deal. That's the kind of exploit you can probably sell to some 3 letter agency for a bag. Worry about this if you're an extremely high-value target, the rest of us can sleep easy.

[kiitos]

how is this any worse than a spear phishing email that gives a login link to a malicious domain that looks the same as the official domain?

[x0x0]

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

[cataflam]

Yes! Here is the whitepaper (from 2017 I think), I read that and used it, it's excellent

https://karla.io/files/ichthyology-wp.pdf

> At Stripe, rather than focusing on mitigating more basic attacks with phishing training, we decided to invest our time in preventing credential phishing entirely. We did this using a combination of Single Sign On (SSO), SSL client certificates, and Universal Second Factor (U2F)

[macintux]

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

[zargon]

> leave yourself logged into the platform all the time

Or only log in when you need to open a google link. Or better yet, use a multi-account container for google.

[macintux]

Yeah, this should have occurred to me. I guess for me it's alien to think about logging into Google.

[zahlman]

> Or better yet, use a multi-account container for google.

Pardon; a what? Got any reference links?

[vel0city]

A Firefox plugin/feature, probably also available on other browsers as well. It is useful for siloing cookies, so you can easily be logged into Google on one set of browser tabs and block their cookies on another.

https://addons.mozilla.org/en-US/firefox/addon/multi-account...

[cataflam]

As for any of these cases, we do receive legitimate emails that require being logged in, Google or otherwise

The answer is simple: use your bookmarks/password manager/... to login yourself with a URL you control in another tab and come back to the email to click it

(and if it still asks for a login then, of course still don't do it)

[tempestn]

Log into Google, then click the link. If you get prompted to log in again, don't.

[macintux]

Good point, I guess this is the obvious answer.

[progval]

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

[ameliaquining]

A browser-integrated password manager is only phishing-proof if it's 100% reliable. If it ever fails to detect a credential field, it trains users that they sometimes need to work around this problem by copy-pasting the credential from the password manager UI, and then phishers can exploit that. AFAIK all existing password manager extensions have this problem, as do all browsers' native password-management features.

[xboxnolifes]

It doesnt need to be 100% reliable, just reliable enough.

If certain websites fail to be detected, thats a security issue on those specific websites, as I'll learn which ones tend to fail.

If they rarely fail to detect in general, its infrequent enough to be diligent in those specific cases. In my experience with password managers, they rarely fail to detect fields. If anything, they over detect fields.

[ameliaquining]

I think this security model requires nontechnical users to be paying more consistent attention than is realistically safe to rely on.

[shhsshs]

I think it's more appropriate to say TOTP /is (nearly)/ phishing-proof if you use a password manager integrated with the browser (not that it /doesn't need to be/ phishing-proof)

[zahlman]

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

[ameliaquining]

This is the point of the "passkey" branding. The idea is to get to the point where these alphabet-soup acronyms are no longer exposed to normal users and instead they're just like "oh, I have to set up a passkey to log into this website", the way they currently understand having to set up a password.

[zahlman]

Sure. That still doesn't make Yubikey-style physical devices (or desktop keyring systems that work the same way) viable for everyone, everywhere, though.

[ameliaquining]

Yeah, the pressure needs to be put on vendors to accept passkeys everywhere (and to the extent that there are technical obstacles to this, they need to be aggressively remediated); we're not yet at the point where user education is the bottleneck.

[cataflam]

Indeed.

At least the crowd here should _know_ that TOTP doesn't do anything against phishing, and most of the critical infrastructure for code and other things support U2F so people should use it.

[nottorp]

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.

[b112]

It's funny how it's never "don't" too.

A guy I knew needed a car, found one, I told him to take it to a mechanic first. Later he said he couldn't, the guy had another offer, so he had to buy it right now!!!, or lose the car.

He bought, had a bad cylinder.

False urgency = scam

[ameliaquining]

I mean, real deadlines do exist. The better heuristic is that, if a message seems to be deliberately trying to spur you into immediate action through fear of missing a deadline, it's probably some kind of trick. In this respect, the phishing message that was used here was brilliantly executed; it calmly, without using panic-inducing language, explains that action is required and that there's a deadline (that doesn't appear artificially short but in fact is coming up soon), in a way quite similar to what a legitimate action-required email would look like. Even a savvy user is likely to think "oh, I didn't realize the deadline was that soon, I must have just not paid attention to the earlier emails about it".

[nottorp]

With credentials? Aren’t you always forced to refresh them right after a login?

As in right then, without being given a deadline…

[ameliaquining]

Yeah, this particular situation's a bit weird because it's asking the user to do something (rotate their 2FA secret) that in real life is not really a thing; I'm not sure what to think of it. But you could imagine something similar like "we want you to set up 2FA for the first time" or "we want you to supply additional personal information that the government has started making us collect", where the site might have to disable some kind of account functionality (though probably not a complete lockout) for users who don't do the thing in time.

[unethical_ban]

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

[glial]

I had someone from a bank call me and ask for my SSN to confirm my identity. The caller ended up being legitimate, but I still didn't give it...like, are you kidding me?

[RussianCow]

This has happened to me more times than I can count, and it's extremely frustrating because it teaches people the wrong lesson. The worst part is they often get defensive when you refuse to cooperate, which just makes the whole thing unnecessarily more stressful.

[Muromec]

I would be surprised if the database with SSN of all adult americans wasn't out there on the usual data dumps website available for 5 dollars.

[JoRyGu]

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.

[giveita]

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?

[TZubiri]

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.

[n8cpdx]

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.

[cataflam]

> update your password, update your 2FA

should practice it for ENTER your password, ENTER your 2FA ;)

> Still, I don’t understand how npmjs.help doesn’t immediately trigger red flags

1. it probably did for quite a few recipients, but that's never going to be 100% 2. not helped by the current practices of the industry in general, many domains in use, hard sometimes to know if it's legit or not (some actors are worse in this regard than others)

Either way, someone somewhere won't pay enough attention because they're tired, or stressed out, or they are just going through 100 emails, etc.

[finaard]

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.

[cataflam]

Still would have done nothing in this case, as they pulled the correct email address he uses for npm from another source (public API I think?).

That's exactly why I said all the other "helpful" recommendations and warning signs people are using are never foolproof, and thus mostly useless given the scale at which phishing campaigns operate.

Great if it helps you in the general case, terrible if it lulls you into a sense of confidence when it's actually a phishing email using the right email address.