I'm not exactly pro-AI, but even I can see that their system clearly works well in this case. If you tune the model to favour false positives, with a human review step (that's quick), I can image your response time being cut from days to hours (and your customers getting their updates that much faster).

He literally said "Flagged packages are escalated to a human review team." in the second sentence. Wtf is the problem here?

> We use a mix of static analysis and AI. Flagged packages are escalated to a human review team.

“Chat, I have reading comprehension problems. How do I fix it?”

"LLM bad"

Very insightful.

It's actually pretty easy to detect that something is obfuscated, but it's harder to prove that the obfuscated code is actually harmful. This is why we still have a team of humans review flagged packages before we try to get them taken down, otherwise you would end up with way too many false positives.

Probably. It’s trivial to plug some obfuscated code into an LLM and ask it what it does.

They're profiting off helping to solve the problem through early warning and detection. And by keeping their customers safe from stuff like this.

Seems good to me. I want more attention and more tooling around this problem. You seem mad at them for helping solve a real problem?

When we find malware on any registry (npm, rubygems, pypi or otherwise), we immediately report it to the upstream registry and try to get it taken down. This helps reduce the blast radius from incidents like this and mitigates the damage done to the entire ecosystem.

You can call it ambulance chasing, but I think this is a good thing for the whole software ecosystem if people aren't accidentally bundling cryptostealers in their web apps.

And regarding not copying massive trees of untrusted dependencies: I am actually all for this! It's better to have fewer dependencies, but this is also not how software works today. Given the imperfect world we have, I think it's better to at least try to do something to detect and block malware than just complain about npm.

> Do I need any? Automated tools cannot prevent malicious code being injected. While they can make attempts to evaluate common heuristics and will catch low hanging malware, they are not fool proof against highly targeted attacks.

So just because a lock isn't 100% effective at keeping out criminals we shouldn't lock our doors?

The more tools that exist to help find vulnerabilities, the better, as long as they're not used in a fully automated fashion. Human vetting is vital, but using tools to alert humans to such issues is a boon.

Passkeys can be a pain in the ass too. Evidentially I set up my Yubikey with Github as some point, which is fine if I'm at my desktop where my key is plugged in, but if I want to sign in on mobile.... now what? I just couldn't log in on mobile for months until I realized I think there's a button on there somewhere that's like "use different 2fa" but then what was even the point of having a key registered if it can be bypassed.

Do not give them permission to your clipboard. It is possible today. I copy and paste passwords and I clear the clipboard afterwards, and I do not use junk like Spotify, and were I to use Spotify, it would be through the browser, not the application. Were it the application, it would be firejailed to oblivion.

It is possible to restrict clipboard access when running applications inside Firejail, i.e. Firejail allows you to restrict access to X11 and Wayland sockets, which prevents the sandboxed application from reading or writing to the system clipboard. See: "--x11=none", "--private=...", "--private-tmp", and so forth. You can run a GUI app with isolated clipboard via "firejail --x11=xvfb app".

For Wayland, you should block access to the Wayland socket by adding "--blacklist=/run/user/*/wayland-*".

I do not use autofill on desktop at all. I use it on Android, however.

>Autofill is your primary defense against phishing,

The autofill feature is not 100% reliable for various reasons:

(1) some companies use different domains that are legitimate but don't exactly match the url in the password manager. Troy Hunt, the security expert who runs https://haveibeenpwned.com/ got tricked because he knew autofill is often blank because of legit different domains[1]. His sophisticated knowledge and heuristics of how autofill is implemented -- actually worked against him.

(2) autofill doesn't work because of technical bugs in the plugin, HTML elements detection, interaction/incompatibility with new browser versions, etc. It's a common complaint with all password plugins:

https://www.google.com/search?q=1password+autofill+doesn%27t...

https://www.1password.community/discussions/1password/1passw...

https://github.com/bitwarden/clients/issues?q=is%3Aissue%20a...

... so in the meantime while the autofill is broken, people have to manually copy-paste the password!

The real-world experience of flaky and glitchy autofill distorts the mental decision tree.

Instead of, "hey, the password manager didn't autofill my username/password?!? What's going on--OH SHIT--I'm being phished!" ... it becomes "it didn't autofill in the password (again) so I assume the Rube-Goldberg contraption of pw manager browser plugin + browser version is broken again."

Consider the irony of how password managers not being perfectly reliable causes sophisticated technical minds to become susceptible to social engineering.

In other words, password managers inadvertently create a "Normalization of Deviance" : https://en.wikipedia.org/wiki/Normalization_of_deviance

[1] >Thirdly, the thing that should have saved my bacon was the credentials not auto-filling from 1Password, so why didn't I stop there? Because that's not unusual. There are so many services where you've registered on one domain (and that address is stored in 1Password), then you legitimately log on to a different domain. -- from: https://www.troyhunt.com/a-sneaky-phish-just-grabbed-my-mail...

Because you’re one person with a job which isn’t security, and the world is full of legitimate warnings from companies telling you that you must do something by an arbitrary deadline?

They screwed up, but we have thousands of years of evidence that people make mistakes even when they really know better and the best way to prevent that is to remove places where a single person making a mistake causes a disaster.

On that note, how many of the organizations at risk do you think have contributed a single dollar or developer-hour supporting the projects they trust? Maybe that’s where we should start looking for changes.

The attacker did have a great domain name choice, didn’t overuse it to the point where it got on spam block lists, and got them at a moment of distraction, so it worked. It’s really easy to look at something in a training exercise and say “who’d fall for that” without thinking about what happens when you’re not at your best in a calm, focused state.

My main point was simply that the better response isn’t to mock them but to build systems which can’t fail this badly. WebAuthn is great, but you have to go all in if you want to prevent phishing. NPM would also benefit immensely from putting speed bumps and things like code signing requirements in place, but that’s a big usability hit if it’s not carefully implemented.

Yes, and we know that’s a thing which people are trained to do by all of the sites which are sloppy about their login forms or host names so we should assume that attackers can trick people into doing it, even many people who think they are too smart for it. Hubris is quite a boon for attackers.

If you're running this kind of infrastructure online these days, you have every right to require payment somehow. Don't work for free.

Good point. But how should the red flag materialize?

Yeah, I hate these. It's also a very not-ergonomic was to sign in. I wish those companies would redirect those efforts to passkeys.

Username/password typically has the same issue via reset password links.

This is why I haven't bothered with them (the browser extensions; I have used password managers for years and years) and thus why they weren't there to protect against the attack.

I'm glad you've had such good experience with autofill consistently working for you. My experience has been closer to that of the sibling comments: 60/40 so I often just give up and copy-paste. I actually did try jettisoning 1Password for Proton Pass but that was even worse, so I went back

> without any migration strategy or import/export support

Since you're already a 1Password user, I wanted to draw your attention to the "Show debugging tools" in the "Settings > Advanced" section. From that point, you can say "Copy Item JSON" and it will give you the details you would want for rescuing the Passkey. Importing it into something else is its own journey that I can't help with

  {
    "overview": {
      "passkey": {
        "credentialId": "...",
        "rpId": "example.com",
        "userHandle": "..."
      },
    ...
    "details": {
      "passkey": {
        "type": "webauthn",
        "createdAt": 175.......,
        "privateKey": "eyJ...",
        "userHandle": "..."
      }

My understand is the people behind passkeys are working on an import/export solution. Who knows when it'll happen though.

For now, when companies let me have multiple passkeys, that's sufficient for me. I put one on my Apple Keychain and one in 1Password.

> So pick one that does? That's like its top 2 feature

Still doesn’t work 100% of the time, because half of the companies on earth demote their developer time to breaking 1995-level forms. That’s why every popular password manager has a way to fill passwords for other domains, why people learn to use that feature, and why phishers have learned to convince people to use that feature.

WebAuthn prevents phishing. Password managers reduce it. This is the difference between being bulletproof like Superman or a guy in a vest.

Mobile autofill requires you to make other security compromises.

He didn't say it didn't have the autofill feature, he said sometimes it doesn't work. I've experienced this pretty routinely with two different managers.

The email says accounts will start locking Sept 10th and it was sent Sept 8th - so a 48 hour urgency window or an account would be locked is urgency IMO

> The solution is to not use email.

and use what? instant message? few things lack legitimacy more than an instant message asking you to do something.

Links in email are much more of a problem than email itself. So tempting to click. It's right there, you don't have to dig through bookmarks, you don't have to remember anything, just click. A link is seductive.

the actual solution is to avoid dependencies whenever possible, so that you can review them when they change. You depend on them. You ARE reviewing them, right? Fewer things to depend on is better than more, and NPM is very much an ecosystem where one is encouraged to depend on others as much as possible.

> The problem is email as it’s used currently. The solution is to not use email.

No. The problem is unsigned package repositories.

The solution is to tie a package to an identity using a certificate. Quickest way I can think off would be requiring packages to be linked to a domain so that the repository can always check incoming changes to packages using the incoming signature against the domain certificate.

https://mailtrap.io/contact-details/

let's see the header of interest:

     Received: from npmjs.help by smtp.mailtrap.live

How did simply opening this email in something like Gmail or a desktop client result in it being able to compromise NPM packages under your control?

I'm just curious - and as a word of warning to others so we can learn. I may be missing some details, I've read most of the comments on the page.

We should be immediately suspicious when we get any solicitation to "renew" something "expired" in a security domain. Swapping un-compromised secrets is essentially always more risky than leaving them be.

Regardless of whether the real NPM had done this in the past, decades of dumb password expiration policies have trained us that requests like this are to be expected rather than suspected.

If legitimate companies didn't do this, then the email would be suspicious.

Next comment:

> Those are swap contract addresses, not attacker addresses. E.g. 0x66a9893cC07D91D95644AEDD05D03f95e1dBA8Af the Uniswap v4 universal router addr.

> Every indication so far is that the attacker stole $0 from all of this. Which is a best-case outcome.

There is NO reliable indicators, because every single one of these "Legit requests don't ..." recommendations has been done by a local bank trying to get their customers to do something.

My local credit union sent me a "please change your password" email from a completely unassociated email address with a link to the change password portal. I emailed them saying "Hey it looks like someone is phishing" and they said, "nope, we really, intentionally, did this"

Companies intentionally withhold warning emails as late as possible to cause more people to incur late fees. So everyone is used to "shit, gotta do this now or get screwed"

You can't hope to have good security when everyone's money is controlled by organizations that actively train people to have bad OPSEC or risk missing rent.

Every day brings me another reason to ask the question: "Why the hell did they throw away the idea of mutual TLS?". They then went onto invent mobile OTP, HOTP, TOTP, FIDO-U2F and finally came a full cycle by reinventing the same concept, but in a more complex incarnation - Passkeys.

TOTP isnt designed to be against phishing. Its against weak, leaked or cracked passwords.

No. It only proves that TOTP, as implemented by mobile apps, is useless against phishing.

The extension from https://authenticator.cc, with smart domain match enabled, would have caught this by showing all other TOTP codes besides the one intended by NPM.

On a Mac, Keychain would also have caught this by not autofilling: https://support.apple.com/en-ph/guide/passwords/mchl873a6e72...

Yes. This attack would not have worked if FIDO2 (or the software emulation Passkey) had been used.

Damn, that's an impressively well-done attack. Curious, do you use a password manager? If so, did it not autofilling feel like a red flag to you?

I've always wondered if I ever get phished if I'll notice bc of that or if I'll just go "ugh 1password isn't working, guess i'll paste my password in manually" and end up pwned

> That said, it remains a perpetual struggle to get people to understand the difference between being connected to the legitimate operator of satan.example

That's because the browser implementers gave up on trying to solve the identity problem. It's too difficult they said, we'd rather push other things.

Google implemented certificate pinning in Chrome for themselves and a few friends, said fuck everyone else, and declared the problem solved. Who cares about everyone else when your own properties are protected and you control the browser?

Meanwhile the average user has no idea what a certificate does, whether it does or doesn't prove identity.

No wonder they removed the lock icon from the browser.

> I'd probably go looking for a new password manager if it fails to do one of the basic features they exist for, copy-pasting passwords defeats a lot of the purpose :)

This isn’t the fault of the password managers themselves, but devs not putting the right metadata on their login forms, or havo the password field show only after putting in the email address, causing the password input to fail to be filled, etc.