2FA does not become 3FA when adding a new passphrase to a system that already had a knowledge based entry.
A password for a private key is _never_ considered what you are. You are severely misusing security terms and will mislead people to believe that a proposed solution has greater strength than it really possesses.
Then explain how authentication via a username and password validated server side, a client-side TLS certificate validated during the negotiation of a TLS connection between the client and server, and a passphrase validated locally on the client's device is not a better solution compared to typical 2FA implementations using email, SMS, or TOTP.
More importantly, this is also a false dichotomy, as the correct answer here is hardware protection of the private key, e.g. yubikey.
That essentially means the entire machine is compromised and logging into any service would allow the adversary to access them. That would compromise the email and SMS routes. If they have root access to my phone (or whatever I use to store the TOTP secret), that would allow them to generate the correct one time token to log into any service that I use TOTP 2FA with.
> With email/sms, at least it's possible for you to realize they're compromised
That's assuming I check carefully and often enough. If someone brute-forces my password over IMAP, then they could read my messages without me ever knowing. But I could always check the process list on my computer to determine if a keylogger is installed.
> and with TOTP the underlying keymat is likely not on the device so the attacker has to repeatedly win the race.
It depends on the application. If someone got access to my phone, they could easily get the TOTP secret out of my GAuth app.
> the correct answer here is hardware protection of the private key, e.g. yubikey.
Except that it's not universally supported. It's not going to work with my email client nor will it work with my IRC client.
While U2F, as mentioned in other posts, will protect against those scenarios, it doesn't appear to support application protocols other than HTTPS.
If that is the threat you are guarding against, that is the very reason for using different factors. In that way, you ensure that people cannot log in with credentials, even if they have them.
In the same way, an atm card cannot get you money, even if you stole it. In the case of an atm card and a pin, you need two factor classes, what you have and what you know.
Regarding the other part of your prior comment that incorrectly used 2FA, that is why Apple uses the terms separately, "two factor auth" and "two step auth". They are not the same.
> you ensure that people cannot log in with credentials, even if they have them.
Except that you left out the second part of that sentence:
>> or being able to bypass the log on process by using the conventional second auth factor against me (by doing the same thing to my email account and/or my cell phone provider).
For example: https://www.nbcbayarea.com/news/local/Mans-1M-Life-Savings-S...
In that case, the person was a victim of a SIM swap scam which redirected password reset messages to the attacker's cell phone, which then allowed them to access the account.
Regardless of how I initially termed it, having another factor just local to the device one is using rather than a 3rd party service that can be compromised in a way that you may not immediately realize is a far better way of doing multi-factor or multi-step auth.
But this solution should not just be limited to the HTTP application level protocol. It should also be available for other application level protocols (IMAP, SMTP, NNTP, IRC, etc). That means that U2F needs to account for this, or we should have more support for using client-side TLS certificates as part of the authentication process.
But rather than addressing the issues where a 3rd party serving as a second factor/step can be compromised without the account holder realizing it in time or the fact that U2F doesn't support other protocols besides HTTPS, you keep going on and on about "security points" which appear to be nebulous in the context of this discussion and also cherry-pick my responses only to go off on a largly irrelevant tangent.
This discussion could have been useful, but, unfortunately, it didn't turn out that way.
Yes, there is a fixation on security, since authentication is a security function that is often gotten wrong when people don't know the threat model and rush through a solution. This has been pointed out to you by several people more than once in this very thread.
Also, this isn't tied into a specific application level protocol. This can be done over other other application level protocols like SMTP, IMAP, NNTP, IRC, etc.
From what I've read about U2F[1], you need to use Google Chrome. Just checking the preferences/settings for both Firefox and Chrome, they both have the option of importing client side TLS certificates. Thunderbird also has the option of importing client side TLS certificates.
To put it another way, my browser can tell I'm connecting to news.ycombinator.com by using the certificate authority bundle installed on my machine. I don't need any external service or new standard to accomplish this. The same principle applies to client side TLS certificates.
Third, yubikey is not only supported by chrome. I've used it with IE and Firefox just now to verify.
Fourth, yubikeys provide significant additional security as you cannot lose control of the private key without realizing it, even if your box is owned. The yubikey requires you to physically press a button to approve any action it takes with the private key. Soft certs are gone once they're decrypted in RAM (there's automation for this exact thing in many RATs).
Source: NIST has advocated for mutual auth with PIV for over a decade. They are now moving away from it and towards WebAuthn, because it's (mutual auth with certs) simply not as good.
Once the user installs the certificate, then their browser would use it during the TLS connection. If the signature couldn't be verified, then the connection wouldn't be established, or it could be, but without the client side TLS part of it (depending on how the webserver is configured). The login attempt could then be restricted because the client side TLS negotiation never took place.
> huge management headache dealing with CSRs securely.
Let's take a website like news.ycombinator.com. When I click on the login link, it gives me the option to provide credentials or create a new account. If I choose to create a new account, I'm asked to provide a new username and password. They could add a field that would allow me to submit a CSR along with an email address they could email the signed certificate to.
Then I could get the certificate by email, import it into my browser and then use it along with the new username and password to log in with my new account.
For equivalent online accounts, a workflow like that should be good enough.
> Third, yubikey is not only supported by chrome. I've used it with IE and Firefox just now to verify.
They should update their website. The link I cited earlier still has the following quote:
>> What browsers support the U2F-certified Yubikeys?
>> You must be running the latest version of the Google Chrome browser, which includes support for the U2F protocol. To check the version number, in your browser, click the Chrome menu in the toolbar, then select About Google Chrome. (Support for U2F is in versions 38 and later.)
>> At this time, Chrome is the only browser supported. However, Mozilla is currently building support for U2F and Microsoft is working within the FIDO Alliance to eventually bring support to Windows 10.
> Fourth, yubikeys provide significant additional security as you cannot lose control of the private key without realizing it, even if your box is owned. The yubikey requires you to physically press a button to approve any action it takes with the private key. Soft certs are gone once they're decrypted in RAM (there's automation for this exact thing in many RATs).
While this is true, is this something that I can currently use with my email/news client? What about my IRC client? I know that I can use client side TLS certificates with both.
> They are now moving away from it and towards WebAuthn, because it's (mutual auth with certs) simply not as good.
What do they plan to do to address more secure authentication over other protocols besides HTTPS?
What I proposed was using a client-side TLS certificate in combination with the username/password for authentication. If the private key corresponding to that certificate requires a passphrase to decrypt, then it should be more than 2FA. What you know is the username/password, what you have is the private key. Whether the passphrase for that private key is considered what you know vs what you are is debatable (since, unlike the username/password or one-time token, the secret isn't shared by transmitting it over the network).