Hm, this set me wondering how much risk there is passing the passwords through the copy-paste mechanism itself. Probably not terribly much more than passing through the keyboard and IO subsystems, though. Still, I know with X selection buffers, when data is requested the application it's requested from can run arbitrary code to generate (or check!) it and is passed the window-id requesting[0]. It seems like a password manager could make use of this to implement an ACL and lock things down tighter - do any do this?

[0]: http://tronche.com/gui/x/icccm/sec-2.html#s-2.4

I guess that is something of a double-edged sword then. You might force someone to use a weaker password, but then hopefully they wouldn't be keeping it in a place where they could simply copy/paste it. This really starts to delve into the whole "security is a gradient with tradeoffs" situation.

>hopefully they wouldn't be keeping it in a place where they could simply copy/paste it.

???

Passwords can be simple copy/pasted from.

Encrypted files can be simply copy/pasted from.

I'm assuming in this scenario that they would be keeping passwords in a plaintext file. If they kept passwords in an encrypted file, wouldn't they need to decrypt it? Wouldn't you presumably have a strong password to decrypt it? Where is that kept? How strong must one's password be when that password is keeping other passwords secure? If they can remember that password, why can they not remember others?

Remembering 1 password is easier than remembering dozens of them. Reusing passwords is not a great idea, so dozens of passwords is a real concern.

It's also the case that disabling paste doesn't do anything to stop a user from storing their passwords in an unencrypted file.

Because remembering one strong password is way easier than remembering 50 strong passwords.