yubioath-flutter
yubioath-flutter copied to clipboard
Yubico
Yubioath-desktop and Chromium don't co-exist on Fedora 32
- Yubico Authenticator version: 5.0.4
- Operating system and version: Fedora 32 x86_64
- YubiKey model and version: YubiKey 4 nano Firmware 4.2.8
- Bug description summary: Chrome-based browsers and this app conflict
Of note, I use KDE as my desktop environment, in case this causes issues. I have my Yubikey 4 configured in OTP+FIDO+CCID mode. The Yubikey is protected with a PIN, so HOTP/TOTP codes cannot be accessed without entering it.
Steps to reproduce
Either way shows the error:
- Start Chrome/Chromium.
- Open the Yubico Authenticator
- You will be prompted for the PIN.
- Enter the PIN and the Authenticator app will not accept the PIN
- Close Chrome/Chromium and the key will Authenticate
1 Start the Yubikey Authenticator app 2. Enter the PIN and the TOTP/HOTP code screen shows. 3. Open Chrome/Chromium 4. Attempt to access any website 5. The Chromium Browser will lag badly on attempting to connect showing "Establishing SSL Connection..." and eventually fail on "ERR_TIMED_OUT". 6. Closing the Yubikey Authenticator app fails, and the app will not shutdown, as well as key refresh will fail.
At this point, killing and restarting the authenticator fails to even recognize the key, unless you move the key to a different USB port. Move the key to a new port and then connectivity to the Authenticator app will function again.
I was attempting to use the Yubikey to authenticate codes for my workplace.
Note, this issue does not occur with any other browser, except Firefox.
Also, it seems to have started specifically when I enabled PIN-protection on the yubikey, and did not show issues until I enabled PIN protection for the key. I had been using the authenticator app before without a PIN.
Expected result
I could open Chrome/Chromium and access websites, then use the Yubikey Authenticator app on the Desktop to provide 2FA codes for apps in Chromium,
Actual results
I cannot use both apps together, and I cannot use the Authenticator App after Chromium is opened until I force kill the PID of the authenticator application, and then physically move the key to a new slot.
Other info
None.[Anything else you would like to add?]
I've raised this bug in the Chromium project which is for the same issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1087704&q=&can=4
Also, note, that once I the codes hang on the key, I have to physically remove the key and reinsert it into a different slot, or the Authenticator app no longer recognizes the key in its original slot. Move it, and the key is recognized. If I cause the hang to happen again, I can move the key back to it's original slot and reopen the authenticator and then it will work again.
I have just confirmed - unsetting the PIN on the key causes the error to no longer appear between the authenticator app and the Chrome/Chromium browsers, however, new keycodes will no longer generate until I open the console and use kill <chrome/chromium PID>
Upon killing the browser, I get new PIN codes in the app properly and it no longer hangs.
Chromium developers believe this is something to do with nss-kit and that both Chromium and the Authenticator app are accessing the user-specific/system-wide nss stores
Thanks for the detailed report, and sorry for not getting back earlier. We'll try to look into this. It does seem strange that the password would make any difference, and it should also be possible to reproduce it with ykman oath commands, since the tools share smart card handling logic.
Another update, something that may or may not be related, but when I use anything that requests FIDO/U2F auth from the key, the touch-based TOTP function on the key seems to still be locked out until I physically pull the key and plug it back in. This is with the opensc patch
I am seeing the same issue with Fedora 33. Interestingly I didn't have this issue with Fedora 32. It only started after upgrading to Fedora 33. I don't have a pin set.
chromium-freeworld-86.0.4240.111-2.fc33.x86_64 nss-3.57.0-1.fc33.x86_64 yubioath-desktop-5.0.4-3.git2e13158.fc33.x86_64
The problem for me has gotten even bigger. Now I am having issues with starting firefox. Firefox will open an invisible window, and hang. I thought I had a bad update, bad kernel, or something. It ended up just being the yubikey. It seems like as with yubioath-desktop and chromium, firefox is also fighting chromium for access.
Edit: No this seems to at least also be a fight between Firefox and yubioath-desktop. I have Firefox open, Chromium closed, and yubioath-desktop open. Then Firefox will hang opening a new link in a new tab till I disconnect the yubikey.
yubioath-desktop also hangs all the time. I have to kill it regularly.
My current workaround is just to stop using U2F for anything. yubioath-desktop is more convenient than my phone, I have 10x or more 2FA codes than I did uses for U2F. Everywhere I can use U2F, I can use 2FA codes, but most places I can't use U2F.
I continued to have some issues with this even after getting rid of U2F, just less. I then upgraded from pcsc-lite 1.9.0 to 1.9.1 by making my own rpm with 1.9.1 based on the 1.9.0 source rpm. It has been a few days, and I have yet to see an issue.
I note that this issue continues on Fedora 33 as well with Chromium, but with the latest Firefox only open, there is no conflict. It only occurs when Chromium is opened and it appears the NSS conflict continues.
As soon as Chromium is opened, the yubioath-desktop key refresh hangs at the next cycle.
Versions are: yubioath-desktop-5.0.4-7.20210210git9ea38f7.fc33.x86_64 chromium-88.0.4324.182-2.fc33.x86_64 nss-3.62.0-1.fc33.x86_64
Yubico Authenticator 6.0 has now been released and uses a new codebase. As such, this issue has been marked with the legacy label, and will be automatically closed in 7 days. If this issue is still relevant to Yubico Authenticator 6, please comment on the issue saying so, and it will be kept open (or be re-opened). Sorry for the inconvenience!
