Password+2 factor sends your password across the wire to the website, and trusts that website and the path between to handle it securely and not store or log it anywhere.
Passkey never sends your private key to the website you are signing in to.
That's how SSH commits work on github. It's an option, but for complete multi-factor security passwords take care of the "something you know" factor. The factors "something you know" like a password, "something you are" like biometrics, along with "something you have" like a hardware authenticator that implements TOTP/HOTP.
But modern password best practices require long, unique passwords for each website.
Most users either don’t follow this, or use a password manager.
If you use a password manager, the “something you know” has become just another “something you have” like an SSH or 2 factor key.
Basically for good security practices, passwords are converging on becoming SSH keys except less secure since you trust the website (or any device that isn’t yours that you type them into) to not leak them.
At that point, what value is the password providing when you are always pairing it with an actual private key challenge?
The best practices about the length and uniqueness of passwords was based on the assumption that leaked passwords and rainbow tables could be used to compromise multiple accounts from a single compromise.
The current standard of storing salted passwords makes the uniqueness requirement of passwords meaningless. If companies don't properly salt passwords, then uniqueness and length became an issue again. Salted passwords are effectively the same as appending an SSH key to a chosen password and letting websites manage them. With properly salted passwords, even if everyone chose the exact same password, a compromised password database would be meaningless.
This is the reason why NIST changed its guidelines about how often a password should be reset. It also changed the guidelines for complexity rules of passwords.
"Q-B05:
Is password expiration no longer recommended?
A-B05:
SP 800-63B Section 5.1.1.2 paragraph 9 states:
“Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”
Users tend to choose weaker memorized secrets when they know that they will have to change them in the near future. When those changes do occur, they often select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password. This practice provides a false sense of security if any of the previous secrets has been compromised since attackers can apply these same common transformations. But if there is evidence that the memorized secret has been compromised, such as by a breach of the verifier’s hashed password database or observed fraudulent activity, subscribers should be required to change their memorized secrets. However, this event-based change should occur rarely, so that they are less motivated to choose a weak secret with the knowledge that it will only be used for a limited period of time.
Q-B06:
Are password composition rules no longer recommended?
A-B06:
SP 800-63B Section 5.1.1.2 paragraph 9 recommends against the use of composition rules (e.g., requiring lower-case, upper-case, digits, and/or special characters) for memorized secrets. These rules provide less benefit than might be expected because users tend to use predictable methods for satisfying these requirements when imposed (e.g., appending a ! to a memorized secret when required to use a special character). The frustration they often face may also cause them to focus on minimally satisfying the requirements rather than devising a memorable but complex secret. Instead, a blacklist of common passwords prevents subscribers from choosing very common values that would be particularly vulnerable, especially to an online attack.
Composition rules also inadvertently encourage people to use the same password across multiple systems since they often result in passwords that are difficult for people to memorize."
> If companies don't properly salt passwords, then uniqueness and length became an issue again.
Yes, that is my point. You are relying on the website to properly transmit, store, and (not) log your password.
If you do not use unique passwords, then a lapse in those practices at any site sharing the same password could compromise that password across every site you use it on.
If you type that password into an untrusted device, it could also be compromised for every site you use that password on.
With private key authentication the website never gets your private key so they can’t compromise it even if they have bad practices.
2FA was created to guard against every single problem you mentioned. There is no concern that Aegis, which allows personal backups, management, and encrypted cloud backups of the secret keys. PKA where I don't control the private keys doesn't seem more safe. Especially since passkeys are being marketed as a replacement to TOTP.
Passkey never sends your private key to the website you are signing in to.