Re: Chaniging focus: security ouitside a password manager (was: Re: Password Manager opinions and recommendations)
On Mon, Apr 02, 2018 at 09:07:16AM -0400, rhkramer@gmail.com wrote:
>
> The first two situations that come to mind include:
>
> * during copy and paste operations, the plaintext password could remain on
> the C&P "stack". thus making it vulnurable: Some notes:
>
> (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 use keepasssx and it has this feature. It is very handy, but very
occasionally frustrating, depending on the UI with which I am
interacting.
>
> * 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.
>
Using full disk encryption (or at a very minimum encrypted swap makes
this less of an issue.
Yet another issue that you did not mention but which, IMHO, is a far
more practical one (in the sense that it impacts us every single day yet
we tend to not be aware of it) is that every program to which you supply
your password must securely manage transferring the password into and
out of memory.
If you log in to a display manager, it must take your plaintext password
from a text box and transfer it to another layer of the OS. If you
provide a password to your web browser in an authentication dialog, the
browser must take that plaintext password and either produce a digest
(for digest-based authentication) or send it in the clear (e.g., over a
connection secured with SSL/TLS). It must necessarily reside in memory.
I use mutt and I either must store my passwords in plain text in
~/.muttrc or provide them to mutt when prompted. However, when providing
the password to mutt when prompted, the default for mutt is to remember
the password until the end of the session. It has to be stored
somewhere.
Now, the kernel provides facilities for storing sensitive information in
memory, protecting access to it, and preventing it from getting swapped
to disk. However, when you use the wide variety of applications that
take passwords as input, you necessarily trust that the developers are
using all the appropriate facilities to securely handle the password and
also to securely wipe it from memory. Some applications, I trust because
of their reputation or because they are high profile receive lots of
attention from security researchers (e.g., KeePassX, Firefox, Chromium,
etc.).
However, I have delved into the code of some random applications (the
one that stands out in my mind is an FTP client, though I do not recall
which one it was) that make me think that most applications that handle
passwords do so improperly and insecurely.
I hope I did not open yet another can of worms here for you :-)
Regards,
-Roberto
--
Roberto C. Sánchez
Reply to: