Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

Post reply on HN
Print view View original

671–680 of 796 posts

Re: NPM debug and chalk packages compromised

#671

Post by diggan »

SchemaLoad wrote: post #556
diggan wrote: post #485

Earlier quoted context omitted.

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 feel like it's extremely common for the autofill to not work for various reasons even when you aren't being phished. I have to manually select the site to fill fairly often, especially inside apps where the password manager doesn't seem to match the app to the website password. Passkeys seem like the best solution here where you physically can not fall for a phishing attack.

> I feel like it's extremely common for the autofill to not work for various reasons even when you aren't being phished

I dunno, it mostly seems to not work when companies change their field names/IDs, or just 3rd party authentication, then you need to manually add domains. Otherwise my password manager (1Password) works everywhere where I have an account, except my previous bank which was stuck in the 90s and disallowed pasting the passwords. If you find that your password manager doesn't work with most websites (since it's "extremely common") you might want to look into a different one, even Firefox+Linux combo works extremely well with 1Password. Not affiliated, just a happy years+ user.

> Passkeys seem like the best solution here where you physically can not fall for a phishing attack.

Yeah, I've looked into Passkeys but without any migration strategy or import/export support (WIP last time I looked into it), it's not really an alternative just yet, at least for me personally. I have to be 100% sure I can move things when the time ultimately comes for that.

Re: NPM debug and chalk packages compromised

#673

Post by __MatrixMan__ »

zarzavat wrote: post #630
macintux wrote: post #579

Earlier quoted context omitted.

And it's not like it would hurt the developers to be conscious of their choices.

There's actually nothing the developers can do about this particular issue other than to display all colors and allow colorblind people to see the colors that they can see.

It doesn't matter which colors the algorithm chooses so long as background/foreground are very distinguishable to as wide an audience as possible, and prev/next are likely to be distinguishable more often than not.

That's a lot of flexibility within which to do clever color math which accounts for the types of colorblindness according to their prevalence.

Re: NPM debug and chalk packages compromised

#675

Post by __MatrixMan__ »

b112 wrote: post #636
zarzavat wrote: post #630

Earlier quoted context omitted.

There's actually nothing the developers can do about this particular issue other than to display all colors and allow colorblind people to see the colors that they can see.

For the newly made up feature, which doesn't exist yet, but already has an issue? Simple. Instead of forcing colour, one could retain a no colour option maybe? Done. Solved. Everything should have this option. I personally have no colour vision issues, other than I find colour annoying in any output. There's a lot who prefer this too.

Agreed, although I would argue that maximal hash contrast should be default, and if people find they prefer less, they can turn it down.

If you're the sort of person who would think about adjusting it to suit your sensitivity to this kind of attack, you're likely not the sort of person that the feature is trying to protect anyhow.

Re: NPM debug and chalk packages compromised

#676

Post by rollcat »

naikrovek wrote: post #315
notmyjob wrote: post #184

Earlier quoted context omitted.

Agree, but this example wasn’t even that aggressive in its urgency and op said they were merely ticking things off the todo, not feeling alarmed by the urgency. The problem is email as it’s used currently. The solution is to not use email.

> The solution is to not use email. and use what? instant message? few things lack legitimacy more than an instant message asking you to do something. Links in email are much more of a problem than email itself. So tempting to click. It's right there, you don't have to dig through bookmarks, you don't have to remember anything, just click. A link is seductive. the actual solution is to avoid dependencies whenever pos…

> the actual solution is to avoid dependencies whenever possible, so that you can review them when they change.

If you're publishing your software: you can't "not" depend on some essential service like source hosting or library index.

> You ARE reviewing them, right?

Werkzeug is 20kloc and is considered "bare bones" of Python's server-side HTTP. If you're going to write a complex Python web app using raw WSGI, you're just going to repeat their every mistake.

While at it: review Python itself, GCC, glibc, maybe Linux, your CPU? Society depends on trust.

Re: NPM debug and chalk packages compromised

#677

Post by rollcat »

lelanthran wrote: post #376
notmyjob wrote: post #184

Earlier quoted context omitted.

Agree, but this example wasn’t even that aggressive in its urgency and op said they were merely ticking things off the todo, not feeling alarmed by the urgency. The problem is email as it’s used currently. The solution is to not use email.

> The problem is email as it’s used currently. The solution is to not use email. No. The problem is unsigned package repositories. The solution is to tie a package to an identity using a certificate. Quickest way I can think off would be requiring packages to be linked to a domain so that the repository can always check incoming changes to packages using the incoming signature against the domain certificate.

> The solution is to tie a package to an identity using a certificate.

Identity on the Internet is a lie. Nobody knows you're a dog.

The solution is to make security easy and accessible, so that the user can't be confused into doing the insecure thing.

Re: NPM debug and chalk packages compromised

#679

Post by 3abiton »

DDerTyp wrote: post #52

One of the most insidious parts of this malware's payload, which isn't getting enough attention, is how it chooses the replacement wallet address. It doesn't just pick one at random from its list. It actually calculates the Levenshtein distance between the legitimate address and every address in its own list. It then selects the attacker's address that is visually most similar to the original one. This is a brilliant…

That moment where you respect the hacker. Still we are encroaching on dark times.
Post reply on HN