3 ms·

Seems a bit janky to only require 2FA from “critical projects” and not all projects. Why cut corners?

by adfm 4y ago

woodruffw 4y ago
There are many weights involved; PyPI is trying to strike a balance between them. Among them: * Project installs follow a power law distribution: the top 1% of packages account for 99% of installations, and the remaining 99% account for roughly 1% of installations. In other words: prioritizing the security of the 1% of packagers means prioritizing the 99% of users who depend on those critical projects. * PyPI has tried really hard to make 2FA as effortless and non-invasive as possible: the current program includes giving away two free physical hardware tokens, as well as a long grace period to ensure that maintainers are not caught in a sudden lurch between their open source and professional obligations. Both of these don't work at scale: PyPI doesn't have the material resources to give every maintainer free hardware tokens, and the same packaging power law means that a large number of relatively inactive maintainers will be caught by any deadline that gets set. Ultimately, the goal is to maximize the number of users protected, maximize the quality of protection, prevent package user disruption, and minimize maintainer disruption. The current scheme, in my view, does a good job at achieving all of these goals. FD: I worked on PyPI's 2FA implementation, but I do not represent PyPI and am not a maintainer.
- woodruffw 4y ago
  I forgot to mention another weight: maintainer time. A universal 2FA mandate would drastically increase the amount of support time maintainers spend helping users recover their accounts (a perverse problem to have!).
xorcist 4y ago
The weird bit is that quality control is so completely out of the question that it's not even mentioned, but authentication is seen as more important than anything else. I wonder how accurate that threat model really is. I mean, node-ipc would have happened regardless of how many authentication factors were involved in uploading. And offers to buy ownership will keep coming. What happened to Sourceforge wasn't lack of security. Turns out those distribution people did more than just wrap software in other formats. Turns out that multi stakeholder thing had merit. Who would have thought?
- woodruffw 4y ago
  Quality control isn't out of the question, per se: it's part of a different threat model. The goal behind 2FA is to limit the latent threat of account takeover attempts, which increases as packages' criticality does. Quality control belongs more closely to the "integrity" category of threats, which is much broader in scope than account takeover. It's something that we're thinking about as part of designing additional security schemes for PyPI; you can follow some of that work under the PEP 480 and PEP 458 umbrellas.
  - xorcist 4y ago
    You are likely completely right. It's just that tiny detail that there's an elephant in the room.
rsync 4y ago
"Seems a bit janky to only require 2FA from “critical projects” and not all projects. Why cut corners?" Agreed. I don't know if these projects need 2FA "protection" or not - but I'm quite certain that the risk to any particular user is identical whether they are downloading a popular vs. unpopular package. Total, global risk is, of course, higher for popular packages, but any individual user does not care if their intrusion vector was a popular vs. unpopular package ...

Seems a bit janky to only require 2FA from “critical projects” and not all projects. Why cut corners?

by adfm 4y ago

Seems a bit janky to only require 2FA from “critical projects” and not all projects. Why cut corners?

There are many weights involved; PyPI is trying to strike a balance between them. Among them: * Project installs follow a power law distribution: the top 1% of packages account for 99% of installations, and the remaining 99% account for roughly 1% of installations. In other words: prioritizing the security of the 1% of packagers means prioritizing the 99% of users who depend on those critical projects. * PyPI has tried really hard to make 2FA as effortless and non-invasive as possible: the current program includes giving away two free physical hardware tokens, as well as a long grace period to ensure that maintainers are not caught in a sudden lurch between their open source and professional obligations. Both of these don't work at scale: PyPI doesn't have the material resources to give every maintainer free hardware tokens, and the same packaging power law means that a large number of relatively inactive maintainers will be caught by any deadline that gets set. Ultimately, the goal is to maximize the number of users protected, maximize the quality of protection, prevent package user disruption, and minimize maintainer disruption. The current scheme, in my view, does a good job at achieving all of these goals. FD: I worked on PyPI's 2FA implementation, but I do not represent PyPI and am not a maintainer.

woodruffw 4y ago
I forgot to mention another weight: maintainer time. A universal 2FA mandate would drastically increase the amount of support time maintainers spend helping users recover their accounts (a perverse problem to have!).

xorcist 4y ago

The weird bit is that quality control is so completely out of the question that it's not even mentioned, but authentication is seen as more important than anything else. I wonder how accurate that threat model really is. I mean, node-ipc would have happened regardless of how many authentication factors were involved in uploading. And offers to buy ownership will keep coming. What happened to Sourceforge wasn't lack of security. Turns out those distribution people did more than just wrap software in other formats. Turns out that multi stakeholder thing had merit. Who would have thought?

woodruffw 4y ago
Quality control isn't out of the question, per se: it's part of a different threat model. The goal behind 2FA is to limit the latent threat of account takeover attempts, which increases as packages' criticality does. Quality control belongs more closely to the "integrity" category of threats, which is much broader in scope than account takeover. It's something that we're thinking about as part of designing additional security schemes for PyPI; you can follow some of that work under the PEP 480 and PEP 458 umbrellas.
- xorcist 4y ago
  You are likely completely right. It's just that tiny detail that there's an elephant in the room.

rsync 4y ago

"Seems a bit janky to only require 2FA from “critical projects” and not all projects. Why cut corners?" Agreed. I don't know if these projects need 2FA "protection" or not - but I'm quite certain that the risk to any particular user is identical whether they are downloading a popular vs. unpopular package. Total, global risk is, of course, higher for popular packages, but any individual user does not care if their intrusion vector was a popular vs. unpopular package ...