Yubikey has been getting multiple "Invalid Yubikey code" popups since Friday last week.
Many users reporting this issue, but sometimes it works and we are logged in.
However it fails more than it works, even after registrering yubikey again to a user account.
Do you have time issues on a service using yubikey?
Notice, we have not upgraded anything and time on our clients and servers are the same.
Using RDM 12.6 and DVLS 4.5.0 (don't have us upgrade, as this has worked for agesm upgrade will be later)
Regards
Michael
David Grandolfo
Yubikey authentication status:
Time elapsed: 780ms
Status: Yubikey:
No response from the validation. Make sure your network settings are correct.
Wireshark shows me that the dvls server tries 5 different ip adresses, when contacting Yubico api servers
Notice, that any other places we use the same yubikeys, they work without issues.
Attached is a screenshot of the wireshark capture, where the IP adresses are listed.
When contacting so many servers in such a short time, maybe dvls is not waiting long enough, as in the end a response is received from one of the ip adresses (but too late, as my client now responded invalid code and debug log shows no response from the validation)
/Michael
yubico.JPG
(I actually have responses from all the ip adresses later on in the capture)
Hi Michael,
We have been able to reproduce your issue and a ticket has been submitted to our engineering department.
Our internal ticket number is DPS-2681.
Best regards,
David Grandolfo
Hi David, any news about the matter?
It is still annoying our users and sometimes they are locked out.
Please explain why this is an issue out of the blue?
Did yubico change something with their API servers, are you in contact with them?
Cause our Devolution products versions have not changed for a long time, so why suddenly an issue with this feature?
Hi Michael,
I understand that this issue could cause many headaches. The current issue is not Devolutions Password Server itself, as you mentioned nothing change on this side. The issue is probably how we communicate with Yubikey server, I test in our latest version and the issue is still there.
I will have a chat with the engineering department today and if as soon as we received an answer from Yubico I will update you.
Best regards,
David Grandolfo
Hi,
After further tests, if you enter twice the 2FA, the second time the session log.
Could you confirm if it's the same behaviour on your infrastructure?
Best regards,
David Grandolfo
Not sure I understand fully what you mean, but I think that you are saying that after first failure, the second yubikey code works.
If the first time it fails, then maybe it works the second time for us.
But it seems for some reason that we have to remove the first failure instantly and send the second code as fast as possible.
If we do it "slowly", then it sometimes fails on and on and end up locking out the user account.
Hi Michael,
Thanks for the test, I didn't know about the delay of the second prompt.
I will add this information in the ticket.
Best regards,
David Grandolfo
Still no progress or info?
Yubikey issue is getting worse, users now locked out after 10 failed attempts with yubikey 2FA
Hi Michael,
The engineering department is still reviewing the issue.
Incidentally, we cannot provide a timeline for its delivery.
Best regards,
David Grandolfo
Have you seen this? (and coincidentially our Yubikeys have stopped working yesterday for good)
https://status.yubico.com/ (Read status for 4. February - YubiCloud no longer accepting v1 protocol, plain-text or old TLS version requests)
And this probably also explains why it has worked on/off for a while now
https://status.yubico.com/2018/11/26/deprecating-yubicloud-v1-protocol-plain-text-requests-and-old-tls-versions/
Note - We would need a hotfix for DVLS server 4.5.0.0, as we can't upgrade to newer version at the moment.
Regards
Michael
I have on our DVLS server forced TLS 1.2 for .NET application and for WinHTTP in the registry database
This seems to have worked for us.
My idea came after I saw in Wireshark, that TLS1.0 var in use, maybe sometimes it was TLS1.2, which explains why it worked sometimes.
But I can't confirm if DVLS is using protocol v2 or v1 as mentioned in
https://status.yubico.com/2018/11/26/deprecating-yubicloud-v1-protocol-plain-text-requests-and-old-tls-versions/
But right now it seems it is working for us...
Hi Michael,
Thanks for the details and solution. I will look with the engineering department if it's something we have to configure in DPS. Otherwise I will create a help topic to move to TLS 1.2.
Best regards,
David Grandolfo
Btw. I have always wondered why "Enable alternate 2FA" only supports "Email" or "Backup codes".
I would prefer to allow Yubikey as Primary and Google Authenticator as alternate 2FA.
Regards
Michael
May I suggest to post a feature request for this alternate 2FA.
For feature requests, kindly post them on the forums at https://forum.devolutions.net/forum34-devolutions-password-server--feature-request.aspx
This will allow the community to demonstrate interest in your idea. We use this interest to prioritize the features we implement.
Best regards,
David Grandolfo
Done