Yubico Forum

When I open Yubico Authenticator in OSX it shows my OTP passwords without touching my yubikey neo.

Is this the normal behaviour? A malicious script installed in my computer could have access to all my OTP passwords as long as my Yubikey neo is plugged in?

Thank you

My recollection is that this is normal behavior for authenticator:
1. for the applet-based OATH codes, you can set a password (optional?), but you cannot currently configure "touch required" (I put an issue into github asking for this feature a while back).
2. for the two slot-based OATH codes, however, you can configure "touch required" (but you cannot configure a password).

Brendan

What you describe is correct mr brendanhoar.

Thanks.

FYI, I added an issue to the github page with three alternate proposals, basically:

1. Support a touch feature for applet-based OTPs. This might be hard because it may require new applet code (and therefore wouldn't be supported on older keys).
2. Easier: add a user-settable maximum retry counter that discards the password and re-prompts after nn generations.
3. Easier: add a user-settable maximum retry counter that discards the password and minimizes or exits after nn generations.

https://github.com/Yubico/yubioath-desktop/issues/57

Brendan

Hi,

This is a very serious concern.
You should advise your clients that while their yubikey NEO (in the case of NEO-n you even claim to be designed to be "always" plugged) is plugged, the applet-based OTP is continuously streaming all the OTC passwords.
We have wrote a code that can now gain access to all the users yubikey neo applet-based OTP while their yubikey is plugged (if it the applet-based OTC is protected with a password we can intercept it with a keylogger so this protection is useless).

I am very disappointed and I think you should clarify this in the product specifications.

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.

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

Perhaps just a bit. Monday mornings and all that




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

Will do. Thanks, Dain.

Brendan

Full specifications are available, main website specs are misleading as these suggest as a requirement "touching" the device in order to allow password reveal.
My code doesn't have a name and can be available for major desktop without the user realizing it, on Android is not so effective as most users will use NFC and only one pass will be shown whenever the user needs it.