Hah! Dain...do I detect a wee bit of snark?

---

I understand the threat model that OTPs are meant to mitigate: remote reuse of login credentials from a machine not under the control of the rightful account holder. Man-in-the-middle and/or Man-in-the-browser threats/attacks are generally out-of-scope for OTPs, but may become in-scope for certain OTP-enabled applications that require additional safeguards.

That being said, because a) the yubikeys (esp. nano/-n models) are often left in the USB port for long periods of time *and* b) because the desktop version of Yubico Authenticator will continuously generate TOTP codes for all accounts *and* c) because desktop systems can get compromised pretty easily...sum all three items together results in my opinion that leaving the code generation going on for hours/days by default is not the best default choice.


Having to remember to explicitly quit the authenticator (esp. because alt-f4 puts it in the windows system tray, continuing to generate codes) or pull out the key (which will interfere with PIV or PGP operations) seems to require a bit too much active mitigation on the part of the end user. It's not "default safe", it's "default convenient".

Relating to the issue ticket I put into github: the safest behavior would be an optional touch-required mode w/ the flag configured in the authenticator but stored and enforced by the applet. This would likely require applet changes and therefore new hardware - so it would be safest but not really optimal to solve the issue today. A second choice mitigation would be hard-coding a small number of consecutive code generations before the password is discarded and re-prompted for. A third choice mitigation would be a local setting for number of consecutive code generations (with 0 for continuous). I also understand that a single-code-before-relock is also not optimal due to bad-luck timing, so that being hardcoded would probably not work well.

In the short term for current users that really need a physical lock on the code generation...

Since the two classic slots already support touch-required and can now be utilized for TOTP codes with the desktop authenticator: if there's a particular account that is very sensitive, then store that account's TOTP secret in one of the two classic slots and configure that slot to require touch.

Just some thoughts.

Thanks,
Brendan

Full specification of the applet (as well as the source code) and the protocol it implements is available online already. I have also written code which is capable of extracting OTPs for all credentials stored on the YubiKey, it's called Yubico Authenticator and is available for major desktop OSes as well as Android.

I think that makes a lot of sense. Having the desktop app "forget" the passphrase after a set time (or number of calculations) makes sense, and could be implemented while still being compatible with existing devices. Would you mind opening another Github issue for that? As you've mentioned, the touch-to-generate ticket you've already opened will require updates to the applet itself, so it's not a backwards compatible solution (which doesn't mean that we're not going to implement it, just that it won't solve the issue for existing users).

Hah! Dain...do I detect a wee bit of snark?

I understand the threat model that OTPs are meant to mitigate: remote reuse of login credentials from a machine not under the control of the rightful account holder. Man-in-the-middle and/or Man-in-the-browser threats/attacks are generally out-of-scope for OTPs, but may become in-scope for certain OTP-enabled applications that require additional safeguards.

That being said, because a) the yubikeys (esp. nano/-n models) are often left in the USB port for long periods of time *and* b) because the desktop version of Yubico Authenticator will continuously generate TOTP codes for all accounts *and* c) because desktop systems can get compromised pretty easily...sum all three items together results in my opinion that leaving the code generation going on for hours/days by default is not the best default choice.


Having to remember to explicitly quit the authenticator (esp. because alt-f4 puts it in the windows system tray, continuing to generate codes) or pull out the key (which will interfere with PIV or PGP operations) seems to require a bit too much active mitigation on the part of the end user. It's not "default safe", it's "default convenient".

Relating to the issue ticket I put into github: the safest behavior would be an optional touch-required mode w/ the flag configured in the authenticator but stored and enforced by the applet. This would likely require applet changes and therefore new hardware - so it would be safest but not really optimal to solve the issue today. A second choice mitigation would be hard-coding a small number of consecutive code generations before the password is discarded and re-prompted for. A third choice mitigation would be a local setting for number of consecutive code generations (with 0 for continuous). I also understand that a single-code-before-relock is also not optimal due to bad-luck timing, so that being hardcoded would probably not work well.

In the short term for current users that really need a physical lock on the code generation...

Full specification of the applet (as well as the source code) and the protocol it implements is available online already. I have also written code which is capable of extracting OTPs for all credentials stored on the YubiKey, it's called Yubico Authenticator and is available for major desktop OSes as well as Android.

What you describe is correct mr brendanhoar.