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