2FA is great for the web UI, but none of these vendors make it particularly easy to enforce 2FA on the command line.
The fact that one time passwords expire and change is what makes them a different factor than a static password.
If you're getting your 2FA code by SMS message or the like, this can be true.
If you're using TOTP (e.g. Google Authenticator), that's just as static as your other passwords. The TOTP code never expires nor changes. What changes is the code you're supposed to send over the wire.
(and you are not likely to leak it anyway -- with something that changes that often, you are not going to have an incentive to write it to files)
This makes it identical to a password from a theoretical perspective. There's really no difference between a TOTP secret that you keep in a TOTP app and haven't memorized, and a password you keep in your password manager and also haven't memorized. Both are "something you know", and nothing else.
You're correct that leaking a temporary code from a single login attempt doesn't compromise the TOTP secret. That is an artifact of the login process, not of whether the mechanism is labeled "2FA" or "password". You can do the same thing while calling the secret a password: https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
Ultimately, everything is "permanent, unchangeable secret", including private key and biometric data. Where the data is stored and how is it accessed makes all the difference.
I could not find the original definition of "something you have", but modern standards like PCI actually give OTP auth as an example of "something you have" (p. 4 of [1])
(I am not looking at the degenerate case of running TOTP app on the same device / same security domain -- it does not describe most cases, and there are some fairly straightforward technical measures to defeat this)
[1] https://www.pcisecuritystandards.org/pdfs/Multi-Factor-Authe...
But none of these things are true. For example, my most recent job involved sharing a 2FA-protected online account. We all had the code.
I think analogy to physical house keys is very helpful. What did your work do?
Did you show the enrollment QR code, and multiple people scanned it --> this is like duplicating house key.
Did you put the key into password manager -> this is like that combination lockbox that releases house key if you enter the right combination.
People do all sorts of unusual things, this does not change the properties of intended usage.
Well, no. Everyone who uses TOTP, without exception, has their secret stored in a password manager. That's what the TOTP app or device is.
The password manager returns passwords directly. They can be viewed, memorized, passed to another person, copied to another device, or checked into git.
With TOTP, there is a private key inside, but it is not accessible to user. You cannot view it, or memorize it, nor can you pass it to another person or check it into git. It is purely implementation detail which is not exposed in any way.
Disclaimer: this is the case with classical TOTP devices, like RSA SecurID hardware token, or un-rooted Android phone running Google Authenticator. I have those, and everyone I know have them as well.
There are exceptions, like people using LastPass 2FA or people who store TOTP secret on their PC. This is not intended usage, and it does not matter for most users.
Some 2FA apps also allow you to back up your codes to a cloud service.
For example, you can put your spare house key under doormat. This effectively makes a lock on your house door require "something you know" (you need to know where the key is stored).
However, that does not mean that we can say that all keys are "something you know". The fact that many people decided to compromise their security does not reflect on other intended use of locks and keys.