Hackers went undetected in Citrix’s internal network for six months

First, mutual auth with certs as you suggest isn't supported by "all servers which support TLS". Second, even if it was you have either a serious management headache dealing with arbitrary unsigned keys from end users or a huge management headache dealing with CSRs securely.

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.

> you have either a serious management headache dealing with arbitrary unsigned keys

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?

Fair point.

Basically, the ability for someone to log into my account by brute forcing or obtaining my credentials 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).

While U2F, as mentioned in other posts, will protect against those scenarios, it doesn't appear to support application protocols other than HTTPS.

>> Basically, the ability for someone to log into my account by brute forcing or obtaining my credentials

> 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.