On 04/02/2018 10:07 PM, rhkra...@gmail.com wrote: > * during copy and paste operations, the plaintext password could remain on > the C&P "stack". thus making it vulnurable: Some notes:
This is a semi-valid concern, depends on your usage patterns. For example, some browsers may expose a JS API that allows sites to read your clipboard. Adobe Flash has a similar feature, IIRC. Also, other applications running on your desktop may be able to read the clipboard contents as well, but that would require user privileges on your machine. Take that into account when deciding whether this is something you need to be worried about. > (1) I've read about at least one password manager that, somehow, > deletes > the plaintext password from the copy and paste "stack" after a time delay--I > didn't make a note of which one that was. I'm sure this is a relatively common feature in password manages. pass, for example, has this feature. That's quite something, considering how minimalistic it is compared to other, more fully-featured password managers out there. It does just use xclip(1), though. >From pass(1): show [ --clip, -c ] pass-name Decrypt and print a password named pass-name. If --clip or -c is specified, do not print the password but instead copy the first line to the clipboard using xclip(1) and then restore the clipboard after 45 (or PASSWORD_STORE_CLIP_TIME) seconds. > (2) another approach could be that a password manager provides a > facility to write the password to a designated textbox without using the copy > and paste facility, thus, presumably, never putting the plaintext password on > the copy and paste "stack"). pass also has this feature, suggesting it is a common feature to may password managers. Through a third-party script (available in contrib/ on the git repo, or /usr/share/doc/pass/examples/dmenu/ after installation on debian), this is possible. It basically just makes a call to xdotool(1) and passes in the password to be typed. xdotool handles the actual typing. As a plus, works even when sites decide to block c&p. Obviously, you could use some other front-end, or write one yourself. > * during hibernation (or maybe suspend and resume): (I use neither at the > present time, but, one stores the machine's state (including RAM) to disk, > the > other stores the (CPU) state to RAM while preserving the other contents of > RAM.) Hibernation could result in the plaintext of passwords being stored on > disk while the power is off, making the plaintext passwords vulnurable if the > machine is stolen. As Tomás said, make sure your swap partition is encrypted, if you bother with disk encryption. Even when not hibernating, if you start swapping, you may be storing valuable information in there without you knowing. It's usually a Bad Idea to have a plaintext swap but encrypted data partitions. Moreover, proper crypto code would probably make sure to remove keys from memory as quickly as possible, as soon as they're no longer necessary. No idea if GPG does this, though. Might be worth looking into.