3

I am looking for quiet universal solution how to approach software keyboard for typing passwords under Linux.

Security level expectations: Achieve not worse (or acceptably slightly worse) security than when passwords are typed to applications on physical USB keyboard. (as in worst case it's starting point for many applications does not supporting more advanced means, and also, I can make/buy hardware password manager acting as usb keyboard as alternative).

The scope of my concern here is comparison of attack vector/risks of solutions based on USB keyboards or keyboard drivers vs just typing them via xdootool type ? (to unaware readers : copying passwords via clipboard has vector attack that any of your applications can read it)

Please note to all readers of question: If your machine is compromised, there are plenty of ways your passwords or keys can be leaked: including stealing them from programs' memory. Here I would like to consider what's "reasonable" method of transporting passwords (definitely I am looking for something better than via clipboard), while considering tradeoffs in mind (yes, keep hardware keys, etc, whenever you can, however not all systems support those more advanced means of authorisation).

3

Any application that you've run at least once can, if it wants to, see everything that you type, read all your files, and extract your passwords from your password manager. All it has to do is inject itself somewhere into the system:

  • To see everything you type: connect to the X server and ask. (To see how, run xtrace xinput test 42 where 42 is the device ID of your keyboard.)
  • Alternatively, grab the focus without giving any visual cue (and retransmit the input to the application that looks focused, to avoid immediate detection).
  • To read all your files: open, read.
  • To extract your passwords from your password manager: read the password database file and listen in while you're typing your master password. Alternatively, inject a wrapper around the password manager process and ptrace it.

Yes, in theory you could notice it. But in practice, you won't.

Putting password in the clipboard does have weaknesses, but local applications are not the problem. Local applications can get your passwords anyway. The main weaknesses of passwords in the clipboard are:

  • Browser bugs that allow web applications (i.e. any open browser tab) to access the clipboard.
  • Clipboard managers that retain a copy of the password in a place you wouldn't think of.
  • Accidental pasting into the wrong field.

The safest way to manage passwords is to avoid manipulating them. This eliminates the risk of user error. So save your passwords in your web browser and have it use the password automatically.

For non-web uses, injecting keyboard input with xdotool is as good as it gets. Local applications can get the passwords anyway, so you aren't losing anything.

  • It looks like qubes-os.org security through isolation is the right way to go. Anyhow, thank you very much for this clarification to all readers. Even it confirms that keyboard is more secure than clipboard, your answer makes it really clear why! (And also creates more respect to browser build-in password manager:) ). – Grzegorz Wierzowiecki Oct 27 '17 at 7:21
1

As it seem to me, the primary point to attack are the X11 events, which are rather easy to eavesdrop for any local application e.g. by xinput test <dev>. Also X11 is the part of (most) standard distributions, and for them all input (including USB keyboards) is channeled through X11.

The xdotool uses X11 facilities (XTEST) to inject the requested key stroks. So I assume it sends them directly through the X11 event stack as every other input. Since you explicitly specified that your reference is a USB keyboard, I'd say this way you reach your goal of not introducing further flaws.

Note: there are some applications like gksudo which are rather resistant to X11 sniffing, I don't know if that applies also to the xdotool input. Otherwise it would be a weakness.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.