Screenshot here: https://imgur.com/a/q8s235k
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.
For example, GitHub asks for 2FA when I change certain repo settings (or when deleting a repo etc.) even when I'm logged in. Maybe NPM needs to do the same?
FWIW npmjs does support FIDO2 including hard tokens like Yubikey.
They do not force re-auth when issuing an access token with publish rights, which is probably how the attackers compromised the packages. iirc GitHub does force re-auth when you request an access token.
I'm surprised by this. Yeah, GitHub definitely forces you to re-auth when accessing certain settings.
Received: from npmjs.help by smtp.mailtrap.live0x10ed43c718714eb63d5aa57b78b54704e256024e
0x13f4ea83d0bd40e75c8222255bc855a974568dd4
0x1111111254eeb25477b68fb85ed929f73a960582
0xd9e1ce17f2641f24ae83637ab66a2cca9c378b9f
Source: https://github.com/chalk/chalk/issues/656#issuecomment-32670...
> 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.
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.
I used the word "often" rather than "always" for this reason.
Completely agree. The only reliable way is to never use an email/SMS link to login, ever.
that message feels like it could work as a first-time as well
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.
dkim=pass header.d=smtp.mailtrap.live header.s=rwmt1 header.b=Wrv0sR0rUrgency is poison.
Please, please put a foot in the door whenever you see anyone trying to push this kind of sh*t on your users. Make one month's advance notice the golden standard.
I see this pattern in scam mail (including physical) all the time: stamp an unreasonably short notice and expect the mark to panic. This scam works - and this is why legit companies that try this "in good faith" should be shamed for doing it.
Actual alerts: just notify. Take immediate, preventive, but non-destructive action, and help the user figure out how to right it - on their own terms.
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.
If you're publishing your software: you can't "not" depend on some essential service like source hosting or library index.
> You ARE reviewing them, right?
Werkzeug is 20kloc and is considered "bare bones" of Python's server-side HTTP. If you're going to write a complex Python web app using raw WSGI, you're just going to repeat their every mistake.
While at it: review Python itself, GCC, glibc, maybe Linux, your CPU? Society depends on trust.
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.
1. It's an extra step: before you pwn the package, you need to pwn a domain.
2. When a domain is pwned, the packages it signs can be revoked with a single command.
You'd need some kind of offline verification method as well for these widely used infrastructure libraries.
Nothing "really works" against a sophisticated hacker :-/ Doesn't mean that "defense in depth" does not apply.
> You'd need some kind of offline verification method as well for these widely used infrastructure libraries.
I don't understand why this is an issue, or even what it means: uploading a new package to the repository requires the contributor to be online anyway. The new/updated/replacement package will have to be signed. The signature must be verified by the upload script/handler. The verification can be done using the X509 certificate issued for the domain of the contributor.
1. If the contributor cannot afford the few dollars a year for a domain, they are extremely vulnerable to the supply chain attack anyway (by selling the maintenance of the package to a bad actor), and you shouldn't trust them anyway.
2. If the contributor's domain gets compromised you only have to revoke that specific certificate, and all packages signed with that certificate, in the past or in the future, would not be installable.
As I have repeatedly said in the past, NPM (and the JS tools development community in general) had no adults in the room during the design phase. Everything about JS stacks feels like it was designed by children who had never programmed in anything else before.
It's a total clown show.
They didn't need me; plenty of repositories doing signed packages existed well before npm was created.
Which is why I likened them to a bunch of kids - they didn't look around at how the existing repos were designed, they just did the first thing that popped into their head.
It should be a PGP or SSH key, absolutely not an X509 certificate (unless you allow self signed).
Personal identity keys should be fully autonomous and not contingent on the formal recognition of any external authority.
Identity on the Internet is a lie. Nobody knows you're a dog.
The solution is to make security easy and accessible, so that the user can't be confused into doing the insecure thing.
What do you think HTTPS is?
I really, really dislike the idea of using TLS certificates as we know them for this purpose, because the certificate authority system is too centralized, hierarchical, and bureaucratic, tightly coupled to the DNS.
That system is great for the centralized, hierarchical, bureaucratic enterprises who designed it in the 90s, but would be a pain in the ass for a solo developer, especially with the upcoming change to 45 day lifetimes.
I am with PGP but more wary of self-signed certs, though even self-signed certs allow mass revocation of packages when an author's cert is compromised.
Don't do security things when you're not fully awake, too. Lesson learned.
The email was a "2FA update" email telling me it's been 12 months since I updated 2FA. That should have been a red flag but I've seen similarly dumb things coming from well-intentioned sites before. Since npm has historically been in contact about new security enhancements, this didn't smell particularly unbelievable to my nose.
The email went to the npm-specific inbox, which is another way I can verify them. That address can be queried publicly but I don't generally count on spammers to find that one but instead look at git addresses etc
The domain name was `npmjs dot help` which obviously should have caught my eye, and would have if I was a bit more awake.
The actual in-email link matched what I'd expect on npm's actual site, too.
I'm still trying to work out exactly how they got access. They didn't technically get a real 2FA code from the actual, I don't believe.
Will post a post-mortem when everything is said and done.
Authentications are separated and if some signature must be placed or money to be sent, you must use other access code and the app shows the intention of what are you authorizing. If it is money being sent, you see where and how much you want to sent before you approve this request on the app.
But the app is all tied to digital identity from the id card in the first place - to set up these strong authentication guarantees in the first place you use your ID card. Some time ago we had to use computer with smartcard reader to set it up, nowdays I dunno whether it is NFC or something, but the mobile phone can read the ID card.
It's nothing short of amazing that nobody worked on this. It's not as if there isn't a need. Everyone with high security requirements (defense, banks etc.) already do this, but this clumsy plugins and (semi-)proprietary software. Instead we get the nth iteration of settings redesigns.
That's exactly what I mean! Who would use it if the UI/UX is terrible? Many Gemini (protocol) browsers like Lagrange have such pleasant UIs for it, though somewhat minimal. With sufficient push, you could have used mutual TLS from even hardware tokens.
Once heard of a user putting in a helpdesk ticket asking why they had to pay for the TOTP app. Then I realize their TOTP seed is probably out in the open now.
I’m sure we can imagine how else this could go badly…
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...
It's a good thing the WebPKI cartel mostly did away with EV certs.... these days any old cert where only the SAN matches the domain and your browser gives a warm fuzzy "you're secure!"
By contrast, OV certs, which were originally supposed a very similar level of assurance, were did away with by CAs themselves, by cost-optimizing the verification requirements into virtual nonexistence.
That said, it remains a perpetual struggle to get people to understand the difference between being connected to the legitimate operator of satan.example (something an Internet-wide system mostly can guarantee) and it being wise to transact there (something extensive experience shows it can’t and shouldn’t try to). And if you’re a domain owner, your domain is your identity; pick one and stick to it. Stackoverflow.blog is stupid, don’t be like stackoverflow.blog.
[1] https://www.troyhunt.com/extended-validation-certificates-ar...
[2] https://arstechnica.com/information-technology/2017/12/nope-...
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.
They even gave me a new TOTP code to install (lol) and it worked. Showed up in authy fine. Whoever made this put a ton of effort into it.
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
The `.help` should have been the biggest red flag, followed by the 48-hours request timeline. I wasn't thinking about things like I normally would this morning and just wanted to get things done today. Been a particularly stressful week, not that it's any excuse.
If you maintain popular open source packages for the love of God get yourself a couple of security keys.
That's how they get you.
Can't really tell you what not to do, but if you're not already using a password manager so you can easily avoid phishing scams, I really recommend you to look into starting doing so.
In the case of this attack, if you had a password manager and ended up on a domain that looks like the real one, but isn't, you'd notice something is amiss when your password manager cannot find any existing passwords for the current website, and then you'd take a really close look at the domain to confirm before moving forward.
That being said, if you’re making login pages: please, for the love of god, test them with multiple password managers. Oh, and make sure they also work correctly with the browser’s autotranslation. Don’t rely on the label to make form submission decisions ... please.
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 :)
> That being said, if you’re making login pages
I think we're doomed on this front already. My previous bank still (in 2025!) only allows 6 numbers as the online portal login password, no letters or special characters allowed, and you cannot paste in the field so no password manager works with their login fields, the future is great :)
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.
What is your mythical "good password manager"?
In those cases, I carefully review the new domain, make sure it belongs to the right owner, then add it to the list of domains to accept. Now the account list properly show up in the future too, until they again change it. But it gives me a moment to pause and reflect before just moving past it.
I cannot remember any times in the last years where 1Password was 100% unable to fill out the username/password for a website unless the website itself prevented pasting passwords (like my old bank).
But even if it fills the wrong fields, it still provides safety as you wouldn't even see the accounts in the list if you're on the wrong domain, so that's your first warning sign.
What does worry me, though, is exactly what you pointed out about NPM’s response time. Given how central NPM packages are to the entire JavaScript ecosystem, you’d expect their security processes to be lightning fast. Every hour of delay can mean thousands (or millions) of downloads happening with potentially compromised code. And as you said, that just increases the incentive for attackers to target maintainers in the first place.
(Microsoft owns GitHub, which owns NPM.)
Most people who get phished aren’t using password managers, or they would notice that the autofill doesn’t work because the domain is wrong.
Additionally, TOTP 2FA (numeric codes) are phishable; stop using them when U2F/WebAuthn/passkeys are available.
I have never been phished because I follow best practices. Most people don’t.
In 15 years of maintaining OSS, I've never been pwned, phished, or anything of the sort.
Thank you for your input :)
Well, until now.
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.
But instead, we're left with this mess where ordinary developers are forced to deal with the consequences of getting phished.
Also, Yubikeys work on phones just fine, via both NFC and USB.
Just set up a new passkey on the mobile device.
Password managers can’t help you if you don’t use them properly.
Spotify steals (and presumably uploads) your clipboard, as well as other apps. Autofill is your primary defense against phishing, as you (and hopefully some others) learned this week.
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...
The number of cases in this thread, about a malware attack basically because of 1Password, where people mention their bad experience with 1Password is really stretching the "no such thing as bad publicity" theory
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.
One side note: most systems make it hard to completely rely on WebAuthn. As long as other options are available, you are likely vulnerable to an attack. It’s often easier than it should be to get a vendor to reset MFA, even for security companies.
It was a generic Phish email you were in every single Corp 101 security course
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.
Ive literally never for a support email or any email from a .help domain.
I'm not mocking them, just trying to understand how so many red flags slipped past.
Domain name No auto-fill Unannounced MFA resets Etc...
My point is that nothing could have saved this person except extreme security measures. There's literally no conclusion here besides:
1. Lock everything down so extremely that it's extremely inconvenient to prevent mistakes 99% of people don't make. (How many npm packages vs the total have been hijacked, less than 1%)
2. This person was always going to be a victim eventually... And that's a hard pill to swallow. For me and the maintainer. Being in network security it's my actual nightmare scenario.
The only lesson to be learned is you need extreme security measures for even the most experienced of internet users. This wasn't your grandma clicking a link, it's a guy who's been around for decades in the online / coding world.
It also makes me suspicious but that's a road I'd rather keep myself
A password manager can’t manage passwords if you don’t configure it and use it.
You forgot to mention that you are both highly skilled and practiced at phishing yourself... don't you think that helps too?
You can run the following to check if you have the malware in your dependency tree:
`rg -u --max-columns=80 _0x112fa8`
Requires ripgrep:
`brew install rg`
https://github.com/chalk/chalk/issues/656#issuecomment-32668...
For security checks, the first 2 out of 3 is just fine.
-uu searches through ignored and hidden files (eg dotfiles)
-uuu searches through ignored, hidden, and binary files (ie everything)
The command rg -u --max-columns=80 _0x112fa8 uses the rg (ripgrep) utility. Here's a breakdown of what each part does:
rg: This is the command for ripgrep, a fast, recursive search tool that respects .gitignore and searches files for a given pattern.
1
-u: This flag tells ripgrep to search files that have been ignored by default (e.g., those listed in .gitignore).
1
--max-columns=80: This option sets the maximum width of a line to 80 characters. If a line exceeds this width, ripgrep will replace it with a message indicating that a matching line was removed, rather than displaying the full, long line.
1
_0x112fa8: This is the pattern that rg will search for within the files. It appears to be a hexadecimal string.npm cache clean --force pnpm cache delete
That said, I think rg is pretty well known to linux daily-drivers and they just wanted to share something quickly for powerusers who want to check their workspaces quickly. Probably better to just instruct n00bs to use grep than install a whole cli tool for searching
Come to think of it, I wonder if a 2-phase attack could be planned by an attacker in the future: Inject malware into a package, flood guidance with instructions to install another popular tool that you also recently compromised... lol
> Unfortunately, in the world of software there are bad actors that bundle malware with their apps. Even so, Homebrew Cask has long decided it will not be an active gatekeeper (macOS already has one) and users are expected to know about the software they are installing. This means we will not always remove casks that link to these apps, in part because there is no clear line between useful app, potentially unwanted program, and the different shades of malware—what is useful to one user may be seen as malicious by another.
---
So there might be pull requests, but Brew's official stance is that they do not actively moderate casks for malware. I guess there's something built into the MacOS packaging step that help mitigate the risk, but I don't know much about it outside playing w/ app development in XCode.
Like ... npm?
Everybody knows npm is a gaping security issue waiting to happen. Repeatedly.
It’s convenient, so it’s popular.
Many people also don’t vendor their own dependencies, which would slow down the spread at the price of not being instantly up to date.
npm sold it really hard that you could rely on them and not have to vendor dependencies yourself. If I suggested that a decade ago in Seattle, I would have gotten booed out of the room.
Yet here we are. And this is going to get massively worse, not better.
I mean, I believe you, but the person you are replying to obviously believes that they are similar. Could you explain the significant differences?
> Unfortunately, in the world of software there are bad actors that bundle malware with their apps. Even so, Homebrew Cask has long decided it will not be an active gatekeeper (macOS already has one) and users are expected to know about the software they are installing. This means we will not always remove casks that link to these apps, in part because there is no clear line between useful app, potentially unwanted program, and the different shades of malware—what is useful to one user may be seen as malicious by another.
It takes like 2 years to get up to date packages. This isn't NPM.
https://www.redhat.com/en/blog/understanding-red-hats-respon...
https://lists.debian.org/debian-security-announce/2024/msg00...
(I get that the same can be said for said for npm and the packages in question, but I don’t really see how the context of the thread matters in this case).
If you have crypto wallets on the potentially compromised machine, or intend to transfer crypto via some web client, proceed with caution.
https://gist.github.com/edgarpavlovsky/695b896445c19b6f66f14...
`Get-ChildItem -Recurse | Select-String -Pattern '_0x112fa8' | ForEach-Object { $_.Line.Substring(0, [Math]::Min(80, $_.Line.Length)) }`
Breakdown of the Command:
- Get-ChildItem -Recurse: This command retrieves all files in the current directory and its subdirectories.
- Select-String -Pattern '_0x112fa8': This searches for the specified pattern in the files.
- ForEach-Object { ... }: This processes each match found.
- Substring(0, [Math]::Min(80, $_.Line.Length)): This limits the output to a maximum of 80 characters per line.
---
Hopefully this should work for Windows devs out there. If not, reply and I'll try to modify it.
If there's any ideas on what I should be doing, I'm all ears.
EDIT: I've heard back, they said they're aware and are on it, but no further details.
It took them quite a long time to do so.
Github is SOC2 compliant, but that of course means nothing really.
And because it could happen to anyone that we should be doing a better job using AI models for defense. If ordinary people reading a link target URL can see it as suspicious, a model probably can too. We should be plumbing all our emails through privacy-preserving models to detect things like this. The old family of vulnerability scanners isn't working.
Great of you to own up to it.
I actually got hit by something that sounds very similar back in July. I was saved by my DNS settings where "npNjs dot com" wound up on a blocklist. I might be paranoid, but it felt targeted and was of a higher level of believability than I'd seen before.
I also more recently received another email asking for an academic interview about "understanding why popular packages wouldn't have been published in a while" that felt like elicitation or an attempt to get publishing access.
Sadly both of the original emails are now deleted so I don't have the exact details anymore, but stay safe out there everyone.
Please take care and see this as things that happen and not your own personal failure.
But google comes with its own privacy nightmares.
https://socket.dev/blog/npm-author-qix-compromised-in-major-...
While it sucks that this happened, the good thing is that the ecosystem mobilized quickly. I think these sorts of incidents really show why package scanning is essential for securing open source package repositories.
Either way, the parent post is clearly ambulance chasing rather than having a productive conversation, which should really be about whether or not automatically downloading and executing huge hierarchal trees of code is absolutely fucking crazy, rather than a blatant attempt to make money off an ongoing problem without actually solving anything.
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.
So just because a lock isn't 100% effective at keeping out criminals we shouldn't lock our doors?
That’s like lock companies parading around when their neighbour is murdered during a burglary but they weren’t because they bought a Foobar(tm) lock.
It seems strange to attack a service like this right after it actively helped keep people safe from malware. I'm sure its not perfect, but it sounds like they deserve to take a victory lap.
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?
In this incident, we detected the packages quickly, reported them, and they were taken down shortly after. Given how high profile the attack was we also published an analysis soon after, as did others in the ecosystem.
We try to be transparent with how Socket work. We've published the details of our systems in several papers, and I've also given a few talks on how our malware scanner works at various conferences:
Very insightful.
You can't catch everything with normal static analysis either. LLM just produces some additional signal in this case, false negatives can be tolerated.
There are cases an LLM may be able to catch that their static analysis can't currently catch. Should they just completely ignore those scenarios, thereby doing the worst thing by their customers, just to stay purist?
What is the worst case scenario that you're envisioning from an LLM hallucinating in this use case? To me the worst case is that it might incorrectly flag a package as malicious, which given they do a human review anyway isn't the end of the world. On the flip side, you've got LLM catching cases not yet recognised by static analysis, that can then be accounted for in the future.
If they were just using an LLM, I might share similar concerns, but they're not.
when static analysis does it, it's called a "misclassification"
“Chat, I have reading comprehension problems. How do I fix it?”
Does the AI detect the obfuscation?
Thanks for the links in your other comment, I'll take a look!
> The author appears to have deleted most of the compromised package before losing access to his account. At the time of writing, the package simple-swizzle is still compromised.
Is this quote from TFA incorrect, since npm hasn’t yanked anything yet?
npm does appear to have yanked a few, slowly, but I still don't have any insight as to what they're doing exactly.
phishing is too easy. so easy that I don't think the completely unchecked growth of ecosystems like NPM can continue. metastasis is not healthy. there are too many maintainers writing too many packages that too many others rely on.
want to stress everyone it can happen to. no one has perfect opsec or tradecraft as a 1 man show. its simply not possible. only luck gets one through and that often enough runs out.
Does anyone know how this attack works? Is it a CSRF against npmjs.com?
It wasn't a single-click attack, sorry for the confusion. I logged into their fake site with a TOTP code.
Sorry for what you're going through.
You login with your credentials, the attacker logins to the real site.
You get an SMS with a one time code from the real site and input it to the fake site.
The attacker takes the code andc finishes the login to the real site.
So if the hacker did an npm publish from local it would show up.
Also, junon.support++ – big thanks for being clear about all this.
If you change your key you can't use it for like 12 hours or something?
They can't pwn what they can't find online.
With nodejs packages, I can open up node_modules and read the code. But packages get a chance to run arbitrary code on your computer after installation. By the time you can read the source code, it may be too late.
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.
Good luck and well done again on the response!
Have the TOTP in the same/another password manager (after considering the tradeoffs) and that can also not be entered unless the domain is right :)
You only need read the whole thread however to see reasons why this would sometimes not be enough: sometimes the password manager does not auto-fill, so the user can think it's one of those cases, or they're on mobile and they don't have the extension there, or...
As a matter of fact, he does use one, that didn't save him, see: https://news.ycombinator.com/item?id=45175125
So pick one that does? That's like its top 2 feature
> he does use one
He doesn't since he has no autofill installed, so loses the key security+ convenience benefit of automatch
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.
As a developer I also love their ssh and gpg integrations, very handy.
I do get it for free from work, but if I had to choose one myself I'd have to pay for I'd probably still pick 1Passwrod.
I wanted to highlight that "getting it for free from work" isn't a sweetheart deal offered just to OP, but a feature of 1Password for Teams, meaning all employees of a business that uses 1Password automatically have a Family license for use at home https://support.1password.com/link-family/
And, for clarity, it's merely a financial relationship: the business cannot manage your Family account, cannot see its contents, and if you have a separation event you can retain the Family account forever in a read only capacity or you can take over the payment (or, heh, I presume move to another employer that also uses 1Password) and nothing changes for your home passwords
That's why WebAuthn doesn't allow that as a core protocol feature, preventing both this attack and shifting the cost of unnecessary origin changes back to the company hosting the site. Attacking this guy for making a mistake in a moment of distraction is like prosecuting a soldier who was looking the other way when someone snuck past: wise leaders know that human error happens and structure the system to be robust against a single mistake.
> I was mobile, the autofill stuff isn't installed
Passkeys seem like the best solution here where you physically can not fall for a phishing attack.
This is how Troy Hunt got phished. He was already very tired after a long flight, but his internal alarm bells didn't ring loud enough, when the password manager didn't fill in the credentials. He was already used to autofill not always working.
I dunno, it mostly seems to not work when companies change their field names/IDs, or just 3rd party authentication, then you need to manually add domains. Otherwise my password manager (1Password) works everywhere where I have an account, except my previous bank which was stuck in the 90s and disallowed pasting the passwords. If you find that your password manager doesn't work with most websites (since it's "extremely common") you might want to look into a different one, even Firefox+Linux combo works extremely well with 1Password. Not affiliated, just a happy years+ user.
> Passkeys seem like the best solution here where you physically can not fall for a phishing attack.
Yeah, I've looked into Passkeys but without any migration strategy or import/export support (WIP last time I looked into it), it's not really an alternative just yet, at least for me personally. I have to be 100% sure I can move things when the time ultimately comes for that.
> 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": "..."
}
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.
Login using one off email links (instead of username + password) is increasingly common which means its the only option.
Not promoting the pattern, I also find it worrying the majority of internet users have no basic understanding of authentication and the risk for their digital identity.
If you use username instead of email address attackers have to guess that too.
One quite serious problem I see quite often is using email plus password for login, and notifying on failed login that the email is not in the system, letting attackers validate which emails are logins.
And this is exactly the kind of phishing attack that is most effective, as this particular incident shows. So I'd say it's actually a worse phishing vector than magic links.
1. You just requested it, I'm not saying to never click link on transactional emails you requested. You still need to click on those verify email links
2. It replaces entering your password, so you're not entering your password on a link from an email, which is the very wrong thing.
I’m extremely security conscious and that phishing email could have easily gotten me. All it takes is one slip up. Tired, stressed, distracted. Bokm, compromised
Do we just run:
npm list -g #for global installs
npm list #for local installs
And check if any packages appear that are on the above list?
Thanks!
Folks from multi-billion dollar companies with multimillion dollar packages should learn a few things from this response.
thanks for your efforts!
More info:
- https://github.com/chalk/chalk/issues/656
- https://github.com/debug-js/debug/issues/1005#issuecomment-3...
Affected packages (at least the ones I know of):
- [email protected]
- [email protected] (appears to have been yanked as of 8 Sep 18:09 CEST)
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
- [email protected]
It looks and feels a bit like a targeted attack.
Will try to keep this comment updated as long as I can before the edit expires.
---
Chalk has been published over. The others remain compromised (8 Sep 17:50 CEST).
NPM has yet to get back to me. My NPM account is entirely unreachable; forgot password system does not work. I have no recourse right now but to wait.
Email came from support at npmjs dot help.
Looked legitimate at first glance. Not making excuses, just had a long week and a panicky morning and was just trying to knock something off my list of to-dos. Made the mistake of clicking the link instead of going directly to the site like I normally would (since I was mobile).
Just NPM is affected. Updates to be posted to the `/debug-js` link above.
Again, I'm so sorry.