The recent (and still ongoing) phishing of NPM developer accounts showed yet again that even technically sophisticated and aware users are falling for phishing lures. Anybody will fall for phishing if a well-targeted e-mail is used.
The recent (and still ongoing) phishing of NPM developer accounts showed yet again that even technically sophisticated and aware users are falling for phishing lures. Anybody will fall for phishing if a well-targeted e-mail is used.
All it took for the NPM phish to succeed was a well-written email and a convincing landing page. This case used “npmjs.help”, but a few days later, someone also registered “npmjs.cam” (the TLD is .CAM, not .COM, a somewhat underused phishing trick).
Luckily, npmjs.cam is currently not reachable:
So if even experienced developers fall for these tricks, how do we protect people like HR, or worse, our sales team? More click-through security awareness training? Instructing them “not to click on links”? Or… triple-factor authentication?
Training has been shown to be ineffective at best, and will not prevent the sales team from opening an updated commission schedule in panic [1][2]. If users are not supposed to click on a link, then why are we not just removing them at your mail gateway (instead of replacing them with a wrapper)?
The real solution lies in how we authenticate, and it is not about multiple factors. Multifactor authentication addresses a different problem: Part of the authentication secrets may be compromised. Sophisticated, successful phishing may compromise all factors. Phishing works because users are unable to reliably identify websites. URLs and TLS certificates are technical means that identify websites, but they are not suitable for identification by most humans. It is too easy to come up with a look-alike domain, and often that isn’t even needed.
Multi-factor authentication does not work as an attacker may pass-through credentials, as implemented in tools like evilginx, asking the user to provide all the necessary authentication parameters. The only way to protect from tools like this is to not have the user in charge of selecting the right credentials. Any authentication mechanism that requires the user to make a decision as to what credential to use for a particular website is not fundamentally phishing-resistant.
The simplest form of a “more phishing-resistant” authentication scheme is a password manager. Password managers are pretty good at figuring out which website a user is currently visiting and what credentials to use. Of course, users are often able to overwrite this decision, leading to phishing.
A better way is cryptography, which only makes particular credentials accessible to specific sites. For example, Passkeys. Passkeys are selected automatically based on the origin of the site the user attempts to log in to. It is not possible for the user to select different credentials, ensuring phishing safety. TLS client certificates could work as well, but are technically more complex to properly implement and, as a result, not practical for most public sites.
NIST in publication 800-63B specifically states: “Phishing resistance requires single- or multi-factor cryptographic authentication. Authenticators that involve the manual entry of an authenticator output (e.g., out-of-band and OTP authenticators) SHALL NOT be considered phishing-resistant because the manual entry does not bind the authenticator output to the specific session being authenticated.” This defines popular authentication methods, like Microsoft’s authenticator-based MFA, as not phishing-resistant.
So in short: Stop blaming the user and instead get working on Passkeys for any site that you believe needs a little bit extra security.
[1] https://arxiv.org/html/2506.19899v2
[2] https://cs.uchicago.edu/news/new-study-reveals-gaps-in-common-types-of-cybersecurity-training/
[3] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf
—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Leave A Reply