Re: Chaniging focus: security ouitside a password manager
On 04/02/2018 10:07 PM, rhkramer@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.
Reply to: