Support TOTP authentication

[fergusq]

Is there an existing issue for this?

• [X] I have searched the existing issues (open and closed), and could not find an existing issue

What keywords did you use to search existing issues?

totp token authentication

Please describe the problem you are attempting to solve with this request

Currently, twine requires PyPI API tokens for uploading. This workflow is really cumbersome. For security reasons, I cannot store the API tokens on my computer. Every time I want to upload a package to PyPI, I must log into the PyPI website using TOTP, create a temporary API token, copy it to twine, and remove the API token.

How do you think we should solve this?

Could you directly support TOTP authentication, i.e. prompt the user for PyPI username and password and the TOTP code? You could request a temporary API token and remove it automatically. This would drastically simplify my workflow.

Anything else you'd like to mention?

It is really difficult to find information about the PyPI API, so I'm not sure how easy this is to implement.

[sigmavirus24]

I'm 99% certain this isn't possible today. Is that accurate @woodruffw ?

[woodruffw]

I'm 99% certain this isn't possible today. Is that accurate @woodruffw ?

Indeed! It's also not planned: PyPI encourages people to use Trusted Publishing if they're publishing from a supported CI/CD provider, or a manually configured API token otherwise.

@fergusq could you say more about the "security reasons" here? To a first approximation, I think repeatedly logging into PyPI and creating temporary tokens is much more brittle from a security perspective than creating a single token and storing it somewhere safe, like an encrypted password manager.

[fergusq]

I have a "travel computer" I use that I don't want to contain any secrets in case it gets stolen. Even though I can use an encrypted password manager, I'd prefer not to store any secrets at all, even encrypted.

I don't really understand the point of tokens: they are just like passwords, hard-coded permanent secret strings that must be stored somewhere. The official documentation suggest storing it unencrypted in a plain text file. This seems very insecure. While encrypting them helps, requiring permanent tokens still seems like a step backwards to me. I would prefer to do two-factor authentication instead.

[sigmavirus24]

So it seems as if you've done 0 research into how tokens are implemented for PyPI and you're making a feelings based assertion with no evidence of the comparative security they offer. It also sounds like this is to support or counteract a fear of someone stealing your travel laptop in order to infect the supply chain of some other projects or products using what you place on PyPI. In that case, this feels relevant.

As for the value of tokens, unlike your password+ 2fa, they can be scoped to a single project. They can be significantly more fine grained than what you're asking for. They also are something that can be revoked (if I remember correctly) by PyPI when there appears to be misuse or suspicious use. Suspending your account as a whole would be far more disruptive than preventing malicious behavior via revoking a token. It's also something far easier for you to do if you did have your laptop stolen before anything could be done. Tokens are far less privileged than your account password and 2fa. Thus they provide a way of doing things with the least privileges possible - a definitive and proven security benefit.

[woodruffw]

I have a "travel computer" I use that I don't want to contain any secrets in case it gets stolen. Even though I can use an encrypted password manager, I'd prefer not to store any secrets at all, even encrypted.

In that case, you should probably use Trusted Publishing, if you can. The upload API isn't currently equipped to handle any kind of MFA and probably won't be extended to support it in the near future, since API tokens are intended to be scoped bearer credentials, i.e. they're not capable of creating sessions or doing account management things that MFA is intended to secure.

I don't really understand the point of tokens: they are just like passwords, hard-coded permanent secret strings that must be stored somewhere. The official documentation suggest storing it unencrypted in a plain text file. This seems very insecure. While encrypting them helps, requiring permanent tokens still seems like a step backwards to me. I would prefer to do two-factor authentication instead.

There are a lot of online resources on this, but to summarize: tokens are:

1. Unique: tokens are random credentials, meaning different services can't be configured to use the same token value. In practice, this means that a compromise of credentials on service A can't be pivoted to a compromise of service B.
2. Scopeable: a user/pass combination has accent to all user projects, as well as the user's own settings. That makes it an extremely powerful default credential to use everywhere, and it means that user/pass combinations don't adhere to the "principle of least authority."
3. Mechanically auditable and revokable: When given a prefix or other identifiable structure (like PyPI's tokens are), tokens can be scanned for and automatically revoked upon public disclosure, unlike passwords GitHub's "secret scanning" feature is a good example of that, and PyPI integrates with it to prevent accidental token disclosures from remaining exploitable.

[fergusq]

So it seems as if you've done 0 research into how tokens are implemented for PyPI and you're making a feelings based assertion with no evidence of the comparative security they offer.

There is no reason to be rude about it.

People have different use cases. While tokens indeed to provide benefits in some situations, they lack some benefits on two-factor authentication. I do understand that some people value other benefits over others. It seems to me that none of the benefits you listed address the issues I had with tokens. They are benefits over passwords, yes, but not over multi-factor authentication, which was what I was asking.

[sigmavirus24]

You are expressing preferences and feelings, not facts or evidence to support those feelings. William has explained the value proposition of tokens. You're still allowed your preferences but that doesn't mean that this will change anything in how PyPI or other software indexes working on providing similar levels of security will function. No one can make you change your preferences but your preferences do not get to undermine other's security. And you're right, my frustration came through because this is not an issue with this project, nor is it one I think has merit even on the correct project. So in light of that, I'm closing this and turning off notifications so you can continue to express your feelings without my involvement.