3 ms·

> [You] will mislead people to believe that a proposed solution has greater strength than it really possesses. Then explain how authentication via a username a

by 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.
IncRnd 8y ago
What is the threat that you are guarding against?
- u801e 8y ago
  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.
  - IncRnd 8y ago
    >> Basically, the ability for someone to log into my account by brute forcing or obtaining my credentials 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.
    - u801e 8y ago
      >> 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-Stolen-In-Cell-Phone-Scam-509097961.html 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.

by u801e 8y ago

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.

IncRnd 8y ago

What is the threat that you are guarding against?

u801e 8y ago
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.
- IncRnd 8y ago
  >> Basically, the ability for someone to log into my account by brute forcing or obtaining my credentials 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.
  - u801e 8y ago
    >> 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-Stolen-In-Cell-Phone-Scam-509097961.html 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.