Auto-type Two-channel obfuscation interference with Key modifiers
A lightweight and easy-to-use password manager
Brought to you by:
dreichl
Menu
▾
▴
#2232 Auto-type Two-channel obfuscation interference with Key modifiers
I found an interference between auto-type and two-channel obfuscation
Summary: when two-channel obfuscation is enabled, {CLIPBOARD-SET} and then a modifier-key sequence (e.g. paste, other shortcut) does not work and instead pastes the previous item
Reproduce steps:
1, create a sample entry with all defaults except set the following:
User name: loremipsum
(value not important, just standardize for demo)
Auto-type: enable
Override default sequence: {USERNAME}{ENTER}{CLIPBOARD-SET:/hunter2/}^v
(this is a minimal example - more on this later)
Two-channel obfuscation: UNchecked
2, open blank notepad file
3, back in keepass window, select the entry and perform auto-type (either through right click or auto-type shortcut)
Actual behaviour: it switches to notepad, type loremipsum, on the next line pastes hunter2
4, go back to edit entry and ENABLE two-channel obfuscation
5, repeat steps #2 and #3
Expected behaviour: it should switch to notepad, type loremipsum, on the next line pastes hunter2 (in other words, it should do the same as before)
Actual behaviour: it switches to notepad, types loremipsum, BUT on the next field it pastes lomp, which is the portion of the {UserName} that would have been pasted earlier through two-channel obfuscation RATHER than the expected text hunter2. If you then immediately manually paste it will correctly paste hunter2
More info / expanding on the minimal example:
this issue appears to happen when there is an auto-type item (e.g. username, password, etc), then {CLIPBOARD-SET}, and then a modifier key sequence.
so for example, this following auto-type sequence will correctly type both loremipsum and hunter2 with two-channel: {USERNAME}{ENTER}{CLIPBOARD-SET:/hunter2/}{CLIPBOARD}
The bug is not limited to the example given. It appears to affect modifier-key sequences generally. I initially discovered this when trying to use the paste+go shortcut in MS Edge, a minimal example of that sequence is this:
{UserName}{CLIPBOARD-SET:/{URL}/}^+l
explanation of what this sequence is intended to do: type username, set the clipboard with the {URL} value, then type Edge's paste+ go shortcut (ctrl+shift+L) which enters the clipboard value into the navbar and goes there. this is currently broken when two-channel is enabled.
System info
Keepass 2.53.1 64-bit (installed)
Windows 10 22H2 64-bit
This is expected because TCATO uses a combination of keystrokes and clipboard pastes to fill in the password. You need to turn TCATO off if you want to use the clipboard placeholders.
cheers, Paul
Hi is it still expected behaviour when the placeholders that use TCATO have already been completed?
It did occur to me that two-channel might not be compatible however the odd behaviour is that it pastes a portion of the previous pasted item.
If it had pasted
unterit would be very obvious that two-channel is still active when the key modifier sequence is being used. That would be a separate issue since arguably two-channel should not interfere with key modifier sequences.Further adding to the odd behaviour, is that if you leave two-channel enabled, but your autotype sequence does not have any other sequences which involve typing (doesn't have to be a placeholder) preceding the modifier-key sequence, then it works just fine. typing that happens after the modifier-key sequence will also work fine.
So for example, two-channel obfuscation is ENABLED for all following examples:
quickbrownfox{ENTER}{CLIPBOARD-SET:/hunter2/}^vwill produce output of
while
{CLIPBOARD-SET:/hunter2/}^vwill output (i.e. directly pastes)
and
{CLIPBOARD-SET:/hunter2/}^v{ENTER}lazydoggives
this last example also works with placeholders, e.g.
{CLIPBOARD-SET:/hunter2/}^v{ENTER}{USERNAME}will work fine too. and these typing sequences do use two-channel.My understanding is that TCATO is pseudo random. Test the same sequence several times to see what you get.
cheers, Paul
if you mean what segment it chooses to paste vs type, it looks to be determinative not only over multiple triggers of the same entry but universally. i have tested it with an entierly separate install of keepass on an entirely different database, just manually created a new entry with the same content.