Earlier quoted context omitted.
Passkeys already solve for this, we just have to get past the FUD.
In this case, how is the Passkey safer than 2FA?
It’s cryptographically bound to the domain.
NPM debug and chalk packages compromised
611–620 of 796 posts
Re: NPM debug and chalk packages compromised
#612Developer account got hijacked through phishing. @junon acknowledged this readily and is trying to get it sorted. Meanwhile, this is a mistake that can happen to anyone, especially under pressure. So no point in discussing the personal oversight. So let me raise a different concern. This looks like an exploit for web browsers, where an average user (and most above average users) have no clue as to what's running unde…
> - How do the end user protect themselves at this point? Especially the average user? - Install as little software as possible, use websites if possible. - Keep important stuff (especially cryptocurrency) on a separate device. - If you are working on a project that pulls 100s of dependencies from a package registry, put that project on a VM or container.
> Install as little software as possible, use websites if possible.
If I understood this correctly, this is an exploit for the browser.
Re: NPM debug and chalk packages compromised
#613Earlier quoted context omitted.
the UI for client side certificates was shit for years. no one particularly cared. passkeys however are... pretty reasonable.
At least on a Mac, you can just double-click a cert file, it'll prompt to install in Keychain, and anything using macOS's TLS implementation will see it.
And what about the browser? How does it know which client cert (I assume the key is also there) to use for a site? Does it prompt you before proceeding with authentication?
Re: NPM debug and chalk packages compromised
#614Earlier quoted context omitted.
the UI for client side certificates was shit for years. no one particularly cared. passkeys however are... pretty reasonable.
That's just it. If any of the browser vendors put 1% of the work they spent on renewing their visual identity, remodeling their home page, or inventing yet another menu system into slightly easier to use client certificates (and smart cards) this would have been a solved problem two decades ago. All the pieces are in place, every browser has supported this since the birth of SSL, it's just the user interface bits tha…
Bingo! Exactly my point. Thanks!
Re: NPM debug and chalk packages compromised
#615Re: NPM debug and chalk packages compromised
#616Earlier quoted context omitted.
npmjs is the stdlib, or what emerged from it. It started as CommonJs ([1]) with Server-side JavaScript (SSJS) runtimes like Helma, v8cgi, etc. before node.js even existed but then was soon totally dominated by node.js. The history of Server-side JavaScript btw is even longer than Java on the server side, starting with Netscape's LifeScript in 1996 I believe. Apart from the module-loading spec, the CommonJs initiative…
> TypeScripters who need big daddy MS or other monopolist to sort it all out for them What is this crap statement? So you want type-checking because it helps you catch a class of errors in an automated way, and suddenly you have a daddy complex and like monopolies? Claiming this says a lot more about you than people who use TypeScript.
If you want type safety there are any number of better languages out there compiling to JavaScript. The entire point of JS is that's a portable good enough dynamic scripting language, not a freaking mess changing all the time.
Re: NPM debug and chalk packages compromised
#617Earlier quoted context omitted.
Hey, you're doing an exemplary response, transparent and fast, in what must be a very stressful situation! I figure you aren't about to get fooled by phishing anytime soon, but based on some of your remarks and remarks of others, a PSA: TRUSTING YOUR OWN SENSES to "check" that a domain is right, or an email is right, or the wording has some urgency or whatever is BOUND TO FAIL often enough. I don't understand how mos…
Or you know, get a password manager like the rest of us. If your password manager doesn't show the usual autofill, since the domain is different than it should, take a step back and validate everything before moving on. Have the TOTP in the same/another password manager (after considering the tradeoffs) and that can also not be entered unless the domain is right :)
I wish it's that easy. 1Password autofill on Android Chrome broke for me a month ago. Installed all updates, checked settings, still nothing. Back to phishing prone copy paste.
Re: NPM debug and chalk packages compromised
#618It wouldn't be a perfect solution, but I wonder why browsers don't indicate the registration date for a domain in the URL bar somehow? I bet junon would have seen that and gotten suspicious.
There are curated lists over newly registered domain names that some security software uses so it should be easy to add without any privacy issues.
Re: NPM debug and chalk packages compromised
#619Earlier quoted context omitted.
Then good password managers will still show you only the logins for that domain. If the login is on another domain then you would have saved it anyways when first logging in/registering and if the site moved then you can get suspicious and check carefully first.
What are good password managers for chrome and Firefox on Android?
Personally a big fan of 1Password. On the topic of autofill, the only website it sometimes won't fill is Reddit, which you know, whatever, I never go there anymore anyway.
As a developer I also love their ssh and gpg integrations, very handy.
I do get it for free from work, but if I had to choose one myself I'd have to pay for I'd probably still pick 1Passwrod.
Re: NPM debug and chalk packages compromised
#620Earlier quoted context omitted.
Not a web guy, but that seems a bonkers default. I would have naively assumed a lockfile would be used unless explicitly ignored.
We didn't get locking until npm v5 (some memory and googling, could be wrong.) And it took a long time to do everything you'd think you want. Changing the main command `npm install` after 7 years isn't really "stable". Anyway didn't this replace versions, so locking won't have helped either?
You can’t replace existing versions on npm. (But probably more important is what @jffry mentioned – yes, lockfiles include hashes.)