5 ms·

This is critical infrastructure, and it gets compromised way too often. There are so many horror stories of NPM (and similar) packages getting filled with malwa

by elric 1y ago

This is critical infrastructure, and it gets compromised way too often. There are so many horror stories of NPM (and similar) packages getting filled with malware. You can't rely on people not falling for phishing 100% of the time. People who publish software packages tend to be at least somewhat technical people. Can package publishing platforms PLEASE start SIGNING emails. Publish GPG keys (or whatever, I don't care about the technical implementation) and sign every god damned email you send to people who publish stuff on your platform. Educate the publishers on this. Get them to distrust any unsigned email, no matter how convincing it looks. And while we're at it, it's clear that the current 2FA approach isn't good enough. I don't know how to improve on it, but it's clear that the actions in this example were suspicious: user logs in, changes 2FA settings, immediately adds a new API token, which immediately gets used to publish packages. Maybe there should be a 24 hour period where nothing can be published after changing any form of credentials. Accompanied by a bunch of signed notification emails. Of course that's all moot if the attacker also changes the email address.

progx 1y ago
TRUE! A simple self defined word in an email and you will see, if the mail is fake or not.
zokier 1y ago
Spf/dkim already authenticates the sender. But it doesn't help if the user doesn't check who the email is from. But in that case gpg would not help that much either.
- elric 1y ago
  SPF & DKIM are all but worthless in practice, because so many companies send emails from garbage domains, or add large scale marketing platforms (like mailchimp) to their SPF records. Like Citroen sends software update notifications for their cars from mmy-customerportal.com. That URL looks and sounds like a phisher's paradise. But somehow, it's legit. How can we expect any user to make the right decision when we push this kind of garbage in their face?
  - zokier 1y ago
    The same problem applies to gpg. If companies can not manage to use consistent from addresses then do you really expect them to do any better with gpg key management? "All legitimate npm emails are signed with GPG key X" and "All legitimate npm emails come from @npmjs.com" are equally strong statements.
  - JimDabell 1y ago
    The problem is there is no continuity. An email from an organisation that has emailed you a hundred times before looks the same as an email from somebody who has never emailed you before. Your inbox is a collection of legitimate email floating in a vast ocean of email of dubious provenance. I think there’s a fairly straightforward way of fixing this: contact requests for email. The first email anybody sends you has an attachment that requests a token. Mail clients sort these into a “friend request” queue. When the request is accepted, the sender gets the token, and the mail gets delivered to the inbox. From that point on, the sender uses the token. Emails that use tokens can skip all the spam filters because they are known to be sent by authorised senders. This has the effect of separating inbound email into two collections: the inbox, containing trustworthy email where you explicitly granted authorisation to the sender; and the contact request queue. If a phisher sends you email, then it will end up in the new request queue, not your inbox. That should be a big glaring warning that it’s not a normal email from somebody you know. You would have to accept their contact request in order to even read the phishing email. I went into more detail about the benefits of this system and how it can be implemented in this comment: https://news.ycombinator.com/item?id=44969726 https://news.ycombinator.com/item?id=44969726
    - zokier 1y ago
      You don't need complex token arrangements for this. You can just filter emails based on their from addresses.
      - JimDabell 1y ago
        Unfortunately, it’s not that simple. It’s extremely common for the same organisation to send emails from different addresses, different domains, and different servers, for many different reasons.
- vel0city 1y ago
  There's little reason to think these emails didn't pass SPF/DKIM. They probably "legitimately" own their npmjs[.]help domain and whatever server they used to send the emails is probably approved by them to send for that domain.
  - zokier 1y ago
    But in the same vein the phishing email can easily be gpg signed too. The problem is to check if the gpg key used to sign the email is legitimate, but that is exactly the same problem as checking if the from address is legitimate.
  - mdaniel 1y ago
    No guessing required, DKIM was intact, but it was also sent via a transactional email service, so that's why https://gist.github.com/Qix-/c1f0d4f0d359dffaeec48dbfa1d40ee9#file-qix-support-at-npmjs-dot-help-phishing-attack-email-L18 https://gist.github.com/Qix-/c1f0d4f0d359dffaeec48dbfa1d40ee...
SoftTalker 1y ago
I think you just have to distrust email (or any other "pushed" messages), period. Just don't ever click on a link in an email or a message. Go to the site from your own previously bookmarked shortcut, or type in the URL. I got a fraud alert email from my credit card the other day. It included links to view and confirm/deny the suspicious charge. It all looked OK, the email included my name and the last digits of my account number. I logged in to the website instead. When I called to follow up I used the phone number printed on my card. Turns out it was a legit email, but you can't really know. Most people don't understand public key signing well enough to rely on them only trusting signed emails. Also, if you're sending emails like this to your users, stop including links. Instead, give them instructions on what to do on your website or app.
- sroussey 1y ago
  I get Coinbase SMS all the time with a code not to share. But also… “call this phone number if you did not request the code”.
  - sgc 1y ago
    This does nothing for the case of receiving a fake coinbase sms with a fake contact phone number. I have had people attempt fraud in my work with live calls as follow up to emails and texts. I only caught it because it didn't pass the smell test so I did quite a bit of research. Somebody else got caught in the exact same scam and I had to extricate them from it. They didn't believe me at first and I had to hit them over the head a bit with the truth before it sank in.
    - Moru 1y ago
      Yes, this is a classic scam vector. We really should stop training users to click links / call phonenumbers in sms and emails.
- Moru 1y ago
  There is companies that send email with invoices where you have to click a link. There is no way of logging in on their site to get to the invoice. It is an easy fix for them (we use the same invoicing company as they do so I know). All they need to do is click "Allow sending bills directly to customers bank". Every month I get the email, I use the included chat function on the webpage to ask when they will enable this and it's always not possible. Mabe some day. I wish we could stop training people to click links in random messages just because we want to be able to track their movements online.
egorfine 1y ago
> You can't rely on people not falling for phishing 100% of the time 1. I genuinely don't understand why. 2. If it is true that people are the failing factor, then nothing is going to help. Hardware keys? No problem, a human will use the hardware key to sign a malicious action.
- MitPitt 1y ago
  Removing humans will help
  - egorfine 1y ago
    I sense a startup opportunity here
- elric 1y ago
  > 1. I genuinely don't understand why. It's a war of attrition. You can keep bombarding developers with new and clever ways of trying to obtain their credentials or get them to click on some link while signed in. It only has to succeed once. No one is 100% vigilant all the time. If you think you're the exception, you're probably deluding yourself. There's something broken in a system where one moment of inattention by one person can result in oodles of people ending up with compromised software, and I don't think it's the person that's broken.
  - egorfine 1y ago
    Then see #2: there is no way to prevent humans from actually performing detrimental actions, hardware keys or not.
    - vel0city 1y ago
      This specific attack (and many others like it) would have absoultey been foiled by U2F or passkeys. These authors would have been incapable of giving the adversary any useful credential to impersonate them by the very nature of how these systems work.
nikcub 1y ago
* passkeys * signed packages enforce it for the top x thousand most popular packages to start some basic hygiene about detecting unique new user login sessions would help as well
- SAI_Peregrinus 1y ago
  Requiring signed packages isn't enough, you have to enforce that signing can only be done with the approval of a trusted person. People will inevitably set up their CI system to sign packages, no human intervention needed. If they're smart & the CI system is capable of it they'll set it up to only build when a tag signed by someone approved to make releases is pushed, but far too often they'll just build if a tag is pushed without enforcing signature verification or even checking which contributors can make releases. Someone with access to an approved contributor's GitHub account can very often trigger the CI system to make a signed release, even without access to that contributor's commit signing key.
evantbyrne 1y ago
The email was sent from the 'npmjs dot help' domain. I'm not saying you're wrong, but also basic due diligence would have prevented this. If not by email, the maintainer may have been able to be compromised over text or some other medium. And today maintainers of larger projects can avoid these problems by not importing and auto-updating a bunch of tiny packages that look like they could have been lifted from stack overflow
- chrisweekly 1y ago
  Re: "npmjs dot help", way too many companies use random domains -- effectively training their users to fall for phishing attacks.
  - InsideOutSanta 1y ago
    This exactly. It's actually wild how much valid emails can look like phishing emails, and how confusing it is that companies use different domains for critical things. One example that always annoys me is that the website listing all of Proton's apps isn't at an address you'd expect, like apps.proton.me. It's at protonapps.com. Just... why? Why would you train your users to download apps from domains other than your primary one? It also annoys me when people see this happening and point out how the person who fell for the attack missed some obvious detail they would have noticed. That's completely irrelevant, because everyone is stupid sometimes. Everyone can be stressed out and make bad decisions. It's always a good idea to make it harder to make bad decisions.
    - OkayPhysicist 1y ago
      I can answer why this is at the company I work at right now: It's a PITA to coordinate between teams, and my team doesn't control the main domain. If I wanted my team's application to run on the parent domain, I would have to negotiate with the crayon eaters in IT to make a subdomain, point it at whatever server, and then if I want any other changes to be made, I'd have to schedule a followup meeting, which will generate more meetings, etc. If I want to make any changes to the mycompany.othertld domain, I can just do it, with no approval from anyone.
ignoramous 1y ago
> Can package publishing platforms PLEASE start SIGNING emails I am skeptical this solves phising & not add to more woes (would you blindly click on links if the email was signed?), but if we are going to suggest public key cryptography, then: NPM could let package publishers choose if only signed packages must be released and consumers decide if they will only depend on signed packages. I guess, for attackers, that moves the target from compromising a publisher account to getting hold of the keys, but that's going to be impossible... as private keys never leave the SSM/HSM, right? > Get them to distrust any unsigned email, no matter how convincing it looks. For shops of any important consequence, email security is table stakes, at this point: https://www.lse.ac.uk/research/research-for-the-world/society/cybercrime-business-email-fraud https://www.lse.ac.uk/research/research-for-the-world/societ...
- elric 1y ago
  I don't think signed email would solve phishing in general. But for a service by-and-for programmers, I think it at least stands a chance. Signing the packages seems like low hanging fruit as well, if that isn't already being done. But I'm skeptical that those keys are as safe as they should be; IIRC someone recently abused a big in a Github pipeline to execute arbitrary code and managed to publish packages in that way. Which seems like an insane vulnerability class to me, and probably an inevitable consequence of centralising so many things on github.
parliament32 1y ago
> it's clear that the current 2FA approach isn't good enough. I don't know how to improve on it USE PASSKEYS. Passkeys are phishing-resistant MFA, which has been a US govt directive for agencies and suppliers for three years now[1]. There is no excuse for infrastructure as critical as NPM to still be allowing TOTP for MFA. [1]https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-0...
- smw 1y ago
  This is the way! Passkeys or FIDO2 (yubikey) should be required for supply chain critical missions like this.
- FreakLegion 1y ago
  Yes, use FIDO, you'll be better off, but no, passkeys aren't immune to account takeover. E.g. not only does GitHub support OAuth apps, it supports device code flow, and thus: https://www.praetorian.com/blog/introducing-github-device-code-phishing/ https://www.praetorian.com/blog/introducing-github-device-co....
- cuu508 1y ago
  Use WebAuthn as the second factor. Passkeys are a single factor authentication, and a downgrade from password+WebAuthn.
  - parliament32 1y ago
    Depends on where you store them. If they're in TPM (like WHFB) it's two-factor (because you need the TPM itself, something you have, and PIN or biometric to unlock it, something you know/are). But if you're just loading keys into a software password manager, yes, it's single factor.
    - int_19h 1y ago
      At this point, we have passkey support integrated in both major desktop OSes (Windows, macOS) and both major mobile OSes (Android, iOS). All of them require both the physical device and either PIN or biometric unlock.
feross 1y ago
Disclosure: I’m the founder of https://socket.dev https://socket.dev We analyzed this DuckDB incident today. The attacker phished a maintainer on npmjs.help, proxied the real npm, reset 2FA, then immediately created a new API token and published four malicious versions. A short publish freeze after 2FA or token changes would have broken that chain. Signed emails help, but passkeys plus a publish freeze on auth changes is what would have stopped this specific attack. There was a similar npm phishing attack back in July (https://socket.dev/blog/npm-phishing-email-targets-developers-with-typosquatted-domain https://socket.dev/blog/npm-phishing-email-targets-developer...). In that case, signed emails would not have helped. The phish used npmjs.org — a domain npm actually owns — but they never set DMARC there. DMARC is only set on npmjs.com, the domain they send email from. This is an example of the “lack of an affirmative indicator” problem. Humans are bad at noticing something missing. Browsers learned this years ago: instead of showing a lock icon to indicate safety, they flipped it to show warnings only when unsafe. Signed emails have the same issue — users often won’t notice the absence of the right signal. Passkeys and publish freezes solve this by removing the human from the decision point.
- Moru 1y ago
  Some registrars make this easy. Think it was cloudflare that has a button for "Do not allow email from this domain". Saw it last time I set up a domain that I didn't want to send email from. I'm guessing you get that question if there is no MX records for the domain when you move to cloudflare.
thayne 1y ago
> Of course that's all moot if the attacker also changes the email address. Maybe don't allow changing the email address right after changing 2fa? And if the email is changed, send an email to the original email alllowing you to dispute the change.
chatmasta 1y ago
DuckDB is not critical infrastructure and I don’t even think these billion-download packages are critical infrastructure. In software everything can be rolled back and that’s exactly what happened here. Yes we were lucky that someone caught this rather sloppy exploit early, and (you can verify via the wallet addresses) didn’t make any money from it. And it could certainly have been worse. But I think calling DuckDB “critical infrastructure” is just a bit conceited. As an industry we really overestimate the importance of our software that can be deleted when it’s broken. We take ourselves way too seriously. In any worst case scenario, a technical problem can be solved with a people solution. If you want to talk about critical infrastructure then the xz backdoor was the closest we’ve caught to affecting it. And what came of that backdoor? Nothing significant… I suppose you could say there might be 100 xz-like backdoors lurking in our “critical infrastructure” today, but at least as long as they’re idle, it’s not actually a problem. Maybe one day China will invade Taiwan and we’ll see just how compromised our critical infrastructure has actually been this whole time…
neilv 1y ago
> This is critical infrastructure, and it gets compromised way too often. Most times that I go to use some JS, Python, or (sometimes) Rust framework, I get a sinking feeling, as I see a huge list of dependencies scroll by. I know that it's a big pile of security vulnerabilities and supply-chain attack risk. Web development documentation that doesn't start with `npm install` seems rare now. Then there's the 'open source' mobile app frameworks that push you to use the framework on your workstation with some vendor's Web platform tightly in the loop, which all your code flows through. Children, who don't know how things work, will push any button. But experienced software engineers should understand the technology, the business context, and the real-world threats context, and at least have an uneasy, disapproving feeling every time they work on code like this. And in some cases -- maybe in all cases that aren't a fly-by-night, or an investment scam, or a hobby project on scratch equipment -- software engineers should consider pushing back against engaging in irresponsible practices that they know will probably result in compromise.
- cjonas 1y ago
  What does having an "uneasy disapproving feeling" actually solve?
  - neilv 1y ago
    The next sentence is one of the conclusions it might lead to.
jonplackett 1y ago
One issue is that many institutions - banks, tech giants - still send ridiculously spammy looking emails asking you to click a link and go verify something. All these actions are teaching people to be dumb and make it more likely they’ll fall for a scam because the pattern has been normal before.

by elric 1y ago

progx 1y ago

TRUE! A simple self defined word in an email and you will see, if the mail is fake or not.

zokier 1y ago

Spf/dkim already authenticates the sender. But it doesn't help if the user doesn't check who the email is from. But in that case gpg would not help that much either.

elric 1y ago
SPF & DKIM are all but worthless in practice, because so many companies send emails from garbage domains, or add large scale marketing platforms (like mailchimp) to their SPF records. Like Citroen sends software update notifications for their cars from mmy-customerportal.com. That URL looks and sounds like a phisher's paradise. But somehow, it's legit. How can we expect any user to make the right decision when we push this kind of garbage in their face?
- zokier 1y ago
  The same problem applies to gpg. If companies can not manage to use consistent from addresses then do you really expect them to do any better with gpg key management? "All legitimate npm emails are signed with GPG key X" and "All legitimate npm emails come from @npmjs.com" are equally strong statements.
- JimDabell 1y ago
  The problem is there is no continuity. An email from an organisation that has emailed you a hundred times before looks the same as an email from somebody who has never emailed you before. Your inbox is a collection of legitimate email floating in a vast ocean of email of dubious provenance. I think there’s a fairly straightforward way of fixing this: contact requests for email. The first email anybody sends you has an attachment that requests a token. Mail clients sort these into a “friend request” queue. When the request is accepted, the sender gets the token, and the mail gets delivered to the inbox. From that point on, the sender uses the token. Emails that use tokens can skip all the spam filters because they are known to be sent by authorised senders. This has the effect of separating inbound email into two collections: the inbox, containing trustworthy email where you explicitly granted authorisation to the sender; and the contact request queue. If a phisher sends you email, then it will end up in the new request queue, not your inbox. That should be a big glaring warning that it’s not a normal email from somebody you know. You would have to accept their contact request in order to even read the phishing email. I went into more detail about the benefits of this system and how it can be implemented in this comment: https://news.ycombinator.com/item?id=44969726 https://news.ycombinator.com/item?id=44969726
  - zokier 1y ago
    You don't need complex token arrangements for this. You can just filter emails based on their from addresses.
    - JimDabell 1y ago
      Unfortunately, it’s not that simple. It’s extremely common for the same organisation to send emails from different addresses, different domains, and different servers, for many different reasons.
vel0city 1y ago
There's little reason to think these emails didn't pass SPF/DKIM. They probably "legitimately" own their npmjs[.]help domain and whatever server they used to send the emails is probably approved by them to send for that domain.
- zokier 1y ago
  But in the same vein the phishing email can easily be gpg signed too. The problem is to check if the gpg key used to sign the email is legitimate, but that is exactly the same problem as checking if the from address is legitimate.
- mdaniel 1y ago
  No guessing required, DKIM was intact, but it was also sent via a transactional email service, so that's why https://gist.github.com/Qix-/c1f0d4f0d359dffaeec48dbfa1d40ee9#file-qix-support-at-npmjs-dot-help-phishing-attack-email-L18 https://gist.github.com/Qix-/c1f0d4f0d359dffaeec48dbfa1d40ee...

SoftTalker 1y ago

I think you just have to distrust email (or any other "pushed" messages), period. Just don't ever click on a link in an email or a message. Go to the site from your own previously bookmarked shortcut, or type in the URL. I got a fraud alert email from my credit card the other day. It included links to view and confirm/deny the suspicious charge. It all looked OK, the email included my name and the last digits of my account number. I logged in to the website instead. When I called to follow up I used the phone number printed on my card. Turns out it was a legit email, but you can't really know. Most people don't understand public key signing well enough to rely on them only trusting signed emails. Also, if you're sending emails like this to your users, stop including links. Instead, give them instructions on what to do on your website or app.

sroussey 1y ago
I get Coinbase SMS all the time with a code not to share. But also… “call this phone number if you did not request the code”.
- sgc 1y ago
  This does nothing for the case of receiving a fake coinbase sms with a fake contact phone number. I have had people attempt fraud in my work with live calls as follow up to emails and texts. I only caught it because it didn't pass the smell test so I did quite a bit of research. Somebody else got caught in the exact same scam and I had to extricate them from it. They didn't believe me at first and I had to hit them over the head a bit with the truth before it sank in.
  - Moru 1y ago
    Yes, this is a classic scam vector. We really should stop training users to click links / call phonenumbers in sms and emails.
Moru 1y ago
There is companies that send email with invoices where you have to click a link. There is no way of logging in on their site to get to the invoice. It is an easy fix for them (we use the same invoicing company as they do so I know). All they need to do is click "Allow sending bills directly to customers bank". Every month I get the email, I use the included chat function on the webpage to ask when they will enable this and it's always not possible. Mabe some day. I wish we could stop training people to click links in random messages just because we want to be able to track their movements online.

egorfine 1y ago

> You can't rely on people not falling for phishing 100% of the time 1. I genuinely don't understand why. 2. If it is true that people are the failing factor, then nothing is going to help. Hardware keys? No problem, a human will use the hardware key to sign a malicious action.

MitPitt 1y ago
Removing humans will help
- egorfine 1y ago
  I sense a startup opportunity here
elric 1y ago
> 1. I genuinely don't understand why. It's a war of attrition. You can keep bombarding developers with new and clever ways of trying to obtain their credentials or get them to click on some link while signed in. It only has to succeed once. No one is 100% vigilant all the time. If you think you're the exception, you're probably deluding yourself. There's something broken in a system where one moment of inattention by one person can result in oodles of people ending up with compromised software, and I don't think it's the person that's broken.
- egorfine 1y ago
  Then see #2: there is no way to prevent humans from actually performing detrimental actions, hardware keys or not.
  - vel0city 1y ago
    This specific attack (and many others like it) would have absoultey been foiled by U2F or passkeys. These authors would have been incapable of giving the adversary any useful credential to impersonate them by the very nature of how these systems work.

nikcub 1y ago

* passkeys * signed packages enforce it for the top x thousand most popular packages to start some basic hygiene about detecting unique new user login sessions would help as well

SAI_Peregrinus 1y ago
Requiring signed packages isn't enough, you have to enforce that signing can only be done with the approval of a trusted person. People will inevitably set up their CI system to sign packages, no human intervention needed. If they're smart & the CI system is capable of it they'll set it up to only build when a tag signed by someone approved to make releases is pushed, but far too often they'll just build if a tag is pushed without enforcing signature verification or even checking which contributors can make releases. Someone with access to an approved contributor's GitHub account can very often trigger the CI system to make a signed release, even without access to that contributor's commit signing key.

evantbyrne 1y ago

The email was sent from the 'npmjs dot help' domain. I'm not saying you're wrong, but also basic due diligence would have prevented this. If not by email, the maintainer may have been able to be compromised over text or some other medium. And today maintainers of larger projects can avoid these problems by not importing and auto-updating a bunch of tiny packages that look like they could have been lifted from stack overflow

chrisweekly 1y ago
Re: "npmjs dot help", way too many companies use random domains -- effectively training their users to fall for phishing attacks.
- InsideOutSanta 1y ago
  This exactly. It's actually wild how much valid emails can look like phishing emails, and how confusing it is that companies use different domains for critical things. One example that always annoys me is that the website listing all of Proton's apps isn't at an address you'd expect, like apps.proton.me. It's at protonapps.com. Just... why? Why would you train your users to download apps from domains other than your primary one? It also annoys me when people see this happening and point out how the person who fell for the attack missed some obvious detail they would have noticed. That's completely irrelevant, because everyone is stupid sometimes. Everyone can be stressed out and make bad decisions. It's always a good idea to make it harder to make bad decisions.
  - OkayPhysicist 1y ago
    I can answer why this is at the company I work at right now: It's a PITA to coordinate between teams, and my team doesn't control the main domain. If I wanted my team's application to run on the parent domain, I would have to negotiate with the crayon eaters in IT to make a subdomain, point it at whatever server, and then if I want any other changes to be made, I'd have to schedule a followup meeting, which will generate more meetings, etc. If I want to make any changes to the mycompany.othertld domain, I can just do it, with no approval from anyone.

ignoramous 1y ago

> Can package publishing platforms PLEASE start SIGNING emails I am skeptical this solves phising & not add to more woes (would you blindly click on links if the email was signed?), but if we are going to suggest public key cryptography, then: NPM could let package publishers choose if only signed packages must be released and consumers decide if they will only depend on signed packages. I guess, for attackers, that moves the target from compromising a publisher account to getting hold of the keys, but that's going to be impossible... as private keys never leave the SSM/HSM, right? > Get them to distrust any unsigned email, no matter how convincing it looks. For shops of any important consequence, email security is table stakes, at this point: https://www.lse.ac.uk/research/research-for-the-world/society/cybercrime-business-email-fraud https://www.lse.ac.uk/research/research-for-the-world/societ...

elric 1y ago
I don't think signed email would solve phishing in general. But for a service by-and-for programmers, I think it at least stands a chance. Signing the packages seems like low hanging fruit as well, if that isn't already being done. But I'm skeptical that those keys are as safe as they should be; IIRC someone recently abused a big in a Github pipeline to execute arbitrary code and managed to publish packages in that way. Which seems like an insane vulnerability class to me, and probably an inevitable consequence of centralising so many things on github.

parliament32 1y ago

> it's clear that the current 2FA approach isn't good enough. I don't know how to improve on it USE PASSKEYS. Passkeys are phishing-resistant MFA, which has been a US govt directive for agencies and suppliers for three years now[1]. There is no excuse for infrastructure as critical as NPM to still be allowing TOTP for MFA. [1]https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-0...

smw 1y ago
This is the way! Passkeys or FIDO2 (yubikey) should be required for supply chain critical missions like this.
FreakLegion 1y ago
Yes, use FIDO, you'll be better off, but no, passkeys aren't immune to account takeover. E.g. not only does GitHub support OAuth apps, it supports device code flow, and thus: https://www.praetorian.com/blog/introducing-github-device-code-phishing/ https://www.praetorian.com/blog/introducing-github-device-co....
cuu508 1y ago
Use WebAuthn as the second factor. Passkeys are a single factor authentication, and a downgrade from password+WebAuthn.
- parliament32 1y ago
  Depends on where you store them. If they're in TPM (like WHFB) it's two-factor (because you need the TPM itself, something you have, and PIN or biometric to unlock it, something you know/are). But if you're just loading keys into a software password manager, yes, it's single factor.
  - int_19h 1y ago
    At this point, we have passkey support integrated in both major desktop OSes (Windows, macOS) and both major mobile OSes (Android, iOS). All of them require both the physical device and either PIN or biometric unlock.

feross 1y ago

Disclosure: I’m the founder of https://socket.dev https://socket.dev We analyzed this DuckDB incident today. The attacker phished a maintainer on npmjs.help, proxied the real npm, reset 2FA, then immediately created a new API token and published four malicious versions. A short publish freeze after 2FA or token changes would have broken that chain. Signed emails help, but passkeys plus a publish freeze on auth changes is what would have stopped this specific attack. There was a similar npm phishing attack back in July (https://socket.dev/blog/npm-phishing-email-targets-developers-with-typosquatted-domain https://socket.dev/blog/npm-phishing-email-targets-developer...). In that case, signed emails would not have helped. The phish used npmjs.org — a domain npm actually owns — but they never set DMARC there. DMARC is only set on npmjs.com, the domain they send email from. This is an example of the “lack of an affirmative indicator” problem. Humans are bad at noticing something missing. Browsers learned this years ago: instead of showing a lock icon to indicate safety, they flipped it to show warnings only when unsafe. Signed emails have the same issue — users often won’t notice the absence of the right signal. Passkeys and publish freezes solve this by removing the human from the decision point.

Moru 1y ago
Some registrars make this easy. Think it was cloudflare that has a button for "Do not allow email from this domain". Saw it last time I set up a domain that I didn't want to send email from. I'm guessing you get that question if there is no MX records for the domain when you move to cloudflare.

thayne 1y ago

> Of course that's all moot if the attacker also changes the email address. Maybe don't allow changing the email address right after changing 2fa? And if the email is changed, send an email to the original email alllowing you to dispute the change.

chatmasta 1y ago

DuckDB is not critical infrastructure and I don’t even think these billion-download packages are critical infrastructure. In software everything can be rolled back and that’s exactly what happened here. Yes we were lucky that someone caught this rather sloppy exploit early, and (you can verify via the wallet addresses) didn’t make any money from it. And it could certainly have been worse. But I think calling DuckDB “critical infrastructure” is just a bit conceited. As an industry we really overestimate the importance of our software that can be deleted when it’s broken. We take ourselves way too seriously. In any worst case scenario, a technical problem can be solved with a people solution. If you want to talk about critical infrastructure then the xz backdoor was the closest we’ve caught to affecting it. And what came of that backdoor? Nothing significant… I suppose you could say there might be 100 xz-like backdoors lurking in our “critical infrastructure” today, but at least as long as they’re idle, it’s not actually a problem. Maybe one day China will invade Taiwan and we’ll see just how compromised our critical infrastructure has actually been this whole time…

neilv 1y ago

> This is critical infrastructure, and it gets compromised way too often. Most times that I go to use some JS, Python, or (sometimes) Rust framework, I get a sinking feeling, as I see a huge list of dependencies scroll by. I know that it's a big pile of security vulnerabilities and supply-chain attack risk. Web development documentation that doesn't start with `npm install` seems rare now. Then there's the 'open source' mobile app frameworks that push you to use the framework on your workstation with some vendor's Web platform tightly in the loop, which all your code flows through. Children, who don't know how things work, will push any button. But experienced software engineers should understand the technology, the business context, and the real-world threats context, and at least have an uneasy, disapproving feeling every time they work on code like this. And in some cases -- maybe in all cases that aren't a fly-by-night, or an investment scam, or a hobby project on scratch equipment -- software engineers should consider pushing back against engaging in irresponsible practices that they know will probably result in compromise.

cjonas 1y ago
What does having an "uneasy disapproving feeling" actually solve?
- neilv 1y ago
  The next sentence is one of the conclusions it might lead to.

jonplackett 1y ago

One issue is that many institutions - banks, tech giants - still send ridiculously spammy looking emails asking you to click a link and go verify something. All these actions are teaching people to be dumb and make it more likely they’ll fall for a scam because the pattern has been normal before.