5 ms·

> People should use a password manager with an rng to generate and store passwords. [...] > Separately from this, people should use hardware 2fa tokens whose

by u801e 8y ago

> People should use a password manager with an rng to generate and store passwords. [...] > Separately from this, people should use hardware 2fa tokens whose weakest link isn't the cell phone company support. What would be better is to support certificate based authentication in combination with a username and password. Then you have 2FA without having to share the private key. You can even get 3FA if the private key requires a passphrase to decrypt it. Using SMS or email based 2FA is not secure (or is only as secure as the email or cell phone account as you already pointed out). Using TOTP requires sharing a secret between the device and the server.

IncRnd 8y ago
A passphrase doesn't make it 3FA, since that is an already used factor class, what you know. 3FA is one from each category of what you know, what you have, and what you are. Depending on the implementation, what you describe may only be 1.5 factor auth.
- 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
  - 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

IncRnd 8y ago

A passphrase doesn't make it 3FA, since that is an already used factor class, what you know. 3FA is one from each category of what you know, what you have, and what you are. Depending on the implementation, what you describe may only be 1.5 factor auth.

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