On Mon, Apr 02, 2018 at 09:07:16AM -0400, rhkra...@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
