4 ms·

I get the value if you assume the host is not compromised and you are worried about encrypt-at-rest or for transmit, but how does a user securely provide a PIN

I get the value if you assume the host is not compromised and you are worried about encrypt-at-rest or for transmit, but how does a user securely provide a PIN to the device if the host itself is rooted?

jolmg 6y ago
That's why in another comment I mentioned that the confirmation button / touch-sensor (and LED) on the Yubikeys is important. If a malware tries to use the key with the compromised PIN or while the credentials are cached, the Yubikey will still ask for confirmation. If it's asking for confirmation when you did nothing to trigger it, then that's a sign that the host might be compromised. Simply don't confirm, fix the malware issue, and change the PIN.
- gruez 6y ago
  That's not too hard to work around. Simply wait until there's a legitimate request from the user and piggy back off that instead
  - jolmg 6y ago
    Then there'd be two confirmations you'd have to accept. Even if the compromised host replaces the legitimate request for its own so that the original doesn't run, you'll still notice that whatever you requested was never done after confirming. I'm not sure what you're precisely proposing by "piggy backing", but I can't see a practical way of doing it that wouldn't make it obvious to the user that something is wrong.
    - gruez 6y ago
      >but I can't see a practical way of doing it that wouldn't make it obvious to the user that something is wrong. Maybe if the user is always on their toes and hasn't gotten complacent. You can probably fool most users by causing a technical hiccup (eg. "your session timed out", "Gateway timed out", wifi cut out, etc.), which will provide a plausible reason for them to press the button again. You can also fool them by faking a login screen when they're already logged in, which will allow you to hijack the request without worrying about the legitimate request. Unless they're truly paranoid, most users won't report minor glitches like that to IT, but for the attacker one hijacked press is all they need to own your entire infrastructure.
      - jolmg 6y ago
        All that seems targeted, not a generic malware checking for Yubikeys connected to random systems. It also doesn't seem "simple" or "practical". Is your argument that the sensor is useless because you can bypass it like that, or is your argument that it's not absolutely foolproof? If the former, I disagree; if the latter, then I can agree. I mean, we're comparing to the alternative where if the credential is cached, then any software can use the key as they like without the user being any wiser. They wouldn't need to present convincing fake login screens or anything else.
        gruez 6y ago
        >All that seems targeted, not a generic malware checking for Yubikeys connected to random systems. Well that's because it's 2 factor, not because you're using a hardware token. Using TOTP would offer similar protections against "generic" malware that's scanning credentials to use later. >It also doesn't seem "simple" or "practical". Is it? It doesn't seem too hard to hook into browser (or whatever other program like gpg or ssh-agent) so you can listen for authentication requests, and disable the wifi using the platform api. >Is your argument that the sensor is useless because you can bypass it like that, or is your argument that it's not absolutely foolproof? If the former, I disagree, if the latter, then I can agree. The sensor adds marginal amount of security and provides a false sense of security. Most the increased complexity (compared to "generic" malware) involved in such a hypothetical attack comes from the 2 factor aspect, not from having a hardware token or having a physical button on the token.

jolmg 6y ago

That's why in another comment I mentioned that the confirmation button / touch-sensor (and LED) on the Yubikeys is important. If a malware tries to use the key with the compromised PIN or while the credentials are cached, the Yubikey will still ask for confirmation. If it's asking for confirmation when you did nothing to trigger it, then that's a sign that the host might be compromised. Simply don't confirm, fix the malware issue, and change the PIN.

gruez 6y ago
That's not too hard to work around. Simply wait until there's a legitimate request from the user and piggy back off that instead
- jolmg 6y ago
  Then there'd be two confirmations you'd have to accept. Even if the compromised host replaces the legitimate request for its own so that the original doesn't run, you'll still notice that whatever you requested was never done after confirming. I'm not sure what you're precisely proposing by "piggy backing", but I can't see a practical way of doing it that wouldn't make it obvious to the user that something is wrong.
  - gruez 6y ago
    >but I can't see a practical way of doing it that wouldn't make it obvious to the user that something is wrong. Maybe if the user is always on their toes and hasn't gotten complacent. You can probably fool most users by causing a technical hiccup (eg. "your session timed out", "Gateway timed out", wifi cut out, etc.), which will provide a plausible reason for them to press the button again. You can also fool them by faking a login screen when they're already logged in, which will allow you to hijack the request without worrying about the legitimate request. Unless they're truly paranoid, most users won't report minor glitches like that to IT, but for the attacker one hijacked press is all they need to own your entire infrastructure.
    - jolmg 6y ago
      All that seems targeted, not a generic malware checking for Yubikeys connected to random systems. It also doesn't seem "simple" or "practical". Is your argument that the sensor is useless because you can bypass it like that, or is your argument that it's not absolutely foolproof? If the former, I disagree; if the latter, then I can agree. I mean, we're comparing to the alternative where if the credential is cached, then any software can use the key as they like without the user being any wiser. They wouldn't need to present convincing fake login screens or anything else.
      - gruez 6y ago
        >All that seems targeted, not a generic malware checking for Yubikeys connected to random systems. Well that's because it's 2 factor, not because you're using a hardware token. Using TOTP would offer similar protections against "generic" malware that's scanning credentials to use later. >It also doesn't seem "simple" or "practical". Is it? It doesn't seem too hard to hook into browser (or whatever other program like gpg or ssh-agent) so you can listen for authentication requests, and disable the wifi using the platform api. >Is your argument that the sensor is useless because you can bypass it like that, or is your argument that it's not absolutely foolproof? If the former, I disagree, if the latter, then I can agree. The sensor adds marginal amount of security and provides a false sense of security. Most the increased complexity (compared to "generic" malware) involved in such a hypothetical attack comes from the 2 factor aspect, not from having a hardware token or having a physical button on the token.