What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

Not sure I would go that far. APIs need to be able to be deprecated as better forms are identified. That being said, the churn had better be worth it. This datetime change does not qualify, and feels like it is going to cause more immediate pain than it solves.

As much as I like to defend Python against the "Python bad!!" nonsense here on HN, I agree with this, and with similar complaints about naming in the 'datetime' module.

> If your password manager is compromised, you’ve got big problems regardless of 2FA tokens being in there or not.

That doesn't check for me:

- 2FA tokens being there -> total compromise

- 2FA tokens not being there -> no compromise of 2FA-protected accounts

Or did you mean something else?

> having your 2FA code phished

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.

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.

[0]: https://support.1password.com/secret-key-security/

[1]: https://xkcd.com/538/

Apologies for the wall of text, but I didn't have time to write a shorter explanation.

You're right. Classes don't even provide such operators by default:

  >>> class Foo:
  ...     ...
  ...
  >>> class Bar:
  ...     ...
  ...
  >>> a = Foo()
  >>> b = Bar()
  >>> a+b
  Traceback (most recent call last):
    File "", line 1, in 
  TypeError: unsupported operand type(s) for +: 'Foo' and 'Bar'

If anything, the complaint is that pre-type-hinted Python was too quick to raise a TypeError without helping you know what types it was expecting. The only case I can think of where it was too lenient was where Python 2 conflated strings and bytes. That change was 90% of the pain of the Python 3 upgrade, and now they're different types.