When I perform auto-type in a remote session, passwords are often typed wrong, sometimes even multiple times in succession causing account lockout.
It seems to happen more often during "busy" work hours and in cascaded remote session (such as a Citrix published Remote Desktop session to yet another server). Because of limitations in remote desktop logins I turned off TCATO. KeePass version used: 2.25
I generated a password for testing:
pWcyEG};hEW|t5yJwk$78\gV
After auto-typing about 50 times in Notepad, I got the following false entries:
pWcyEG};hEW|t5yjwk$78\gV
pWcyeG};hEW|t5yJwk$78\gV
pWcyEG];hEW|t5yJwk$78\gV
pWcyEG};hEW|t5yjwk$78\gV
pWcyEG};hEW|t5yjwk$78\gV
pWcyEG];hEW|t5yJwk$78\gV
pwcyEG};hEW|t5yJwk$78\gV
pWcyEG};hEw|t5yJwk$78\gV
pWcyEG};hEW\t5yJwk$78\gV
pWcyeG};hEW|t5yJwk$78\gV
pWcyEG};hEW|t5yjwk$78\gV
Some observations: In one entry, the captital w after capital e appeared lowercase. So it appears that each character is sent separately, together with a shift if needed. The character and it's needed shift arriving out of order would explain this.
Would it be possible to actually press-and-hold shift? And delay typing both before and after pressing / releasing shift?
For the above example password the keypresses would be (S: press Shift, r: release shift, _: no change):
_S_r__Sr__SrS_r__S_r_S_r
And in the timeslots without changes in shift state (space: no character typed because of shift state change):
p w cy eg] ;h ew\ t5y j wk 4 78\g v
This has most likely already been resolved by
https://sourceforge.net/p/keepass/bugs/1213/
Here's the latest development snapshot for testing:
http://keepass.info/filepool/KeePass_140410.zip
Make sure that the RDCAutoTypeAndTCATO plugin is not installed (otherwise KeePass' built-in auto-type engine is not used).
Best regards,
Dominik
Thanks for the swift response.
Unfortunately, the development snapshot produced similar results. After reading bug #1213 I tried adding a delay, see the attachments: one without configured delay, the other with {DELAY=100}. Both were produced with the executable from KeePass_140410.zip.
The plugin mentioned is not installed, and TCATO is turned off.
Last edit: RAvOX 2014-04-10
I can't seem to replicate your issue using the latest development build. All of my notepad entries are perfect using a randomly generated password with different types of characters and cases -- DvltFf%4W]@/Qe:!7JC5z01m(C(^RKWx
Unfortunately I cannot reproduce this either. Also, I cannot imagine a workaround; you already tested it with delays (so increasing the default delay will not help), and as far as I know the current key sending method is the only one working with remote desktop and VM windows.
Best regards,
Dominik
I can imagine that a radical change such as a different key sending method would break things for many users. Although this probably can't be fixed, I'll report back if I find a reliable way for reproducing the issue.
I can confirm it's still there in latest KeePass,
my auto-type hotkey is shift+F4 and I thought that might be the case why,
it often types 2 instead of @ in my login or just types password wrong
Windows 10 x64
Does it happen consistently?
Does it happen in different apps?
Do you have unusual keyboard / clipboard software running?
cheers, Paul
It can happen multiple times in a row, but most of the time it works fine
happens for different apps - steam login, epic games launcher login and all others
I also thought it might be due to me still holding \ releasing shift key after I press my shift+f4 hotkey for autotype
my keyboard is pretty old but with standard layout, thought caps lock is rebinded to control using registry keys, and there's autohotkey running for rebinding mouse buttons
Can you test it without AutoHotKey?
Put a delay in the Auto-Type to see if that improves things. {DELAY=100}
cheers, Paul
I tried pressing shift manully during auto-type and it seems to indeed be getting through and messing up the password, delay command just makes whole typing thing much slower, is there instead a starting delay thing so I could have time to unpress my shift hotkey?
thought if it was blocking auto-type hotkey while it's still being typed - it'd be better, I assumed it already worked that way
{DELAY 500} will give you time to release the keys.
KeePass doesn't block anything, it just types.
cheers, Paul
Same here. Within nested virtual Desktops (Remote Desktop within a Citrix Session), Shift keys get randomly dropped. Delays don't help.
Isn't it possible - as a workaround for this special case - to exclusively use Clipboard?
Marcus.
How would KeePass know it's in a nested VD in a Citrix session via RD?
This is really up to you to manage, either via drag n drop or copy/paste.
cheers, Paul
Oh no, I didn't mean KeePass should detect this automatically. I would like to have a third typing mode beneath normal Autotype and Two-Channel-Obfuscation: Send completely via clipboard.
Then I could set this third mode for the relevant entry.
I would never have expected that global auto type hotkey works inside VM inside Citrix, but it actually does, so it would be great to be able use it.
Marcus.
I doubt that using the clipboard during auto-type in this scenario is a reliable solution, but you can try it of course:
{CLIPBOARD-SET:/{PASSWORD}/}{USERNAME}{TAB}^v{ENTER}
Best regards,
Dominik
Wow. This is simple and works great. Thank you Dominik, you saved me a lot of trouble!
Marcus.
The clipboard does not work for me because I have to enter password in nested RDP session to the Windows lock screen which does not allow pasting.
But increasing to Delay=200 seems to have solved this
Problem still exists while login into nested citrix sessions, where clipboard is disabled.
using keepass 2.51.1 (64-bit) , my autotype sequence is currently
{DELAY=200}{USERNAME}{TAB}{PASSWORD}{ENTER}
Sometimes, username is changed : numbers in username are replaced with shifted value at french keyboard ( 5 => ( , 2=>é ... ). I have also seen a "i" replaced with "I"
Sometimes, username is ok but login fails . I suppose that same problem occurs during password typing sequence.
There is no link between the occurrence of the problem and the quality of my internet connection: sometimes , typed sequences appear with a big delay on the screen, but are correct, sometimes the opposite.
here is a test result : autotype in local notepad works perfect. autotype in remote notepad within citrix session fails sometimes, using this sequence for test purpose : {USERNAME}{TAB}{PASSWORD}{ENTER}
ABCDeFG1234567890abcdefg abcdefgihjklmnopqrstuvwxyz1234567890
AbCDEFG1234(67890abcdefg abcdefgihjklmnopqrstuvwxyz1234(67890
ABCDEFG123456è890abcdefg abcdefgihjklmnopqrstuvwxyz&234567890
AbCDEFG1234567890abcdefg abcdefgihjklmnopqrstuvwxyz12345678ç0
ABcDEFG1234567890abcdefg abcdefgihjklmnopqrstuvwxyz123'567890
ABCDEFG12"4567890abcdefg abcdefgihjklmnopqrstuvwxyz1234(67890
ABCDeFG123'567890abcdefg abcdefgihjklmnopqrstuvwxyz1234567890
ABCDEFG1234(67890abcdefg abcdefgihjklmnopqrstuvwxyz&2345-7890
ABCDEFG12345-7890abcdefg abcdefgihjklmnopqrstuvwxyz&2345-7890
ABCDEFG1é"4567890abcdefg abcdefgihjklmnopqrstuvwxyz12"4567890
ABCDEFG12345678ç0abcdefg abcdefgihjklmnopqrstuvwxyz1234567890
ABCDEFG1234567890abcdefg abcdefgihjklmnopqrstuvwxyz1234567890
aBCDEFG1234567890abcdefg abcdefgihjklmnopqrstuvwxyz1234567890
ABCDEFG1234567_90abcdefg abcdefgihjklmnopqrstuvwxyz123456789à
ABCDEFG1234567890abcdefg abcdefgihjklmnopqrstuvwxyz12345-è8ç0
aBCDEFG1é34567890abcdefg abcdefgihjklmnopqrstuvwxyz123'56è890
other sequence:
abcdefgABCDEFG1234(67_ç0 abcdefgihjkl12"4567890mnopqrstuvwxyz
abcdefgABCDeFG1234(67890 abcdefgihjkl12"456è89àmnopqrstuvwxyz
abcdefgABCDEFG1234(67890 abcdefgihjkl123'567890mnopqrstuvwxyz
abcdefgaBCDEFG&2345-78ç0 abcdefgihjkl12345678ç0mnopqrstuvwxyz
abcdefgABCdEFG1234567890 abcdefgihjkl123'567890mnopqrstuvwxyz
abcdefgABCDEFG1234567_90 abcdefgihjkl123456è890mnopqrstuvwxyz
abcdefgABCDEFG1234567890 abcdefgihjkl1234567_90mnopqrstuvwxyz
abcdefgABcDEFG1234567890 abcdefgihjkl1234567890mnopqrstuvwxyz
other test :
{USERNAME}{TAB}{PASSWORD}{ENTER}
6-6-6-6-6-6---6-6 AaAaAaAaAaAaAaAaAaAa
6-6-6-6-6-6-6-6-6 AaAaAaAaAaAaAaAaaaAa
6-6-6-6-6-6-6-6-6 AaAaAaAaAaAaAaAaAaAa
6-6-6-6-6-6-6-6-6 aaAaAaAaAaAaAaAaAaAa
6-6-6-6-6-6-6-6-6 AaAaAaAaAaAaAaAaAaAa
6-6-6-6---6-6-6-6 aaAaAaAaAaAaaaAaaaAa
6-6-6-----6-6---6 AaAaAaAaAaAaAaAaAaAa
6-6-6-6-6-6-6-6-6 AaAaAaaaAaAaAaAaAaAa
{DELAY=200}{USERNAME}{TAB}{PASSWORD}{ENTER}
6---6-6-6-6-6-6-6 AaAaAaAaAaAaAaAaAaAa
6-6-6-6-6-6-6-6-6 AaAaAaAaAaAaAaAaAaAa
----6-6-6-6-6-6-6 AaAaAaAaAaAaAaAaAaAa
6-6-6-6---6-6---6 AaAaAaAaAaAaAaAaaaAa
{DELAY 1000}{USERNAME}{TAB}{PASSWORD}{ENTER}
6-6-6-6-6---6-6-- AaAaAaAaAaAaAaAaAaAa
{DELAY=1000}{USERNAME}{TAB}{PASSWORD}{ENTER}
6-6-6-6-6-6-6-6-6 AaAaAaAaaaAaAaAaAaAa
I could see that the problem only happens on numbers and capital letters ( french keyboard : you must use "shift" to type in numbers and capital letters ) , and that delay will not solve problem. ( last line of test )
Last edit: sksbir 2022-10-06
Intermittent issues are the hardest to track down and because it only happens in Citrix there isn't a lot we can do.
cheers, Paul
Hi
I was able to find a workaround in addition to those already presented above: Always set all citrix windows to windowed mode:
- The autotype does not work at all in a local citrix session in full screen ( using a 2 screens display).
- The random shift problem appears if you use it in a full screen citrix session that is nested in a windowed citrix session.
- The random shift problem can also be mitigated even in a full screen citrix session that is nested in a windowed citrix session, if you use the CLIPBOARD-SET trick described above.
Since I switch my nested citrix session back to windowed mode at login time, I have not encountered the problem anymore. ( autotype sequence used : {DELAY=200}{USERNAME}{TAB}{PASSWORD}{ENTER} )
Interesting, thanks for the info!