Require API Tokens for upload if 2FA is enabled

[ewdurbin]

This completes our roll out of 2FA and API Tokens.

Currently, uploads can be authenticated by either Basic Authentication or API Tokens. Our Basic Authentication mechanism works regardless of if 2FA is enabled for the account.

This change (lacking tests etc...) would enforce: 3e97e29

We'd need to notify all users with 2FA enabled about the change and a timeline for enforcement.

Some open questions:

• Should new 2FA enrollments enforce this ASAP?
• What kind of timeline would we want to have from notification to enforcement?
• How does this impact our flow for 2FA provisioning?
• How might this impact adoption for users? Might some with many projects just disable 2FA rather than deal with provisioning/rotating credentials?

[di]

Notification is implemented in #10836, just need to actually prevent it.

[di]

Giving this a 6 month notification window means we will start requiring API tokens on or after Aug 25th, 2022.

[Julian]

Hello friends. A minor concern I wanted to mention which I get reminded of whenever I create a new package is #6378 (or the closely related #6396 and #11296). Specifically I just got one of these notification emails because I was extra lazy while creating a new package and didn't even create a temporary user-scoped token, I just used my password for an initial upload. But I don't really maintain any long lived non-project scoped API tokens, every one I create is scoped just to upload the project it's specifically for, and I essentially then never need any more powerful credential to live other than my password.

Perhaps it's worth considering holding off on making this a hard requirement until that other feature is implemented for first-upload API tokens? Not doing so seems to me like it'd cause some to start maintaining a second long-lived credential (the user-scoped API token) whose only function is to be available for first uploads so I can go create a project-scoped one.

Just a minor inconvenience though, so perhaps not enough to outweigh the concern for other use cases, but figured I'd mention that to me these seem like they may be related.

[takluyver]

Could I request that an API to create tokens (#6396) be set up in connection with this policy?

I accept I'm probably something of an outlier in terms of how many different projects I upload, but I think once you're getting beyond ~5 projects, manually creating and managing tokens for individual projects is a pain. I could use the user-scoped upload token, but this doesn't seem much better than a password-only workflow - if it leaked, an attacker could upload a new version of any package that I can.

The workflow that I envisage is that the first time I publish a new project, I have to manually enter 2FA credentials (either in the terminal, or in the browser in an oauth-style workflow). Then as part of that, the local tool can create and store a project-scoped token which I can use for future updates.

Depending on how sensitive the project in question is, I might choose not to store the token at all, or to store tokens with a finite lifetime. In either case, it will be important to be able to generate tokens quickly and easily - not clicking around a web form and copy-pasting the token.

[dstufft]

Depending on what you're doing, you can create a user scoped token, and then locally attenuate that to restrict it further to only support specific projects.

[takluyver]

That's a good point, but I'd still need to store the user-scoped token locally, which I'd like to avoid. I'd guess that persistent local storage is a greater risk than sending the token back to PyPI over HTTPS.

[dstufft]

Yea to be clear, I'm not opposed to the API, just mentioning it as a possibility incase it either solves the problem for you or provides an interim solution that's better than the status quo.

[takluyver]

Thanks! 🙂 If this requirement is introduced without any new API possibilities, I'll probably just use the user scoped token in basically the same way as the password, although that doesn't really seem much of an improvement in practice.