Sorry to be dumb, but can you expand a bit on "2FA reset email..." so the rest of us know what not to do?
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. EDIT: Yeah they did, nevermind. Was a TOTP proxy attack, or whatever you'd call it.
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.
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.
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.
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.