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

Compromising Angular via expired NPM publisher email domains

thehackerblog.com

Post reply on HN
Print view View original

71–80 of 82 posts

Re: Compromising Angular via expired NPM publisher email domains

#71

Post by arccy »

01acheru wrote: post #20

A tangential issue related to this since Github is involved: Github pages. If you point a DNS entry to a Github page and then delete the page without deleting the entry on you DNS table someone can create a new page with the same name and hijack your DNS entry for malicious purposes. I've written to Github already about this, if they want to let you point your DNS to the page they should give you a unique entry to po…

at least they allow you to verify and restrict who can do this now https://docs.github.com/en/pages/configuring-a-custom-domain...

Re: Compromising Angular via expired NPM publisher email domains

#72

Post by tedunangst »

codingkev wrote: post #70
robbie-c wrote: post #41

Earlier quoted context omitted.

> I don't like GitHub's security screener dismissing this report because of the "social engineering" aspect. Agreed. I get where it comes from, npm isn't responsible for individual contributors getting social-engineered, but this is much deeper than that, and part of the flaw is with npm's support allowing the password reset to go through.

What do you suggest as an alternative to password reset based on the account email?

If you retired the email because the domain expired, maybe don't let it reset existing accounts. It's dead.

Re: Compromising Angular via expired NPM publisher email domains

#73

Post by wink »

the8472 wrote: post #59

Entirely avoidable if people could buy domains for 100years, paid up-front.

For what percentage of the population? Going with an easy example of 12$/year for a .org - I can tell you I can think of exactly 0 people in my circle of friends who would put down 1200$ for a domain.

Re: Compromising Angular via expired NPM publisher email domains

#74

Post by jmull »

burrows wrote: post #58
ShakataGaNai wrote: post #57

> Developers using custom domains for their email address should seriously consider the risks they are taking on by using the email for their online accounts. If this domain expires or is hijacked, where does that leave them? This high level point really irritates me. What if your let your domain expire? What if your domain is hijacked? This applies to EVERYONE doing ANYTHING online with their own domain name - aka e…

Seems like the author is making a reasonable point to me. The risk profile for a gmail email address and a custom domain email address are different and developers may benefit from understanding this difference. I don’t think he’s attacking the character or intelligence of people who use custom domains, he’s pointing out a gotcha that they may not be aware of.

You're giving the article more credit than it's earned.

Indeed, a developer should understand the risks and benefits associated with using an email address on domains they control vs. domains someone else controls.

Too bad the article doesn't make that point.

(Seems obvious to me that a domain you control is less risky since the mitigations are relatively straight-forward and reliable, while for a domain you don't control, you really don't have any reliable mitigations if the domain owner decides to shut you down. Not to mention that a third-party domain also has the risk of expiring or being highjacked. A third-party domain only makes sense if you want to trade risk for dollars: a cheaper or free email address for a greater risk of losing control of the email address.)

Re: Compromising Angular via expired NPM publisher email domains

#75

Post by 01acheru »

arccy wrote: post #71
01acheru wrote: post #20

A tangential issue related to this since Github is involved: Github pages. If you point a DNS entry to a Github page and then delete the page without deleting the entry on you DNS table someone can create a new page with the same name and hijack your DNS entry for malicious purposes. I've written to Github already about this, if they want to let you point your DNS to the page they should give you a unique entry to po…

at least they allow you to verify and restrict who can do this now https://docs.github.com/en/pages/configuring-a-custom-domain...

It is good they finally worked this out, it's been years I wrote them about this (and many many others did the same, I was not the first nor the last to warn them).

I just don't understand why taking so long to fix this, and why they fixed it in such a complicated fashion when it's a really basic use case with a simple and straightforward solution that adds no burden to the end user.

Re: Compromising Angular via expired NPM publisher email domains

#76

Post by remram »

josteink wrote: post #62
remram wrote: post #53

Earlier quoted context omitted.

But you rent the domain as well. With the additional caveat that the domain will be available for renting by anybody else once you stop paying, whereas Gmail won't.

> With the additional caveat that the domain will be available for renting by anybody else once you stop paying Not with the “additional” caveat. That’s the only caveat, and it’s a simple, understandable and known risk. Using gmail.com or whatever puts you in a situation where the risks are numerous and unknown, and as a non-paying freeloader you get nothing to say in how access to your digital identity is managed. I…

People have had their GoDaddy/NameCheap/... account social-engineered away from them too. That might be easier to fix than your Gmail (because you're a paying customer), but if your npm is already gone, having NameCheap apologize doesn't help much.

Re: Compromising Angular via expired NPM publisher email domains

#77

Post by sangnoir »

Identity management is a very hard problem a lot of systems identify people by, or anchor trust to an email address, that mostly works, but has some very gnarly edges[0]. I don't think a private company can solve this (the company itself becomes a point of failure, what if they go out of business, or are acquired and change line of business?)

I really wish the USPS would get into managing digital identity, or at the very least, attack the lowest of hanging fruits: assign everyone[1] an email address that won't suddenly be closed for ToS violation on a domain that won't expire in anyone's lifetime. Lost your password/authenticator? Walk into a post office with your government issued identity.

Cleverer people than I am should be able to figure out how to create anonymous identities from your official one and have them linked unidirectionally, i.e. Alice can voluntarily prove she owns/created the Alana identity, but it's otherwise computationally impossible/expensive to do the reverse (unmask Alice from just the Alana pseudo ID)

0. Losing access to a mailbox means losing access to account recovery functionality, and mailbox takeovers result in TFA.

1. This is US-centric, but hopefully an international standard may be set, so that governments or delegated authorities are responsible for basic online identity; just like the way TLD's are managed

Re: Compromising Angular via expired NPM publisher email domains

#78

Post by tjoff »

burrows wrote: post #63
tjoff wrote: post #61

Earlier quoted context omitted.

Having your own domain shoulders you from google or any other mail provider. Surely that is vastly better.

We can do a risk profile for an email with a custom domain versus a gmail domain. Do we need to differentiate between custom email domain with self-hosted mail server and custom email domain with gmail? If I self-host the mail server then I’ll have a machine running on digital ocean or ec2 and this machine will accept connections from the Internet. I think this machine should be included in the assessment. So now the…

That is like a fraction of a fraction of a fraction of people with own domains.

I don't think that's relevant, at all.

Re: Compromising Angular via expired NPM publisher email domains

#79

Post by lrem »

techsupporter wrote: post #67
lrem wrote: post #64

Earlier quoted context omitted.

I also have a personal domain that's nearing 20 years of being online. Today qt.io refused registering an account because they didn't like said domain. I refuse to use another one. Despite already having written a repro and found where is the bug in their code. What have we come to?

> Today qt.io refused registering an account because they didn't like said domain. Did their form say what wasn't liked about your domain? I'm curious because I remember a time, you may as well, when lots of account forms only accepted domains from known residential ISPs and would try to guess domains used by freemail providers. These days, I'm curious why a group like QT would care.

Nope, the error message stated only that I can't open an account with this domain.

Re: Compromising Angular via expired NPM publisher email domains

#80

Post by burrows »

tjoff wrote: post #78
burrows wrote: post #63

Earlier quoted context omitted.

We can do a risk profile for an email with a custom domain versus a gmail domain. Do we need to differentiate between custom email domain with self-hosted mail server and custom email domain with gmail? If I self-host the mail server then I’ll have a machine running on digital ocean or ec2 and this machine will accept connections from the Internet. I think this machine should be included in the assessment. So now the…

That is like a fraction of a fraction of a fraction of people with own domains. I don't think that's relevant, at all.

Could you please clarify your point? I don’t understand the comment as is.
Post reply on HN