Thousands of Npm Accounts Use Email Addresses With Expired Domains (therecord.media) 35
An academic research project found that thousands of JavaScript developers are using an email address with an expired domain for their npm accounts, leaving their projects exposed to easy hijacks. From a report: The study, performed last year by researchers from Microsoft and North Caroline State University, analyzed the metadata of 1,630,101 libraries uploaded on Node Package Manager (npm), the de-facto repository for JavaScript libraries and the largest package repository on the internet. Researchers said they found that 2,818 project maintainers were still using an email address for their accounts that had an expired domain, some of which they found on sale on sites like GoDaddy. The team argued that attackers could buy these domains, re-register the maintainer's address on their own email servers, and then reset the maintainer's account password and take over his npm packages.
why are people still using node?!? (Score:1)
Re: why are people still using node?!? (Score:2)
Re: (Score:2)
Because a huge amount of code has been written in it. Thus it will be with us for decades (at minimum) to come.
Re: (Score:3)
And because people are lazy or have no idea how to write that function themselves (yes, maybe lots of work).
Yet another reason to use NoScript :)
Re: (Score:2)
You can at least run node js from cobol... ugh the thought..
Re: (Score:2)
Why wouldn't they?
Is username email address? (Score:2)
Is username the email address on npm? (I have never been there).
Using email address as username to login has always been stupid for this very reason; what happens when somebody's email address changes?
Re: (Score:3)
You change it.
The purpose of your user name is to uniquely identify you. Your e-mail address uniquely identifies you. In fact, that's it's original purpose.
Re: (Score:2)
Using email address as username to login has always been stupid
Yes and no. An email ID is easy to remember. Authentication is (should be) via a password or other means. As long as the system one is logging into doesn't attempt any kind of authentication using the e-mail address, it doesn't matter if it's expired. Just don't forget your password.
Re:Is username email address? (Score:4, Informative)
But...
If you have MikeyDees@healthfood.com and you register lots of accounts with that.
Then you let the domain expire.
I pick up the domain and re-activate MikeyDees@healthfood.com
Now I go to the websites and say, "hey, I forgot my password" and then I get an email with a token, link, password in cleartext...whatever.
You just took over the account, even in the original owner still remembers their password.
Re: Is username email address? (Score:4, Insightful)
That problem doesn't go away with non-email usernames. As long as the password reset process is by email, the accounts are vulnerable to an expired domain attack.
This is a problem without a straightforward solution.
Re: (Score:2)
Well see that is actually the problem isn't it - it uniquely identifies you temporally
user@domain works until someone else is assigned to that user at that domain. Kind of like:
Occupant
123 Main St
Springfield, NA 11123
Might uniquely identify someone for a while, until it identifies someone else. Lots of sights do authenticate people by e-mail address.. That is how password reset, works on almost all of them! Its how MFA recovery works for almost all of them. Not that solutions don't exist but most of them
Re: (Score:2)
The problem is regardless if the account is separate or your email address, the fact remains that 'recover my password' is pretty much going to be email.
The answer would be for accounts to have a displayname and the email address is kept secret. A lot of sites do this better by having the email be private and even the password reset link feedback omitting the email address, or redacting it so that if you know you can tell but a third-party could not figure it out.
Would not be an issue with end-to-end encryption (Score:2)
Identify the account by email address and public key. Any mail sent to the address is encrypted and can't be read by anyone but the original author.
The problem is far more pervasive than just code repositories. Are you sure you've cancelled every account before you gave up an email address that you used to register these accounts? It also happens with phone numbers: Since every web site under the sun apparently needs to be able to call you and send you SMS in case you forget your password, anyone who "inher
Re: (Score:3)
Problem is "I lost my keypair, I need to recover". It becomes impractical to forever bind with no backup to access an account.
The fact they could see and check email addresses to do this study is the main problem. No one other than the account holder should be able to see email addresses of the maintainers. Unfortunately, npm and pypi fail by showing email addresses of all module owners. They should abstract away, with a displayname@npmjs.com email address that gets forwarded to the correct address for
Re: (Score:2)
You could very easily have multiple keys associated with an account, so that you can put one in a safe, possibly in a sealed envelope stored at a trusted friend's house. The remaining situations where someone has lost access to all keys could force a manual identity check, which would include looking at domain ownership changes.
Re: (Score:2)
There's what *can* a careful user do, and then the practical reality of how people will curse your name if you require them to register a bunch of keys or else risk suffering a 'manual check'.
Either way, masking the author of a module on the module registries seems like an easy low hanging fruit to severely mitigate this opportunity.
Re: (Score:2)
If people regularly used end to end encryption with email, it wouldn't be a separate step to also use it to guard against lapsed email addresses being used to hijack accounts. The fact that email is still sent in the clear is an anachronism that needs to be changed. It would also help with this problem, even though it would just be a side effect.
I guess it depends (Score:3)
Re: (Score:3)
Actually, in that regard, the expired domains aren't the problems, it's the domains that *were* expired and picked up without the downloader ever knowing it was an expired domain. A package under attack in this way would have a seemingly valid domain by the time anyone could download it.
Suspend the accounts (Score:3)
This can be solved with a script on the npm server that periodically checks whether the email domain has expired, and deactivates accounts where it has. Reactivation of those accounts would require (a) logging in and changing the email to a valid one [the legit owner can do this if they remember their password] or (b) some sort of more involved process for expired domains where the owner doesn't remember their password, potentially involving security questions or identity documents. Option b would rarely be needed, fortunately.
Re: (Score:2)
Does not work. The domain may have been re-sold already when the script checks.
Re: (Score:2)
Checking once a day solves 99.99% of the problem. The overwhelming majority of hacks are going to happen on long-expired domains.
Re: (Score:2)
Come to think of it, it actually solves 100% because an expired domain is held for a month before anybody else can buy it. Plus the expiration date is a matter of public record so you can store that info to predict it in advance and don't need to keep checking domains that have far off expirations.
Re: (Score:2)
Not really - the more dangerous thread actors - read the ones most likely to be interested in using a supply chain vector to do something more nefarious than playing a practice joke or creating a little general chaos or most certainly watching domains at high frequency to snipe them with automated tools.
You can bet they have snerfed all the contact domains for every package in major repos that have a reasonable number of downloads / use statistics and are watching those domains carefully.
They are NOT obviou
"easy" (Score:2)
Wrong Problem (Score:2)
JavaScript is crap (Score:2)
And so are many JS developers. What else is new? Any competent developer would at least make sure the contact info is removed before abandoning a project.
Gee thanks (Score:2)
Typo (Score:1)
Debian (Score:2)
Another example of why primary developers should not double as maintainers in a package repository.
I figure Debian has been the gold standard for repos in the past. Does anyone else do it better?