keylogger-obfuscating-input.txt

Can password typing in the browser be made less obvious
for a keylogger?

No... probably this is creating another attack surface...
but anyway.

Suppose you'd randomize the rate, and the order in
which characters reach the DOM, introducing additional
characters and keystrokes.

I used to edit my browser password input fields by
leveraging vim using Vimperator on Windows back in 2004.
Specific vim configuration and vim's :rightleft command
allowed me to type the passwords in reverse. Pretty cool.

So imagine a secure context, where a non-repeating
pseudo-random number generator returns a list of
numbers, based on a given password length. Imagine
that this is then made known to the user securely.

If a user keeps passwords on paper, a new 'key' could
be written above the password every time (s)he needs
it.

7 5 8 3 2 1 9 11 4 12 6 10
X J v i Y H < `  + L  m )

Then, the 'key' could be written to a temporary file
with an unpredictable name that's only interpretable
by the program that'll send keystrokes to the browser
as you type. Remember, the actual DOM input may
contain an amount of additional garbage characters to
further obfuscate the input. So given this key, and
without the garbage, when the user types:

HYi+JmXv<)`L

the browser receives (vim macro expression):

let @a="iH\<left>Y\<left>i\<right>\<right>
+\<left>\<left>\<left>\<left>
J\<right>\<right>\<right>\<right>
m\<left>\<left>\<left>\<left>\<left>\<left>
X\<right>v\<right>\<right>\<right><\<right>\<right>
)\<left>\<left>\<left>`\<right>L"

which results in our passphrase: XJviYH<`+Lm)

Passwords should obviously have strong entropy, so
when the characters are to be input in a different
order, this is not much of an extra hurdle.

Again, this has no real benefit. A keylogger could
easily be designed to figure out the resulting text.

lol! I always had this idea floating in my head. Thanks for sharing