4 ms·

I wonder how bad will this cred-stuffing package authors problem will get before npm/other package managers flat out require 2FA for maintainers

hn_throwaway_99 7y ago
I think the blog author is implying as much as he can, without directly accusing, that he believes that https://github.com/shinnn https://github.com/shinnn was responsible for the bad code, not a random hack.
- JulianMorrison 7y ago
  2FA would also make it much harder to use the "somebody hacked me" defense.
  - Operyl 7y ago
    No at that point they'd be saying "zomg NPM has a terrible bug that allowed the hacker to bypass my 2FA!" If someone is trying to redirect blame they'll always find some way to do so.
    - JulianMorrison 7y ago
      The problem is not liars, the problem is being unable to prove they were lying. With 2FA, the logs would prove it.
      - Operyl 7y ago
        Unfortunately, based on preexisting cases it really doesn't make much of a difference, the liars will still deflect the blame and the logs will always be "wrong".
- btown 7y ago
  To quote the article: "As far as we are aware, the only purpose of the malicious code was to sabotage the purescript npm installer to prevent it from running successfully... the purpose of this condition [in the code, hardcoded to include the word 'cli'] seems to be to ensure that the malicious code only runs when our installer is being used (and not @shinnn’s)." :hmm:
  - uponcoffee 7y ago
    >>[[ 9 July, around 0100 UTC: @doolse identifies thatload-from-cwd-or-npm@3.0.2 is the cause. See purescript/npm-installer#12 (comment) @doolse opens an issue on the load-from-cwd-or-npm repo pointing out that the package is breaking the purescript npm installer (although at this stage, none of us spot that the code is malicious). This issue is later deleted by @shinnn. ]] Hmm indeed. A hack is possible but the timeline of events is dubious.
jasonwatkinspdx 7y ago
I mean, do you really think some hacker compromised @shinnn's account, solely for the purpose of sabotaging a new installer that had only been published for 8 hours? I mean, I'm all for benefit of the doubt and such, but it's pretty obvious what happened here.
- rmrfrmrf 7y ago
  This was my gut reaction, but on further thought, this whole thing seems so needlessly petty that it could have easily been the author attempting to make the other person look bad.
keyle 7y ago
npm should absolutely enforce 2FA imho.
jasonhansel 7y ago
Better yet: use encryption keys to verify identity.
- TheDong 7y ago
  I don't think encryption keys actually are useful for the average case here. Currently, developers store npm tokens which may be stolen because they're often stored on disk or as environment variables. Requiring developers to store encryption keys makes almost no difference: the private key will still be stored on disk and will still be vulnerable to effectively the same attacks. There are some differences of course. Security-conscious users could use hardware tokens to store their encryption keys, and they could password protect the private key in either case. This is not the large majority of users though, so in the average case, it won't matter.
stephenr 7y ago
I'm not really familiar with how NPM packages are published - is it just referencing a commit hash in a repo, or is it a separate upload direct? If it's the former (or could be made to be the former), requiring GPG signed commits would go a long way to preventing malicious activity.

hn_throwaway_99 7y ago

I think the blog author is implying as much as he can, without directly accusing, that he believes that https://github.com/shinnn https://github.com/shinnn was responsible for the bad code, not a random hack.

JulianMorrison 7y ago
2FA would also make it much harder to use the "somebody hacked me" defense.
- Operyl 7y ago
  No at that point they'd be saying "zomg NPM has a terrible bug that allowed the hacker to bypass my 2FA!" If someone is trying to redirect blame they'll always find some way to do so.
  - JulianMorrison 7y ago
    The problem is not liars, the problem is being unable to prove they were lying. With 2FA, the logs would prove it.
    - Operyl 7y ago
      Unfortunately, based on preexisting cases it really doesn't make much of a difference, the liars will still deflect the blame and the logs will always be "wrong".
btown 7y ago
To quote the article: "As far as we are aware, the only purpose of the malicious code was to sabotage the purescript npm installer to prevent it from running successfully... the purpose of this condition [in the code, hardcoded to include the word 'cli'] seems to be to ensure that the malicious code only runs when our installer is being used (and not @shinnn’s)." :hmm:
- uponcoffee 7y ago
  >>[[ 9 July, around 0100 UTC: @doolse identifies thatload-from-cwd-or-npm@3.0.2 is the cause. See purescript/npm-installer#12 (comment) @doolse opens an issue on the load-from-cwd-or-npm repo pointing out that the package is breaking the purescript npm installer (although at this stage, none of us spot that the code is malicious). This issue is later deleted by @shinnn. ]] Hmm indeed. A hack is possible but the timeline of events is dubious.

jasonwatkinspdx 7y ago

I mean, do you really think some hacker compromised @shinnn's account, solely for the purpose of sabotaging a new installer that had only been published for 8 hours? I mean, I'm all for benefit of the doubt and such, but it's pretty obvious what happened here.

rmrfrmrf 7y ago
This was my gut reaction, but on further thought, this whole thing seems so needlessly petty that it could have easily been the author attempting to make the other person look bad.

keyle 7y ago

npm should absolutely enforce 2FA imho.

jasonhansel 7y ago

Better yet: use encryption keys to verify identity.

TheDong 7y ago
I don't think encryption keys actually are useful for the average case here. Currently, developers store npm tokens which may be stolen because they're often stored on disk or as environment variables. Requiring developers to store encryption keys makes almost no difference: the private key will still be stored on disk and will still be vulnerable to effectively the same attacks. There are some differences of course. Security-conscious users could use hardware tokens to store their encryption keys, and they could password protect the private key in either case. This is not the large majority of users though, so in the average case, it won't matter.

stephenr 7y ago

I'm not really familiar with how NPM packages are published - is it just referencing a commit hash in a repo, or is it a separate upload direct? If it's the former (or could be made to be the former), requiring GPG signed commits would go a long way to preventing malicious activity.