An attacker that can read your pipes/sockets can also sniff all your keystrokes, read your clipboard and read from other processes memory. A timer to erase the clipboard is only good to prevent accidents; a malicious program targeting your password manager will simply read the clipboard once a second and watch for changes. Local security is hard.

For a more-secure solution, consider running Qubes OS with a seperate vault VM running a password manager. That way you can induvidually copy passwords to the VM where you want to enter it, without others getting any access to it. Of course, that's too hard for most people, so we end up running everything in the same context and then call it "secure" because we erase the clipboard after 5 seconds.

I use pass ( http://www.passwordstore.org/ )

It can copy your password to the clipboard, and erases it after 45 seconds (by default.) It's still implemented as a shell script and uses xclip.

Reading the shell script I can see they thought about some clipboard managers which store their entries in plain text:

  # Clipboard managers frequently write their history out in plaintext,
  # so we axe it here:
  qdbus org.kde.klipper /klipper org.kde.klipper.klipper.clearClipboardHistory &>/dev/null

So anything that monitors your clipboard (basically every spyware worth its salt) will have a copy of all your passwords then? That doesn't seem very secure.

That is the case for all password managers... A big loop hole imo but one that has to be weighed against having simpler, more similar passwords for services.

If you have a browser password manager, monitoring the clipboard will do nothing.

That only works for passwords you use on the web though.

Which includes the vast majority of exploitable passwords. Passwords that only work on my local machine are of less concern when it comes to being hacked by a random keylogger software.

The only workaround I can think of is: don't use the clipboard then.

With pass you can also display the password on the console so you can retype it, but if you're running in an X session you're potentially screwed anyway.

If you wanna get real paranoid, displaying it on your screen isn't the best idea.

https://en.wikipedia.org/wiki/Van_Eck_phreaking

Reminds me that I tried to see if Emacs did anything to input in password-reading mode, and the content was in clear, only the rendering was obfuscated.

The point of erasing the clipboard is not to protect against malicious software - as others have pointed out, this doesn't work. The point of doing this is to reduce the risk that the user accidentally pastes their password somewhere they shouldn't (e.g. an instant messaging application).

I've also been using Pass. It is excellent, however the problem is that there doesn't appear to be much in the way of support for mobile devices. Not in any solid, working way anyhow. I decided to try out dashlane (http://dashlane.com) and so far it's been excellent with support for android and iOS devices as well as a desktop app and browser support. It does all I need.

Obviously those who like to keep their passwords close to their chests and host the password database on their own server, this won't apply but for the rest of us, I've not found anything as good.

If you do want to use the primary selection, you can use `xclip -l 1 -quiet`, which will remain in the foreground until a single request is made for its contents (a single paste); it will then quit, and the content will no longer be available.

Not fool-proof, but helps mitigate the risk. If an attacker snoops on the selection, it'll quit before your paste and you'll know that something is wrong.

Agreed. There's definitely room for improvement.