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

NPM won't publish packages containing the word keygen

mamot.fr

Post reply on HN
Print view View original

251–260 of 269 posts

Re: NPM won't publish packages containing the word keygen

#251

Post by joelwilliamson »

nailer wrote: post #244
retrocryptid wrote: post #237

Earlier quoted context omitted.

Just learned "keygen" is the term the script-kiddies use to describe the act of generating fake activation keys. Never let it be said HN is not educational. But I feel the same way I felt when I noticed idiots using "crypto" to refer to cryptocurrency instead of cryptography.

Keygen has been around for for at least 30 years, whereas people misusing the term “crypto” has only been around for five years or so.

Why is it a misuse to use "crypto" to refer to a currency whose design relies on secrets, but it's fine to use "crypto" to refer to keeping communications private using some secret information?

Re: NPM won't publish packages containing the word keygen

#252

Post by tzs »

hunter2_ wrote: post #230
JohnFen wrote: post #185

Earlier quoted context omitted.

Some banks have a service where if you use your card for ongoing regular payments and the card is replaced for any reason, the bank will allow those regular charges to continue on the new card when the service provider uses the old number. It's very convenient if that's what you want -- it means you don't have to go to all of the ongoing services to update your card immediately. But it does mean that you can't count…

Ah. So in that case, NPM is not learning a new card number, and probably isn't even aware of anything at all, given that the card issuer is simply accepting transactions (instead of declining them as this person expected) on the old card number. NPM was in the wrong for continuing to place unwanted transactions, but they were not actively participating in this "follow" scheme so the blame stops short of that.

No, they get the new number.

The way the update services is work is that you send them the card type, card number, and expiration date of a card you have on file, and they respond typically with one of these four responses:

1. Still good.

2. The account is closed.

3. The card is still good but has a new expiration date, which is YYMM.

4. The account has a new card. The card number is XXXXXXXXXXXXXXXX and the expiration date is YYMM.

Re: NPM won't publish packages containing the word keygen

#253

Post by nailer »

joelwilliamson wrote: post #251
nailer wrote: post #244

Earlier quoted context omitted.

Keygen has been around for for at least 30 years, whereas people misusing the term “crypto” has only been around for five years or so.

Why is it a misuse to use "crypto" to refer to a currency whose design relies on secrets, but it's fine to use "crypto" to refer to keeping communications private using some secret information?

I do crypto the airport (opening the barriers with my passport, where the computer in my passport signs a challenge encrypted with its pubkey) and do crypto with my phone (making a call, which is encrypted with Ericsson SNOW), and do crypto at the corner shop (using my card, same as the passport).

If airports, phones, and corner shops claimed they 'work in crypto' it would be similarly misleading.

Even Toly refers to himself as a distributed systems engineer, because building a blockchain involves more DS work than crypto work.

FWIW I work in web3/defi, used to work in PKI.

Re: NPM won't publish packages containing the word keygen

#254

Post by tobiasSoftware »

hunter2_ wrote: post #165
tobiasSoftware wrote: post #158

Earlier quoted context omitted.

Fun fact. Several years ago I started getting charges from NPM, which although I am a software developer I have never used. I cancelled my credit card multiple times, but they kept appearing each month. I went to my bank, Bank of America, and they claimed that there was nothing they could do because NPM was using some sort of option they had to follow me when I got new credit cards. I don't know what kind of option t…

Ok, I'll bite. There is no way a merchant can learn a new card number other than from the cardholder, or from a thief who got it from the card/cardholder. Not from any upstanding entity. If you merely got a new expiration date, security code, etc. without also changing the card number, they could "follow" that by submitting a transaction without those extra pieces of information, at greater cost and risk to themselve…

I was as shocked as you, and was absolutely infuriated over the bank telling me that they couldn't manually override whatever was going on. I can assure you it was a real thing that happened, and I did cancel my credit card and get a new number, if I remember I tried that at least twice.

I found the email from NPM when they fixed it, though in the email they still claim that my card details were stolen and it should be closed, ignoring that I had done that multiple times already. The email is below. Apparently there were 28 charges, so it must have been around 2 years that this was ongoing, I was dealing with some major issues at that time so I had to put it on the backburner for that time.

As far as digital wallets and virtual cards, I have none of those things. I may be a programmer, but I haven't gone techy with my finances, I just have a checking account and a credit card, and this charge kept appearing on my credit card across at least two card cancellations. Having said that, I have no idea what would happen if a fraudulent digital wallet or virtual card was set up that I was unaware of. The issue did start in 2015 though, so I'm not sure if those even existed back then.

Email from @npmjs.com: "We've completed the investigation into the charges we believe linked to your card ending in [Redacted]. We've refunded each individual charge for a total of $196 (28 refunds at $7/each). You should see those credited back to your account within a few business days.

We've canceled the subscription the charges were linked to, and removed the billing details. That said, we'd still encourage you to notify your bank that the card information was stolen and that the card should be closed.

Thanks for your patience while we worked through this on our end. I understand it wasn't ideal and even frustrating at times. I'm sorry for that.

Please let us know if there is anything else we can do for you. We’ll be here to help."

Re: NPM won't publish packages containing the word keygen

#255

Post by salawat »

codetrotter wrote: post #38
ezekg wrote: post #19

I run a business called Keygen [^0], and own the @keygen namespace on npm. We’re working on a Node SDK, so this isn’t good to hear. I’ll open up a discussion with them and see what we can do. [^0]: https://keygen.sh

Time to change the name of your business to kexgen I guess.

Better idea.

KeyDjinn

Or

Keygyn

Get in that extra level of possible scandal.

Either way, the logos practically make themselves.

Re: NPM won't publish packages containing the word keygen

#256

Post by salawat »

insanitybit wrote: post #236
smashah wrote: post #64

Earlier quoted context omitted.

Malicious unchecked code in postinstall can just be moved to runtime so blanket blocking postinstall is as effective a solution to supply chain attacks as the solution of blocking npm packages with the word "keygen" in them is to the problem of .... js based keygens??? There are many legitimate purposes for postinstall scripts yet the anti-postinstall crowd acts like they solved security issues with this one easy ste…

> moved to runtime So a completely different scenario? Let's assume for a moment that developers only ever 'build' or 'check' their code, but all actual runtime behavior is in production. In production we have toooooons of security tooling for monitoring and constraining program behavior. On dev computers? Basically nothing. Of course, developers run `test` as well, and sometimes they run the whole program but these…

Not running your tests locally to make sure stuff actually compiles/works before commiting to the repo and blowing up everyone else is a great way to piss off your QA group.

Please, make sure it runs locally first. CI often costs $$$, and when you nab a QA for debugging support, nothing irritates more than the answer "Well, no..." to the question "Did you even compile/run this?"

Re: NPM won't publish packages containing the word keygen

#257

Post by justaj »

creshal wrote: post #33
ijustlovemath wrote: post #31

Earlier quoted context omitted.

unrelated to your question: Your website's very pretty, but doesn't scroll horizontally on mobile. It also looks like there might be a bug in the code sample - where does "fingerprint" come from?

It doesn't scroll on desktop either, I guess the world still is not ready for people having multiple windows open in parallel.

It scrolls fine here with JS disabled.

Re: NPM won't publish packages containing the word keygen

#258

Post by hunter2_ »

tzs wrote: post #252
hunter2_ wrote: post #230

Earlier quoted context omitted.

Ah. So in that case, NPM is not learning a new card number, and probably isn't even aware of anything at all, given that the card issuer is simply accepting transactions (instead of declining them as this person expected) on the old card number. NPM was in the wrong for continuing to place unwanted transactions, but they were not actively participating in this "follow" scheme so the blame stops short of that.

No, they get the new number. The way the update services is work is that you send them the card type, card number, and expiration date of a card you have on file, and they respond typically with one of these four responses: 1. Still good. 2. The account is closed. 3. The card is still good but has a new expiration date, which is YYMM. 4. The account has a new card. The card number is XXXXXXXXXXXXXXXX and the expirati…

Oh, ok. Still doesn't feel right blaming the merchant for utilizing #4 in exactly the intended manner.

The existence of #4 seems odd though. If someone just wanted different card perks they could do a "product change" which I believe retains the same number anyway, so a new number should only occur if the old number was reported stolen, in which case why provide the new number to the potential thief?

Re: NPM won't publish packages containing the word keygen

#259

Post by insanitybit »

salawat wrote: post #256
insanitybit wrote: post #236

Earlier quoted context omitted.

> moved to runtime So a completely different scenario? Let's assume for a moment that developers only ever 'build' or 'check' their code, but all actual runtime behavior is in production. In production we have toooooons of security tooling for monitoring and constraining program behavior. On dev computers? Basically nothing. Of course, developers run `test` as well, and sometimes they run the whole program but these…

Not running your tests locally to make sure stuff actually compiles/works before commiting to the repo and blowing up everyone else is a great way to piss off your QA group. Please, make sure it runs locally first. CI often costs $$$, and when you nab a QA for debugging support, nothing irritates more than the answer "Well, no..." to the question "Did you even compile/run this?"

> Not running your tests locally to make sure stuff actually compiles/works before commiting to the repo and blowing up everyone else is a great way to piss off your QA group.

Uh... branches? Obviously?

Re: NPM won't publish packages containing the word keygen

#260

Post by tzs »

hunter2_ wrote: post #258
tzs wrote: post #252

Earlier quoted context omitted.

No, they get the new number. The way the update services is work is that you send them the card type, card number, and expiration date of a card you have on file, and they respond typically with one of these four responses: 1. Still good. 2. The account is closed. 3. The card is still good but has a new expiration date, which is YYMM. 4. The account has a new card. The card number is XXXXXXXXXXXXXXXX and the expirati…

Oh, ok. Still doesn't feel right blaming the merchant for utilizing #4 in exactly the intended manner. The existence of #4 seems odd though. If someone just wanted different card perks they could do a "product change" which I believe retains the same number anyway, so a new number should only occur if the old number was reported stolen, in which case why provide the new number to the potential thief?

The update service is only available to merchants, and even then I believe there is extra vetting beyond simply being allowed to accept credit card payments. The intersection of that set and the set of credit card thieves is small.

For a typical user who has their card stolen it will go something like this. Fraudulent charges start appearing on their card, which is when they realize their card number has been stolen. The bank issues them a new card, makes sure the fraudulent charges get refunded, and invalidates the old card so the thieves won't be able to put new charges on it.

Without the updater service the user would have to deal with contacting every place they have subscriptions and update their on file card to avoid having their services disrupted.

With the updater service many or most of those will update automatically.

If the thieves used the card to buy some subscriptions, and those are from merchants who are able to use the update services, then those services may get the new number so the user might have to contact them to cancel.

For most people in that case though the number of subscriptions they legitimately have will be much less than the number of subscriptions that the credit card thieves purchased on the user's stolen card.

Post reply on HN