While I'm not against security and 2FA in general, making PyPI 2FA mandatory ahead of any kind of org support is a major pain for big projects with more than one maintainer. This week I was forced to link my company's pypi account to a personal device to unblock our latest release and now none of the dozen other maintainers I work with can get access. Things will get spicy if someone in my position were to die, leave the company on bad terms, etc and a big project can no longer be managed.
PyPI announced orgs back in April, but it seems they still haven't figured out the details on pricing, etc. No telling when those will roll out, but I sure hope it's soon. I'm cynical, but the sequencing of work here very much feels like somebody at Google (or wherever) wanted to push a big open source security project to advance their personal promo case rather than thinking through the needs of serious project maintainers.
You were not forced to do that because TOTP is manageable via password manager.
TOTP and yubikey are excellent technologies that way. They allow two-factor authentication without breaking privacy.
Everyone within the sound of my voice: get a password manager. It sounds like a hassle but it makes your life infinitely better. It allows you to keep your life private and more secure than it was while providing more convenience than you had before.
I recommend KeepassXC. Open source, audited, fully featured, and can be paired with one of several different kinds of syncing technologies depending on your risk appetite.
I think it's odd that PyPI doesn't list any desktop programs, like KeepassXC, at https://pypi.org/help/#twofa , only mobile ones. That makes it seem like 2FA is mobile-only.
I expect some people don't want to mix work accounts on their personal phone ("keep your life private"), and because smart phones are still not yet universal, even among developers.
Many people seem to believe that keeping your 2FA keys in an un-backupable mobile app and away from your computer is safer than keeping it in your backupable and multi-device password manager.
PyPI doesn't list desktop solutions because I made that list back in 2019 and didn't think to list them. If you have some reputable desktop password managers that support TOTP that you'd like to see listed, you should open a PR for them!
You are certainly far more qualified than I to know which desktop password managers are reputable.
I only installed KeepassXC two weeks ago to try it out because several people here on HN mentioned it, and because it was free software not connected to for-profit companies.
It is the only one I've tried, and I've only used it once, to see what it was like.
I think your historical comment omits something. When I made this complaint back in 2019 you replied at https://news.ycombinator.com/item?id=20058199 saying "I've forwarded this thread along to others working on PyPI as part of the OTF grant, and we'll be figuring out how best to explain using TOTP without being too mobile-centric."
That mobile-centric list hasn't changed, and I still don't have, nor want, a smart phone.
Good to know, I wasn't aware. But if you're storing passwords, TOTP seed, and recovery codes all in the same shared password vault, it's not really multi-factor anymore. It's security theatre.
2FA was not created as a defense against password manager compromise. That is not its purpose. It protects against password reuse attacks and helps to protect against total compromise of people who have been phished.
Even better, a password manager can avoid giving up a TOTP code to a phisher in the first place because it is checking the domain.
If your password manager is compromised, you’ve got big problems regardless of 2FA tokens being in there or not.
The extremely marginal security benefit of storing the 2FA tokens separate from your password manager is just not even worth discussing in most scenarios. It exists, but doing that causes the additional risks of losing access to your 2FA token or having your 2FA code phished, both of which seem a lot more likely than your password manager being compromised. At least, as long as you’re using any halfway decent password manager.
Long term, the goal is to get rid of passwords and 2FA altogether by switching to Passkeys. Each Passkey will naturally be stored in a single place, since they can’t be split into multiple parts anyways.
It's important to think about threat vectors. A general concept like "the password manager getting compromised" is not really a threat vector, it's more the outcome of a threat vector. How exactly do you think a password manager is getting compromised? To identify the threat vector, we need to talk about the actual method of compromise here.
A 1Password vault is fully encrypted and protected by several layers of security. The most important layer of protection: the 1Password vault is encrypted with a combination of your password and your Secret Key[0], which is a long key generated uniquely for each vault. Even with a weak password, the vault has very strong encryption because of the Secret Key, which you don't get the opportunity to mess up and make weak by accident. Without both, the Vault cannot be decrypted, and nothing is stored in plain text; everything is stored in the encrypted vault. An additional layer of security is that they can't even get the vault from 1Password's servers without both your password and a second factor, assuming 1Password hasn't been compromised, but this is not critical. Even if the attacker got their hands on the vault, the vault itself is very secure. No attacker is going to be able to brute force the encryption key.
The most likely way (probably the only realistic way) for a well-secured password manager to be compromised is for someone to gain access to your machine while your password manager is unlocked. A simple keylogger is not enough, since it won't capture your Secret Key unless this machine has been deeply compromised since the day you set up 1Password on it for the first time. But, even then... that would mean they already own your machine.
So, total access to your fully unlocked machine, with your password manager also unlocked. That's what password manager compromise means in this context, at least to me. Remote access or physical access, it doesn't matter. As I said in my previous comment, if they have access to your password manager, "you've got big problems", because they probably have access to a lot more than just your password manager. If they have access to your machine, and your password manager is unlocked at the same time, it's game over for virtually anyone at that point.
It doesn't matter if the 2FA tokens are in there or not. It doesn't even matter if the passwords are stored in there, although I'm sure they wouldn't complain about having access to the passwords. Most services will allow the threat actor to reset your 2FA token (and password) simply by requesting a reset email with a verification link. Since the threat actor already has access to your machine, they almost certainly have access to your email, which the vast majority of people leave signed in. The password manager contains the username you use for each service, which is all they need to start firing off reset emails.
A very few websites won't let you reset your 2FA token, of course, but it's much fewer than the number of websites with 2FA. Anything other than verification emails (or never letting you sign in again) is very expensive for a website operator. Plus, what are the odds that you're not already signed into those sensitive services on this compromised machine? They may not even need your 2FA for whatever they're trying to do here. They own your machine. In the absolute worst case scenario (for the attacker), they just leave a RAT (remote access trojan) on your machine and walk away. They would just wait for you to sign into whatever they need, while you're completely oblivious to the attack. The password manager is an irrelevance.
The thing is... very few people get compromised this way in the first place. It's not worth losing sleep over unless you need to protect some extremely important asset. Certificate Authorities lose sleep over these kinds of threat vectors when it comes to their root signing key, of course.
I suppose we could also say something something quantum computers? Maybe some three-letter government agency can unlock your encrypted vault by waving a magic wand over it? If that's the threat vector you're worried about, then I don't think storing the 2FA tokens in a separate app is likely to help very much, but I guess it's something.
Even in my first comment, I admitted that there can be a very marginal increase in security by keeping your 2FA tokens separate from your passwords, so it can be the correct thing for certain scenarios. But, it does present additional risks, especially for TOTP. For those scenarios, I would generally recommend a YubiKey and using U2F instead of a TOTP app on a phone. For your security to be better off by keeping 2FA tokens out of the password manager, I believe that you need to be implementing some extreme security practices all over the place. Otherwise, it won't matter. Your password manager should be an extremely secure place to store 2FA tokens. If it isn't, then you need to find a better password manager ASAP.
Perhaps there are some other ways a good password manager could be compromised that I haven't considered in this comment, but those methods seem like they would have to involve either serious design flaws in the encryption or a big wrench[1]. You can never be 100% sure about any particular implementation of encryption, but what are the odds that someone is going to burn a very expensive zero-day exploit on you specifically? If they would do that, why? If there is a single service, or a single certificate, that needs the utmost protection, then yes, you need to take unusual steps to guard it. But this does not apply to almost anyone.
> What would be a realistic scenario? If I'm using a password manager, it won't recognize the phishing domain, which means I won't get to the 2FA step.
Usually, someone receives an important-looking email that calls them to take action by clicking a link. They urgently click the link, and begin trying to sign in. If it is being done by a threat actor who has already compromised your password by another means, they would just skip straight to the 2FA token prompt.
But, considering how skeptical that person sounded of password managers in general, I wouldn't be surprised if they're the kind of person who avoids password managers for their "most important" accounts anyways. Instead, choosing to use (relatively weak) memorized password(s). So, then they get phished for their memorized password, then reach for their "secure" separate 2FA app, and a 2FA code gets phished that way too. Game over.
You should probably not do that, but as coder543 says in another comment, there are reasons why even that is preferable to not having TOTP.
And assuming you enforce multi-factor authentication to access your vault, it is sort of transitively multiple factors (except for security vulnerabilities affecting the vault).
It’s not ideal, individual accounts seems like the only reasonable solution for legal and auditing reasons, but at least it’s possible to conveniently share users with 2FA enabled if you need to.
> sites implementing 2fa don't make it easy to share the keys
Sites that offer TOTP as a second factor normally either have the seed printed out next to the QR code, or have a button (or link) to show it.
It's a major hassle to scan a QR code from the laptop screen without leaving the laptop, whereas copy-pasting the seed into the password manager is easy. Pasting it somewhere you can share with other people is just as easy since the seed is just a string of characters.
There's also the fact that TOTP is an open standard, so one could very easily implement a bit of software that translated the QR code into the seed, so there's really no point at all for websites to try to protect the seed from the user. The user owns the seed and the code.
I suspect it has more to do with the legal backchatter on supply-chain attacks in opensource. The likes of GitHub and GitLab already have a bunch of features they can point at, should a lawyer come knocking; PyPi doesn't have anything.
I had the same experience in a big building. I basically rendered my own kitchen unsafe for human food preparation with all the poisons I tried, but still it hardly made a dent because there was a near infinite population of german cockroaches waiting to recolonize my unit from the walls and surrounding units.
If your time is so valuable, why are you spending it creating throwaway accounts just to hate on somebody else's content? If you don't like it, just move on. You're not adding anything to the conversation here.
There's an incredible recurring phenomenon of people registering throwaway accounts on HN to talk shit while also claiming that they "don't care" about the topic. The irony is stupefying.
I don't know about Rolexes specifically, but there is definitely a male subculture of people obsessed with watches who will be impressed by somebody sporting the right bling. I'm not into it, but I can see why many people are given they roll art, engineering, collecting, and conspicuous display of power/wealth all into one.
For some guys it's cars, for some it's watches. It's kinda weird seeing the men of my generation run around trying to find their "X" for "Yeah, I'm the <X> guy. Impressed?"
hypergamy. (particularly male) humans have been in a status conscious rate race since caveman days, it's built in and not likely to change. consciously avoiding it is just an alternate strategy in the same game, like the "wears sneakers with a tux" guy.
I wish the men around me didn't choose cars for how much noise they make, I live on a somewhat busy street.
The internet has just ruined niche culture a bit in my opinion.
I used to be harder to find people in to a specific sub-culture but now it is easy to find a subeditor or whatever. They just feed off each other until they are insufferable.
Having worked with a huge Jenkins deployment at a large company somewhat recently (>10,000 jobs), I found it worked okay enough that company leadership never felt it was worth the pain if switching. But all the friction points added up to a system that was rarely touched by anyone who hadn’t learned where all the bodies were buried. Over time that meant as an engineering org we were underinvesting in CI; there was a lot of quality-oriented stuff beyond unit testing that never got implemented in CI because the typical dev was unaware of how to change it or fearful about trying to change it. The relative accessibility of Github Actions (and other config as code alternatives) transforms the average dev’s relationship to CI from consumer to owner/developer/maintainer, and I think that is extremely worthwhile even if these tools bring some new problems of their own.
As someone who has only ever been involved in CI/CD at smaller companies, I take for granted that our pipelines are maintainable by the developers writing the code being tested/packaged. That just seems like a positive indicator for QA culture.
Familysearch took down a photo of my grandparents because it they were kissing. It is the only picture I have of that grandfather, but they say no PDA of any kind allowed so I guess his appearance will just be lost to history. Pretty weird if you ask me that they treat a peck on the cheek the same way they handle full nudity / porn / etc.
The OP seems to think we should approach cover letters with the same care as if we were writing the great American novel. I disagree. They are meant to be somewhat canned, but a good one will efficiently direct the reviewers attention to the parts of your resume which are most relevant to the job and give the impression that you are specifically interested in the role. This is a task generative AI can accomplish with appropriate direction.
Obviously a generic prompt is going to get a generic response, but if you put in the work to create a prompt with adequate context and descriptions of what you specifically want then I've seen it produce output that is a reasonably good starting place. If you don't want it using overly flowery, weirdly deferential language and copying specific phrases from the job description then you can address that by including those instructions in the prompt: "Be concise. Use a confident and conversational tone, and avoid using specific phrases from the job description."
The problem is most people aren't going to spend 20-30 minutes creating a really customized prompt. But people who can't write a good prompt probably also weren't going to handcraft a great letter either. Mainly because of the investment of time it requires to create a fully bespoke piece of writing by hand for each place you want to apply.
Another thing I want to mention is that it seems that many people don't realize yet that if you don't like the initial output you can give feedback and ask for revisions. E.g. "Can you make it shorter", "Eliminate flowery adjectives", etc or even just "Can you show me some different variations of this letter?"
If you're writing a lot of these, it's worth putting in 20 minutes or so to make a prompt that creates output that doesn't suck but which you can easily reuse for other companies and roles with minor tweaks.
Most of my frustrations with GHA arise when doing something useful conflicts with someone’s idea of security. For example, branch protection rules intended to stop devs from yoloing commits blocking me from pushing a version bump commit during a release workflow.
The lack of exceptions for actions is bizarre. And then they build repository rules or whatever, and made the same mistake again! You can at least exclude github apps now, but then you need to run all your repo actions with an app installtion key :/
> In business, if you don't honor agreements you get sued (and lose).
Unless you want future options with the person you are suing. Unless you need a reference. If you can afford it and if you are prepared to burn bridges.
PyPI announced orgs back in April, but it seems they still haven't figured out the details on pricing, etc. No telling when those will roll out, but I sure hope it's soon. I'm cynical, but the sequencing of work here very much feels like somebody at Google (or wherever) wanted to push a big open source security project to advance their personal promo case rather than thinking through the needs of serious project maintainers.