Check for insecure maintainer accounts

[Zac-HD]

Recent research on weaknesses in the npm supply chain identified 2,818 maintainer email addresses at expired domains, affecting 8,494 packages. Such weaknesses can be mitigated by multi-factor authentication, but generally make targeted account hijacking trivially easy. PyPI could regularly check that custom domains linked to account email addresses remain registered. Similarly, PyPI could mitigate the risks of password reuse by checking for maintainer email addresses in security breaches from other sites and checking that new passwords have not already been exposed.

While I think this is unlikely to be implemented without funding, if funded it would consist of fairly-tightly-scoped backend changes, plus policy decisons to notify maintainers of possible account breaches.

More controversially we could also reject package updates from potentially-compromised accounts, or notify downstream users via the proposed general vulnerability notification mechanism. Just the technical ability to monitor for possible breaches and exposed passwords does seem like a good start, though.

[di]

Thanks for the PR! A few questions/clarifications I think we should probably resolve before merging:

PyPI could regularly check that custom domains linked to account email addresses remain registered.

How? And how would PyPI have any advantage here over an attacker that is also checking whether custom domains have not expired?

Similarly, PyPI could mitigate the risks of password reuse by checking for maintainer email addresses in security breaches from other sites and checking that new passwords have not already been exposed.

PyPI already integrates with the HIBP API: https://pypi.org/help/#compromised-password

(We also integrate with GitHub's token scanning API: https://pypi.org/help/#compromised-token)

More controversially we could also reject package updates from potentially-compromised accounts

What would constitute a "potentially-compromised account"?

[Zac-HD]

How? And how would PyPI have any advantage here over an attacker that is also checking whether custom domains have not expired?

The registration expiry date is public via whois records - for example https://www.godaddy.com/whois/results.aspx?domain=pypi.org suggests that no attacker could register pypi.org and get admin@pypi.org until 2022-07-24T15:13:23Z plus the renewal grace period of 30 days (plus). So the natural advantage is that PyPI need not wait until it's actually possible for an attacker to register the domain to take action, and could queue things up a fair way in advance.

PyPI already integrates with the HIBP API: pypi.org/help/#compromised-password

🎉 That's what I get for writing up proposals late after work 😅

What would constitute a "potentially-compromised account"?

I was thinking "Custom domain expired, was re-registered, followed by password reset" - plausibly in this case we just want to lock the account out entirely pending manual out-of-band verification instead of allowing the reset to go through.

[di]

Thanks! Would you be able to add some summarized version of that to the funding request?

[Zac-HD]

@di, anything else I can do to help get this merged?