4 ms·

I believe we can agree that just using a username/password for authentication is 1FA (single factor authentication). If we add a one-time token sent via SMS or

by u801e 8y ago

I believe we can agree that just using a username/password for authentication is 1FA (single factor authentication). If we add a one-time token sent via SMS or email, or generated via TOTP, that's generally considered 2FA (with the username/password considered what you know and the one time token being what you have, I believe). 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).

Godel_unicode 8y ago
As I have said other places in this thread, you're slowly reinventing Fido/u2f/(as was expanded by others)WebAuthn.
- u801e 8y ago
  Fido/u2f is only supported in certain places. What I'm talking about is supported by any server that supports TLS. For instance, news.ycombinator.com is running nginx. nginx supports using client-side TLS certificates. If the administrators of this website chose to enable it, they could allow me to submit a certificate signing request, sign it, and send me the resulting certificate. Then they could allow me to connect to this server using that certificate to authenticate me in addition to my username and password. 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. [1] https://www.yubico.com/solutions/fido-u2f/ https://www.yubico.com/solutions/fido-u2f/
  - Godel_unicode 8y ago
    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.
    - u801e 8y ago
      > 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?
IncRnd 8y ago
Many security people will discount everything that someone says once they see that person misapply marketing-phrases to describe security technology. 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.
- u801e 8y ago
  > [You] 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.
  - Godel_unicode 8y ago
    Key-logger on the box your soft cert is on. Soft cert is comprised immediately, fully, and permanently. And you might never know. With email/sms, at least it's possible for you to realize they're compromised, and with TOTP the underlying keymat is likely not on the device so the attacker has to repeatedly win the race. More importantly, this is also a false dichotomy, as the correct answer here is hardware protection of the private key, e.g. yubikey.
    - u801e 8y ago
      > Key-logger on the box your soft cert is on. Soft cert is comprised immediately, fully, and permanently. 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.

by u801e 8y ago

Godel_unicode 8y ago

As I have said other places in this thread, you're slowly reinventing Fido/u2f/(as was expanded by others)WebAuthn.

u801e 8y ago
Fido/u2f is only supported in certain places. What I'm talking about is supported by any server that supports TLS. For instance, news.ycombinator.com is running nginx. nginx supports using client-side TLS certificates. If the administrators of this website chose to enable it, they could allow me to submit a certificate signing request, sign it, and send me the resulting certificate. Then they could allow me to connect to this server using that certificate to authenticate me in addition to my username and password. 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. [1] https://www.yubico.com/solutions/fido-u2f/ https://www.yubico.com/solutions/fido-u2f/
- Godel_unicode 8y ago
  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.
  - u801e 8y ago
    > 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?

IncRnd 8y ago

Many security people will discount everything that someone says once they see that person misapply marketing-phrases to describe security technology. 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.

u801e 8y ago
> [You] 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.
- Godel_unicode 8y ago
  Key-logger on the box your soft cert is on. Soft cert is comprised immediately, fully, and permanently. And you might never know. With email/sms, at least it's possible for you to realize they're compromised, and with TOTP the underlying keymat is likely not on the device so the attacker has to repeatedly win the race. More importantly, this is also a false dichotomy, as the correct answer here is hardware protection of the private key, e.g. yubikey.
  - u801e 8y ago
    > Key-logger on the box your soft cert is on. Soft cert is comprised immediately, fully, and permanently. 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.