Hacker News Reader

Comment by charcircuit | Hacker News Reader

Does OIDC flow block this same issue of being able to use a RAT to publish a malicious package?

No, once the computer is compromised nothing really helps assuming the attacker is patient enough.

No. axios (v1 at least; not v0) were setup to publish via OIDC, but there's no option on npmjs for package maintainers to restrict their package to *only* using OIDC. The maintainer says his machine was infected via RAT, so if he was using software-based 2FA, nothing could have prevented this.

Actually there is an option to restrict to only OIDC publishing. It is a bit hidden and relies on a different form for reasons I really cannot understand. Npm UX is just so bad.

Point 4 from https://npmdigest.com/guides/npm-trusted-publishing#ux-probl...

(I wrote that guide page for myself because I always get annoyed when dealing with npm OIDC)

Nope, the most restrictive option available is to disallow tokens and require 2FA. I think that using exclusively hardware 2FA and not having the backup codes on the compromised machine probably would have prevented this attack though.

Someone in the linked Github thread describes an attack where the attackers waited for the victim to use their Yubikey for an AWS login, giving the attackers access to AWS as well. I don't think hardware 2FA is safe against a RAT.

Logins are session-based. You could tie publishing of a package to a signature from the key, then 1 tap = 1 package hash. But yeah, if the system is compromised and the attacker is doing interactive attacks they can wait for something that requires using the key and then trigger the publishing and win a race against the real prompt. To the user it might just appear like having to tap twice.

Reply on news.ycombinator.com