-1 to this. while 2FA is a no-brainer for most of us, publicly listing (or showing status) not only encroaches individual liberty to make a choice, it would open such users to be targets of an attack. Enforcing 2FA in an organization seems more appropriate. Perhaps npmjs.com has implemented that since last I looked, but I know in the past that enforcement was not available.

I also greatly dislike the trend of public "shaming" that's so prevalent today. The internet has made us cruel.

> -1 to this. while 2FA is a no-brainer for most of us, publicly listing (or showing status) not only encroaches individual liberty to make a choice, it would open such users to be targets of an attack.

Saying that you refuse to enable 2FA is the information security equivalent of saying you refuse to wear a condom.

Of course people are free to make their own choices but I personally wouldn't take anyone who publishes software seriously if it's not enabled. This isn't like securing access to a social media or shopping account. The ramifications of a breach can quickly cascade and 2FA is low hanging fruit to stop a lot of that. It's far from perfect but it goes a long way.

> Enforcing 2FA in an organization seems more appropriate. Perhaps npmjs.com has implemented that since last I looked, but I know in the past that enforcement was not available.

The nested nature of dependencies makes partial enforcement pointless: A (2FA) > B (2FA) > C (2FA) > D (no 2FA!)

> I also greatly dislike the trend of public "shaming" that's so prevalent today. The internet has made us cruel.

I wholeheartedly agree with you on both points and, outside of security, I can't think of any other example where I'd be open to it.

I like to think I hold myself and people in our own industry to higher standards than the Internet at large.

I, too, greatly dislike the cruelty of public shaming. It's inhumane, and dehumanizes us all.

Recently I was tasked with improving 2FA usage in my company's GitHub organization. My first approach was to nicely, neatly, and personably ask people, coupled with regular announcements to make sure everyone knew. Every interaction came with documentation on how to do it and a sincere offer to walk them through it. Totally reasonable approach, executed with kindness and compassion.

The cynic in me was unsurprised when this rapidly became a Sisyphean task. A number of people, upon faced with being informed in half a dozen different ways, professed to have no idea that they were expected to enable 2FA. Others swore up and down to me that they knew what to do and would shortable enable it, only for it to still be off a week or more later.

At this point I decided that kindness and human compassion were a drain on my time and clearly ineffectual. So I grabbed a junior engineer and we wrote a script that automatically removes from the org anyone who doesn't have 2FA enabled. Announced it to everyone, every manager on board, and turned it on. Overnight, the problem went away, and has largely stayed away. Once in a while people publicly ask why they were kicked out and are reminded that they were informed of the 2FA requirement.

This isn't an approach characterized by humanity and kindness. It is, however, one that is effective and time-efficient.

Why did you need to write a script? GitHub allows you to enforce 2FA at the organisation level.

https://help.github.com/articles/requiring-two-factor-authen...

You're absolutely right! GitHub does offer that wonderful feature.

There are some legacy bot accounts that we cannot readily tradition to 2FA and we cannot do without. The feature you have so rightly pointed to would evict them from the org. That's not an acceptable outcome in this case.

I skipped over this in my previous comment because I felt it wasn't germane to the story or the point.

Indeed, why would we want to use packages from people who can't be bothered to use 2FA?

I hope you also publicly shame services that only offer 2FA in exchange for your phone number.

My phone number identifies me much better than my email address and/or cookies ever will. As someone who cares about privacy, I don't give it to anyone. And yet, publicly shaming me for not enabling 2FA would shame me by proxy for caring about privacy.

Security > Privacy, and there are plenty of ways to get static burner phone numbers for a small fee if privacy is that important to you. (Skype, Google Voice, Burner Phone, etc)

> Explicit whitelisting for network access. > Explicit whitelisting for fs access.

Would you (or anyone else reading this) be interested in exploring what that would look like for Node.js?

(If you do, feel free to reach me at my email in https://github.com/nodejs/node under benjamingr)

I think it would be interesting - one solution could be a loader (ESM) that only lets you load other "unprivileged" files by default - then importing things like `child_process` or `fs` could require more privilege. A little like how apps work.

> A programmatic way to tell if the publisher of a module has 2FA enabled.

I will bring this up. Personally I think I understand the objection of the reply below about this information being risky. That's something NPM likely can/should solve and not Node.js.

For what it's worth GitHub orgs can already tell who has or doesn't have 2FA. Node.js itself for example enforces GitHub 2FA for all the organization. I assume GitLab has a similar feature.

+1 to this. I hadn't heard the suggestion of making 2FA use public before, but I really like the idea.