Pretty much this; There are some people who believe that efforts to improve supply chain security benefits only corporate or business users, and that individual developers should not be asked to take on a uncompensated burden for their benefit.
Does it not raise the threshold required to poison the supply chain? If so, can you inform me as to why this is not a good enough solution, such that you would warrant against the inclusion of 2FA as part of the process? Furthermore, since it's an attempt to solve a known and increasing problem, what do you suggest they do to resolve the issue? This seems some pretty open-and-shut low-hanging fruit to me.
"At the expense of uploaders." Arguing against TOTP in 2023 just seems so ridiculous to me, especially for people savvy enough to publish a package on PyPI. I just don't get it.
This isn't the first time I've heard such a complaint.
So, dumping hours upon hours of work into publishing a project on PyPI is fine, but setting up TOTP is where some people draw the line? To prevent against a commonly-exploited attack vector that is so simple to mitigate?
The difference is that one type of work is something you do of your own choosing, and the other type of work is enforced and you have no control over it.
Not offering an opinion on whether it's good or bad that it's enforced, but that's the difference between the two.
TOTP is a bit of an annoyance though a pretty rare one all things considered as most sites have reasonable delays before they ask for re-authorising devices.
The biggest issue is that as the number of sites in the Authenticator grows finding them becomes more annoying.
Keys are a pain in the ass though, as their form factors usually make them impossible to keep attached to a laptop (as they snag and break if you forget to unplug them before putting the laptop in a bag), yet easy to lose if you’re not super careful.
There are low-profile keys (yubikey’s nanos) but they’re not exactly cheap, and I’ve never seen one being given out (whereas I have free keys from older programs of github and google both).
They’re all minor gripes, but they’re routine annoyances nonetheless, and as the number of sites requiring 2FA grows (rightfully so) the likelihood that you’ll meet a 2FA prompt every day closes in on 1.
And there’s a handful of sites which are really shit about it, with way too aggressive requirements and way too short sessions.
It is very easy and convenient for your password manager to handle TOTP codes too. I personally have 1Password set up to also generate the codes and they automatically fill up on the websites or copy to the clipboard on mobile devices after filling out the normal passwords
I personally looking forward to 3fa where you need another person to verify that you are not a hacker. Overall it's a sign that these sites have lost the battle.
Wait, what? I'm so confused. How is this security theatre and how is it better to have curated packages than an open ecosystem when it comes to "hostility"?
Is this an extension of the supposed NSL? Demands from USA TLAs to be able to match users to projects would seems to fit with the story as it was presented on HN (PyPI responded to a demand for all data, including use data, related to certain projects; https://news.ycombinator.com/item?id=36061407).
Could equally come from the project, looking at their past HN stories they've had a lot of problems with malicious users. ID requirements might reduce that.
In any case, this multi-year phase-in is the sort of ratcheting steps you do when you want to make a change, and it's a big change, and you don't want a flag-day migration.
hey ee just wanted to say thanks for all your work, you're doing so much for the python ecosystem. genuinely appreciate all you're doing, you're a great example for the rest of us.
> The most important things you can do to prepare are to enable 2FA for your account as soon as possible, either with a security device (preferred) or an authentication app and to switch to using either Trusted Publishers (preferred) or API tokens to upload to PyPI.
So you either need to have a mobile phone (all of the linked applications[0] seem to require an Android or iOS device) or some custom device and they prefer you to rely on some 3rd party they call "Trusted Publisher"?
Weren't private+public key signatures invented for solving pretty much this thing? They might be a bit complex for Mere Mortals but programmers should at least be able to figure them out. Am i missing something?
EDIT: seems like TOTP is indeed similar to private+public key signatures (in that there is a shared secret to check against), can be done fully locally without requiring a phone or any 3rd party service and it just happened that the applications listed on the site were all for phones.
If you delete your package, can't someone else grab the namespace?
I see that as the main issue if you want to migrate away from PyPI's management practices.
Similarly, if you don't want to deal with PyPI at all, and host your own packages, then it's all too easy for someone else to register a package of the same name on PyPI. Users aren't used to configuring an alternate server.
Very possibly, but I don't have a phone or a hardware key, and I'm certainly not going out and getting one for the benefit of PyPI, so my choices are?
Having an outdated version of my packages on a locked-out account on PyPI (with the up-to-date sdists that I distribute on my website) sounds like a nightmare.
Those can be used? That could be a way around this then, thanks -- I'll investigate (just going on @badsectoracula's comment that phone or key is required, possibly I misinterpreted that).
Still something of a PITA though (and not really a second factor).
I also don't have a smart phone or hardware key, and feel the same.
I host my packages on my own server using the PEP 503 "Simple Repository API". (For what it's worth, Donald Stufft, author of this PyPI blog post, also wrote PEP 503.)
I migrated away from PyPI years ago because modern FOSS distribution is increasingly intermediated by package managers, which I think worsens the connection between user and producer by adding a layer of anonymity.
I see 2FA as a technical work-around using mechanical trust instead of personal trust.
I don't care if people who don't know about me or my project web site can't find it on PyPI, because care is reciprocal - I want them to care about me too, at least enough to know where the project came from. That's where I think trust comes from.
My packages will never be popular. I develop very specialized software for a field with perhaps 10,000 world-wide users. No one will pay for my software, or hire my services, if they only visit PyPI.
I thankfully still have a Python 2.7 version of my software on PyPI. I haven't deleted it, to make name-squatting harder. It's even lead people to contact me directly, to ask about Python 3 support. I never would have heard from them, had I published the newest versions on PyPI, and that direct contact breaks the anonymity PyPI interposes.
A nice plus is how hosting means I have full access to the download logs, giving me insight onto what platforms people use that PyPI doesn't provide, because "anonymity".
The biggest annoyance is they main reason I started using PyPI was because someone else added another project of mine to PyPI.
I distributed https://pypi.org/project/PyRSS2Gen/ on my own web site as source. Someone else added it to PyPI, with me listed as the primary developer. I didn't know about it until the PyPI devs emailed developers like me to encourage them to support Python 3! I then had to ask that stranger for access to the PyPI entry.
I fear that will happen again, if I ever develop a new package that I distribute myself.
I hope this provide something for you to chew on, as you consider what you might do.
While we strive to make PyPI useful for everyone we totally understand that sometimes the trade offs we have to make just don't work for everyone so we try really hard to enable folks like yourself to be able to set up their own repositories. I'm glad that it's working out for you and that you've got a setup you like.
I do want to mention two things:
We've got a PEP (PEP 708) going through the works that will tighten the security model around multiple repositories down some more. If I understand your uses well enough you should be able to add a line or two of HTML to your repository and not have any interruptions or warnings. That PEP isn't accepted yet or implemented or anything, but something to keep in the back of your mind at least.
While we don't make any sort of raw download logs available, we do publish what is essentially a query-able database of download events that have been parsed already to make it easy to see those stats. We do have a little bit of redaction on those events, primarily to avoid leaking PII like IP addresses and such, where instead of an IP address we log broad geographical area (country I think?).
I looked at PEP 708. I was confused by what "repository" means. In PEP 503 "A repository that implements the simple API is defined by its base URL .... Within a repository, the root URL (/ for this PEP which represents the base URL) MUST be a valid HTML5 page with a single anchor element per project in the repository.".
A repository contains projects - "individual project contained within a repository".
PEP 708 seems to use "repository" to mean both that and individual project. Consider "To enable one repository to extend another, this PEP allows the extending repository to declare that it “tracks” another repository by adding the URL of the repository that it is extending."
The examples show project with new entries tracking a project on another repository.
This made it hard for me to understand what something like "repository owner" really means.
> If I understand your uses well enough you should be able to add a line or two of HTML to your repository and not have any interruptions or warnings.
Now it also contains "click" and "tqdm" entries, copied verbatim from the respective PyPI project entries, because I recently added my first required install dependencies, and -i doesn't automatically fall back to PyPI.
I use '-i' because I don't want installs to start using the old chemfp version on PyPI. (Why? I only distribute pre-compiled wheels for 'manylinux'. I didn't release Python 3.11 wheels until a few weeks ago. I don't want pip for 3.11 users, or on macOS, to find the source version and try to install them. And "We’ve spent 15+ years educating users that the ordering of repositories being specified is not meaningful, and they effectively have an undefined order." ;)
I would prefer to not maintain copies of the click and tqdm project entries, as I need to remember to refresh them.
However, the main issue I have is namesquatting is still too easy. If I started chemfp now, with no PyPI entry, then from my side nothing changes.
But I've had people do "pip install chemfp" WITHOUT the -i option then ask what why it didn't work.
I assume that's because people aren't used to using a -i (or configuring it in their requirements.txt) so aren't sensitive as to why it's important.
Namesquatting a purely non-PyPI project then comes easy - register it on PyPI. PyPI is active about namesquatting, but you all surely don't track all small non-PyPI projects.
What I would like is, I thought, pretty simple:
python -m pip install chemfp.com:/package/chemfp/
with the ability to also specify a path like that in the requirements.
That's considered in PEP 708 as possible ("To my knowledge the only systems that have managed to do this end up piggybacking off of the domain system and refer to packages by URLs with domains etc") but rejected ("our ability to retrofit that into our decades old system is practically zero without burning it all to the ground and starting over" ... "This would upend so many core assumptions ...")
This means while some of my current issues will be assuaged with this PEP, my fundamental concern will not.
Not at all, you can use any TOTP app and the list does include desktop options. I like https://authy.com/ , from Twilio, and use it both on my desktop and phone. I've started using it to enable TOTP backup/syncing, and I've been using it for PyPI 2FA for years now.
Or you can implement your own, TOTP is not complicated. Here's a Python library that does the heavy lifting for you: https://github.com/pyauth/pyotp .
The parent was complaining about needing "either [...] a mobile phone [...] or some custom device", which is not true. And sure, Authy is a third-party; but it's not the only option, and you can implement your own (TOTP is not that complicated).
And TOTP has much better user experience than raw keys, especially for beginners who might mix the public/private parts, and experts who want hardware protection.
Actually my main concern is the reliance on 3rd parties - requiring a mobile phone is an implicit reliance on a lot of 3rd parties that IMO should not have any business where/how i authenticate myself.
I don't know about TOTP but if it can be completely independent from 3rd parties and can be used locally like private+public key signatures can then i guess it is fine.
You can implement TOTP in a few lines of code; it's pretty straightforward and there's many CLI and desktop apps, plugins for (desktop) password managers, etc.
For some reason many sites seem to pretend it's a phone- or special device only thing. In principle it's more secure, but if you also have a password manager on your phone – as many people do – then it's not really.
Does TOTP rely on some external service though or can it be done fully locally? AFAIK a benefit of private+public key signatures is that it can all be done without reliance on 3rd parties.
Thanks, i took a look in the page and it looks quite simple. One question i have would be that it mentions:
> TOTP credentials are also based on a shared secret known to both the client and the server
AFAICT this "shared secret" is something that is shared between the service you want to authenticate with (e.g. PyPI) and "you" (your password manager, TOTP client or whatever), right?
In which case i guess this sounds something like it can be done fully locally indeed.
I did use Authy once for a service i used for a bit but it required me to put my phone online every time[0] i tried to authenticate because otherwise the authentication would fail, so the association Authy=TOTP made me think a reliance on a 3rd party service is required and the page mentioning only mobile phone apps also made me think there is also some sort of reliance on mobile phones.
[0] I have a very old Android phone that i always keep offline
No third parties are involved. You get a secret (often presented in the form of a QR code, but most implementations also have it as text) which you store and generate short-lived secret messages based on that and the current time, which is the code you enter. The server also knows the secret and can verify you sent the correct message. That's pretty much all there is to it.
It's really simple; I once wrote an implementation in Python in 20 lines or so based on just the specification, and I'm not a crypto guy at all. It's probably the simplest crypto systems to implement. Things like "connect your authentication app" make it sound complicated, but all that does is store a short secret in the app.
One clear advantage of this is that a code is only valid for a short period of time (usually a few minutes at the most). I can't re-use the code you used yesterday, and intercepting codes is also much harder as it's much more time-sensitive.
Yeah, the more i read about it the better it sounds and the more it seems that i had a misunderstanding about it. Perhaps i'll try implementing it once to see exactly what it is.
Sibling posts have pretty much answered it already. If you want to really overgeneralize it, it blew my mind a mere few weeks ago when I finally came to the realization after all these years that TOTP is nothing more than an initial seed value, as one half, combined with the current time as the other seed half.
I had a huge jackie chan meme moment at that point.
Then I realized that, all along, my password manager has a feature to store TOTP, and there is not even a strict need to use all these authenticator apps. (Of course, as someone who strives to exercise some security mindfulness, I reckon it undermines much of the overall point of TOTP to keep it within the same datastore as your account password.)
I'm using https://github.com/Spomky-Labs/otphp to generate in a PHP Backend automatically TOTPs. Something similiar is probably also available for Python/Javascript/etc.
TOTP is effectively a cryptographic hash(shared-secret, time) producing 6 decimal digits where time gets incremented every 30s. The server accepts the token if it's recent enough.
Many desktop password managers have built in support (e.g. keepass2).
TOTP is a good choice, and helps a lot on keeping everyone's account safe! Thanks a lot for taking the time to investigate your options
I do feel want to mention though (largely because I think it's pretty cool), that those security devices are using a private/public key system under the covers, and they're actually designed to be privacy friendly and phishing resistant. One of the problems with TOTP based 2FA is that since it's asking users to type the TOTP code into the website, they can be phished and tricked into typing their password and TOTP code into an attacker's website, who then quickly go and use it to sign onto their account.
Those hardware tokens prevent that phishing from happening. They basically create, on the fly, a public/private key pair that is bound to the domain name of the site in question, and then give the public key of that to the site. When you come back to log in again, the site tells the hardware token what public key it has, the token looks a the site's domain and determines if it has that key for that domain, and if it does it uses a signature to prove ownership of the private key.
It all ends up working really well, since the domain name (actually the protocol, domain name, and port) is part of the identify of the key pair, it is impossible for it to get entered on the wrong site, so it completely eliminates phishing. Then since every single site gets it's own brand new keypair generated for it, there's no way to determine that the hardware token used on Site A is the same as the hardware token used on Site B. So it's entirely privacy preserving as well!
The protocol is obviously a bit more complicated then that, but that's the general idea of it.
You can share the TOTP seed with colleagues (securely), and then enter it manually in your respective authentication apps. Or use an online password manager, as the other comment suggests.
You can have multiple accounts associated with a single project, so each person can have their own account and you just add them all as owners to the projects.
That can be annoying to keep in sync if you have a lot of projects, but we're rolling out organization support to make that easier for people.
At some point surely people will realize that forcing the vast majority of people to be either an Apple customer or, worse, a Google product is not a viable design?
Current day mobile devices, infested as they are with the dubious morality and regulatory malpractices that engineered the duopoly are horrible as digital identity providers and 2FA.
2FA is a function that is becoming essential for anybody that wants to participate in a digital life. A widely available and easy to use alternative is not a good to have it is absolutely essential.
The implications of how 2FA is implemented go far beyond lovely PyPI. Entities like banks are deprecating specialized hardware in favor of the mobile. This is insane and odious.
TOTP is not tied to Google, Apple, or mobile phones in any way. It's an open specification and easy to understand and implement by anyone with even fairly junior skills.
Some 2FA systems do require some specialized mobile app, but this is not one of them.
I, for one, really appreciate this move. Supply chain attacks are huge problem, and package repositories are especially at risk. The options provided are very reasonable, and supporting TOTP ensures that even the most hardcore privacy and free-software enthusiasts are included.
As a consumer and maintainer myself, PyPI has had a fair share of issues, but this is definitely not one of them.
87 comments
[ 2.6 ms ] story [ 161 ms ] threadI use 2FA on many of my accounts, and it's not that bad if you're only being prompted for it once a week or so.
"At the expense of uploaders." Arguing against TOTP in 2023 just seems so ridiculous to me, especially for people savvy enough to publish a package on PyPI. I just don't get it.
So, dumping hours upon hours of work into publishing a project on PyPI is fine, but setting up TOTP is where some people draw the line? To prevent against a commonly-exploited attack vector that is so simple to mitigate?
Like... Really?
Not offering an opinion on whether it's good or bad that it's enforced, but that's the difference between the two.
The biggest issue is that as the number of sites in the Authenticator grows finding them becomes more annoying.
Keys are a pain in the ass though, as their form factors usually make them impossible to keep attached to a laptop (as they snag and break if you forget to unplug them before putting the laptop in a bag), yet easy to lose if you’re not super careful.
There are low-profile keys (yubikey’s nanos) but they’re not exactly cheap, and I’ve never seen one being given out (whereas I have free keys from older programs of github and google both).
They’re all minor gripes, but they’re routine annoyances nonetheless, and as the number of sites requiring 2FA grows (rightfully so) the likelihood that you’ll meet a 2FA prompt every day closes in on 1.
And there’s a handful of sites which are really shit about it, with way too aggressive requirements and way too short sessions.
I’ve got great hopes for TPM WebAuthn.
I presume package authors are likely to be rather better informed than this?
https://nakedsecurity.sophos.com/2017/07/11/two-factor-via-y...
This is not what 2FA solve
> Someone should offer Homebrew for Python
Ah yes the package manager that updates several unrelated packages every time you install anything and doesn't allow rollbacks right?
You're not even wrong
It's really annoying that it's doing it by default. To avoid this, add this to your `.bash_profile` / `.zshrc` / etc:
export HOMEBREW_NO_AUTO_UPDATE=1
Are you going to pay for people to manually curate the entire python ecosystem?
Could equally come from the project, looking at their past HN stories they've had a lot of problems with malicious users. ID requirements might reduce that.
In any case, this multi-year phase-in is the sort of ratcheting steps you do when you want to make a change, and it's a big change, and you don't want a flag-day migration.
Or, if you don't like it, you use the boiling frog apologue - https://en.wikipedia.org/wiki/Boiling_frog .
I'm not doing anything for the Python ecosystem. I'm a Python developer, not part of core dev, PyPI, Python packaging, or anything ecosystem related.
This allows you to lose your phone without losing your account.
>
> The most important things you can do to prepare are to enable 2FA for your account as soon as possible, either with a security device (preferred) or an authentication app and to switch to using either Trusted Publishers (preferred) or API tokens to upload to PyPI.
So you either need to have a mobile phone (all of the linked applications[0] seem to require an Android or iOS device) or some custom device and they prefer you to rely on some 3rd party they call "Trusted Publisher"?
Weren't private+public key signatures invented for solving pretty much this thing? They might be a bit complex for Mere Mortals but programmers should at least be able to figure them out. Am i missing something?
EDIT: seems like TOTP is indeed similar to private+public key signatures (in that there is a shared secret to check against), can be done fully locally without requiring a phone or any 3rd party service and it just happened that the applications listed on the site were all for phones.
[0] https://pypi.org/help/#totp
I see that as the main issue if you want to migrate away from PyPI's management practices.
Similarly, if you don't want to deal with PyPI at all, and host your own packages, then it's all too easy for someone else to register a package of the same name on PyPI. Users aren't used to configuring an alternate server.
Having an outdated version of my packages on a locked-out account on PyPI (with the up-to-date sdists that I distribute on my website) sounds like a nightmare.
Still something of a PITA though (and not really a second factor).
I host my packages on my own server using the PEP 503 "Simple Repository API". (For what it's worth, Donald Stufft, author of this PyPI blog post, also wrote PEP 503.)
I migrated away from PyPI years ago because modern FOSS distribution is increasingly intermediated by package managers, which I think worsens the connection between user and producer by adding a layer of anonymity.
I see 2FA as a technical work-around using mechanical trust instead of personal trust.
I don't care if people who don't know about me or my project web site can't find it on PyPI, because care is reciprocal - I want them to care about me too, at least enough to know where the project came from. That's where I think trust comes from.
My packages will never be popular. I develop very specialized software for a field with perhaps 10,000 world-wide users. No one will pay for my software, or hire my services, if they only visit PyPI.
I thankfully still have a Python 2.7 version of my software on PyPI. I haven't deleted it, to make name-squatting harder. It's even lead people to contact me directly, to ask about Python 3 support. I never would have heard from them, had I published the newest versions on PyPI, and that direct contact breaks the anonymity PyPI interposes.
A nice plus is how hosting means I have full access to the download logs, giving me insight onto what platforms people use that PyPI doesn't provide, because "anonymity".
The biggest annoyance is they main reason I started using PyPI was because someone else added another project of mine to PyPI.
I distributed https://pypi.org/project/PyRSS2Gen/ on my own web site as source. Someone else added it to PyPI, with me listed as the primary developer. I didn't know about it until the PyPI devs emailed developers like me to encourage them to support Python 3! I then had to ask that stranger for access to the PyPI entry.
I fear that will happen again, if I ever develop a new package that I distribute myself.
I hope this provide something for you to chew on, as you consider what you might do.
While we strive to make PyPI useful for everyone we totally understand that sometimes the trade offs we have to make just don't work for everyone so we try really hard to enable folks like yourself to be able to set up their own repositories. I'm glad that it's working out for you and that you've got a setup you like.
I do want to mention two things:
We've got a PEP (PEP 708) going through the works that will tighten the security model around multiple repositories down some more. If I understand your uses well enough you should be able to add a line or two of HTML to your repository and not have any interruptions or warnings. That PEP isn't accepted yet or implemented or anything, but something to keep in the back of your mind at least.
While we don't make any sort of raw download logs available, we do publish what is essentially a query-able database of download events that have been parsed already to make it easy to see those stats. We do have a little bit of redaction on those events, primarily to avoid leaking PII like IP addresses and such, where instead of an IP address we log broad geographical area (country I think?).
If anyone is curious to see that, it's hosted in Google BigQuery (sorry, it does require a Google account) and there's a guide at https://packaging.python.org/en/latest/guides/analyzing-pypi... that tells you more about it.
I looked at PEP 708. I was confused by what "repository" means. In PEP 503 "A repository that implements the simple API is defined by its base URL .... Within a repository, the root URL (/ for this PEP which represents the base URL) MUST be a valid HTML5 page with a single anchor element per project in the repository.".
A repository contains projects - "individual project contained within a repository".
PEP 708 seems to use "repository" to mean both that and individual project. Consider "To enable one repository to extend another, this PEP allows the extending repository to declare that it “tracks” another repository by adding the URL of the repository that it is extending."
The examples show project with new entries tracking a project on another repository.
This made it hard for me to understand what something like "repository owner" really means.
> If I understand your uses well enough you should be able to add a line or two of HTML to your repository and not have any interruptions or warnings.
I'm not sure it works, at least, not fully.
I tell people to use:
This used to contain only one project, "chemfp".Now it also contains "click" and "tqdm" entries, copied verbatim from the respective PyPI project entries, because I recently added my first required install dependencies, and -i doesn't automatically fall back to PyPI.
I use '-i' because I don't want installs to start using the old chemfp version on PyPI. (Why? I only distribute pre-compiled wheels for 'manylinux'. I didn't release Python 3.11 wheels until a few weeks ago. I don't want pip for 3.11 users, or on macOS, to find the source version and try to install them. And "We’ve spent 15+ years educating users that the ordering of repositories being specified is not meaningful, and they effectively have an undefined order." ;)
I would prefer to not maintain copies of the click and tqdm project entries, as I need to remember to refresh them.
I think with PEP 708 I can have a single
which will fix that pain point.However, the main issue I have is namesquatting is still too easy. If I started chemfp now, with no PyPI entry, then from my side nothing changes.
But I've had people do "pip install chemfp" WITHOUT the -i option then ask what why it didn't work.
I assume that's because people aren't used to using a -i (or configuring it in their requirements.txt) so aren't sensitive as to why it's important.
Namesquatting a purely non-PyPI project then comes easy - register it on PyPI. PyPI is active about namesquatting, but you all surely don't track all small non-PyPI projects.
What I would like is, I thought, pretty simple:
with the ability to also specify a path like that in the requirements.That's considered in PEP 708 as possible ("To my knowledge the only systems that have managed to do this end up piggybacking off of the domain system and refer to packages by URLs with domains etc") but rejected ("our ability to retrofit that into our decades old system is practically zero without burning it all to the ground and starting over" ... "This would upend so many core assumptions ...")
This means while some of my current issues will be assuaged with this PEP, my fundamental concern will not.
Or you can implement your own, TOTP is not complicated. Here's a Python library that does the heavy lifting for you: https://github.com/pyauth/pyotp .
And TOTP has much better user experience than raw keys, especially for beginners who might mix the public/private parts, and experts who want hardware protection.
I don't know about TOTP but if it can be completely independent from 3rd parties and can be used locally like private+public key signatures can then i guess it is fine.
Though Python would be a 3rd party dependency. ;)
HN comments about that article at https://news.ycombinator.com/item?id=33245042 . Including some of the problems people have had with 2FA usability.
For some reason many sites seem to pretend it's a phone- or special device only thing. In principle it's more secure, but if you also have a password manager on your phone – as many people do – then it's not really.
Give https://en.wikipedia.org/wiki/Time-based_one-time_password#A... a read, it's extremely simple.
> TOTP credentials are also based on a shared secret known to both the client and the server
AFAICT this "shared secret" is something that is shared between the service you want to authenticate with (e.g. PyPI) and "you" (your password manager, TOTP client or whatever), right?
In which case i guess this sounds something like it can be done fully locally indeed.
[0] I have a very old Android phone that i always keep offline
It's really simple; I once wrote an implementation in Python in 20 lines or so based on just the specification, and I'm not a crypto guy at all. It's probably the simplest crypto systems to implement. Things like "connect your authentication app" make it sound complicated, but all that does is store a short secret in the app.
One clear advantage of this is that a code is only valid for a short period of time (usually a few minutes at the most). I can't re-use the code you used yesterday, and intercepting codes is also much harder as it's much more time-sensitive.
I had a huge jackie chan meme moment at that point.
Then I realized that, all along, my password manager has a feature to store TOTP, and there is not even a strict need to use all these authenticator apps. (Of course, as someone who strives to exercise some security mindfulness, I reckon it undermines much of the overall point of TOTP to keep it within the same datastore as your account password.)
This code snippet can be used for standard TOTP 2FA
Many desktop password managers have built in support (e.g. keepass2).
I do feel want to mention though (largely because I think it's pretty cool), that those security devices are using a private/public key system under the covers, and they're actually designed to be privacy friendly and phishing resistant. One of the problems with TOTP based 2FA is that since it's asking users to type the TOTP code into the website, they can be phished and tricked into typing their password and TOTP code into an attacker's website, who then quickly go and use it to sign onto their account.
Those hardware tokens prevent that phishing from happening. They basically create, on the fly, a public/private key pair that is bound to the domain name of the site in question, and then give the public key of that to the site. When you come back to log in again, the site tells the hardware token what public key it has, the token looks a the site's domain and determines if it has that key for that domain, and if it does it uses a signature to prove ownership of the private key.
It all ends up working really well, since the domain name (actually the protocol, domain name, and port) is part of the identify of the key pair, it is impossible for it to get entered on the wrong site, so it completely eliminates phishing. Then since every single site gets it's own brand new keypair generated for it, there's no way to determine that the hardware token used on Site A is the same as the hardware token used on Site B. So it's entirely privacy preserving as well!
The protocol is obviously a bit more complicated then that, but that's the general idea of it.
a) are the only person who needs to use that login b) you can associate multiple logins with a single account.
As far as I can see (b) is not true which means yet another case where a colleague has to phone me every time they need to login.
edit: not shared account but a shared vault.
I hadn't thought of that!
That can be annoying to keep in sync if you have a lot of projects, but we're rolling out organization support to make that easier for people.
Current day mobile devices, infested as they are with the dubious morality and regulatory malpractices that engineered the duopoly are horrible as digital identity providers and 2FA.
2FA is a function that is becoming essential for anybody that wants to participate in a digital life. A widely available and easy to use alternative is not a good to have it is absolutely essential.
The implications of how 2FA is implemented go far beyond lovely PyPI. Entities like banks are deprecating specialized hardware in favor of the mobile. This is insane and odious.
Some 2FA systems do require some specialized mobile app, but this is not one of them.
As night follows day the next stage of 2FA will be biometrically based and there will be no escape route for "junior developers".
As a consumer and maintainer myself, PyPI has had a fair share of issues, but this is definitely not one of them.
Seriously, stop reinveting the wheel.