Inconsistent RDP password entry

Hardware Password Manager
1

I have just started to use my OnlyKey.
I was setting up a couple of new passwords, one of which I set inside of a remote desktop session.

I ended up getting locked out of my account because it turns out the password entry over a windows remote desktop connection is VERY inconsistent.

Here are two test phrases I tried inputting via my OnlyKey over Windows remote desktop (I have also tried this on Splashtop and it seemed to work fine).

----What I Want----
1! 2@ 3# 4$ 5%
----Results----
11 2@ 3# 44 55
1! 2@ 33 4$ 5%
11 2@ 33 4$ 55

----What I Want----
Only The First Letter Of Every Word Should Be Capitalize
----Results----
only the First letter of every word should be capitalize
Only The first Letter Of every Word should be Capitalize
only the first Letter of Every word Should be Capitalize

Is this a known issue?

2

@super Yes, its a known issue. Unfortunately the issue is not exactly OnlyKey though, the issue is that RDP has trouble keeping up with fast typing, so things like the shift key being pressed dont work well at high speeds over RDP. Can you try setting a lower type speed in your OnlyKey app preferences and let us know if that resolves your issue?

3

Thank you for the reply.
I am slowing the typing speed down this time to 1, and the issue still stands.

Does the typing speed not apply to modifier key presses?

4

@super Thanks for testing, that usually fixes the issue. Can you provide information such as OS you are using, RDP app you are using (i.e. Microsoft or 3rd party), any special situation you are seeing this like RDP through another RDP?

5

So it looks like this is specific to using Windows RDP into our server.
Our server is running Windows Server 2016, and I am connecting through a single (not RDP inside RDP) remote desktop connection from my Windows 10 workstation.

I just tried connecting from my workstation into another workstation running Windows 10 and it works fine.

6

@super I think I identified the issue and a couple of solutions. I remembered a previous report of similar issue here - https://groups.google.com/forum/#!searchin/onlykey/rdp%7Csort:date/onlykey/HeGc6UmiM9c/JJGL2lm0AgAJ

The Problem:
Seems to only affect Windows RDP client when in full screen mode. Reason appears to be that the keystrokes being sent are pretty slow so RDP doesn’t only gets the modifier keys (like shift) sometimes.

Solution #1 - Go the ‘Local Resources’ tab of the Windows remote desktop connections options (click on ‘Show Options’ in the bottom left corner to display the tabs. You want the 3rd one from the left). There you will find a section named “Keyboard”. The default setting is to set to ‘Apply Windows key combinations only when using the full screen’. This can be set to “On this computer”. Then the issue will not happen in full screen mode.

Solution #2 - (short answer - wait for OnlyKey firmware release later this month) Long answer - I tested this using our current OnlyKey firmware, soon to be released OnlyKey firmware, and with YubiKey.

Yubikey Test
1! 2@ 3# 4$ 5%
1! 2@ 3# 44 5%
1! 2@ 3# 4$ 55
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 33 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 44 5%
1! 2@ 3# 44 5%
1! 2@ 3# 44 5%
1! 2@ 3# 44 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 44 5%
1! 2@ 3# 44 5%

Seems Yubikey also had the problem just not quite as bad.

Made adjustments to our new firmware to send modifier keys multiple times per key press (simulating actual user press of shift first then key) and now it looks to be 100% accuracy at default type speed:
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%
1! 2@ 3# 4$ 5%

7

Awesome, thank you very much for this.

I gave solution 1 a try and it worked like you said, though losing Windows key functionality on the remote client is a bit tedious.

I’ll definitely have to keep an eye out for the new firmware.

Thanks again and have a great rest of your week. :slightly_smiling_face:

8

Regarding this issue and new firmware (I’ve seen the same error happen with VeraCrypt boot loader when type speed was set too fast), would it be possible to make type speed a setting which can be saved independently per slot? This way you could use faster speeds for those logins which are compatible with it and use slower speeds for problematic ones.

btw: thanks for the great product!

9

This is a feature request mentioned here - Separate type speed settings per slot

10

maybe the keys should be held down a little longer or whatever, I obviously dont have any stats on how the onlykey handles the macros with the passwords and all

11

On oct 2020 Solution #2 mentions a solution with a next firmware release.
However, it seems the problem still exists in the current firmware version 3.0.1.
Solution #1 works, but a firmware update to really solve this problem would be more than welcome.

12

We did put a fix in the firmware in 2020. You will still need to make the change mentioned in Solution #1 as that is something that cannot be done in firmware. That is a setting in Windows.

13

I understood the message as Solution #1 or Solution #2 was to solve the problem.
You now seem to indicate both are required ?

14

just to understand the underlying issue:
isn’t the real problem a mix-up of symbols sent to RDP. So sometimes the shift-key is registered after the character was sent? So wouldn’t it be a simple solution to send the shift-key-down half way between the previous and the next character? And shift-key-up should be the same, in the middle of two numbers/letters?

Or even handle the shift-key-up and down like an character, which will slow down the entire process but increase reliability?

15

So wouldn’t it be a simple solution to send the shift-key-down half way between the previous and the next character? And shift-key-up should be the same, in the middle of two numbers/letters?

You have to send a character and the shift key modifier at the same time, Shift ON, Key ON, Key OFF, Shift OFF. This is what OnlyKey does. If the shift is off while the key is still on it would incorrectly print a lower case character.

I understood the message as Solution #1 or Solution #2 was to solve the problem.
You now seem to indicate both are required ?

Solution #2 has already been included in OnlyKey firmware since 2020, OnlyKey now generally works well in RDP as long as you don’t have a fast typespeed enabled. There is no fix for fast typing and RDP missing a character as RDP was designed to support keyboards typing at speeds that humans type. If RDP is missing characters you have to adjust your typespeed to a slower speed.

Solution #1 is something different. Windows won’t send certain keys through your RDP session unless you enable that option.

16

the modifier can be sent at ANY time. You can sent shift down an hour earlier. As long as no shift-up is sent, the modifier applies.

And the core of the issue is, that the modifier might get registered after the key-down event. Therefore sending the shift-down as dedicated event will solve the issue

and I have done this in my own implementation of a password manager, so my answer is not just an assumption but a proven fact.

17

I am not sure what you are referring to as a proven fact. RDP is known to have an issue with typing too fast, that is the issue here that affects all keyboards and the solution here is to decrease type speed.