Re: Chaniging focus: security ouitside a password manager (was: Re: Password Manager opinions and recommendations)
Am 02. Apr, 2018 schwätzte rhkramer@gmail.com so:
moin moin,
Just continuing to think (or maybe not think ;-) about password managers /
password security, changing the focus slightly (I think) but keeping the same
thread.
I'm now thinking about the security (or vulnurability) of passwords during
"normal" usage--I mean, I'm thinking about the times when a password, even
though stored in a very secure manner (in a password manager or encrypted
file(s) of some sort), the password is viewable in plain text, and thus, to a
greater or lesser degree, vulnurable.
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.
Clipboard expiration was the feature that got me to finally consider a
password manager rather than my roll-your-own gpg script.
As I understand it, the clipboard is told to delete the contents after a
given time. That time is configurable for the KeePassX tools. I believe it
defaults to 20 seconds. It doesn't work for extra fields, e.g. if you have
security answers, but does for the password. It would be nice if the
auto-expire fields were configurable. Maybe they are in KeePassXC. I need
to finally move to that fork.
(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").
The auto-play feature might do what you want.
Also, with KeePassXC a feature I have not yet reviewed allows the
browser to prompt KeePassXC for the credentials. KeePassXC will then ask
permission to provide them before answering the application. This also might
do what you want.
Note that in both cases the plain text password is still being
transferred. For the latter, I presume it's possible for an ssh-style
exchange, so the plain text password would be communicated over a secure
channel. As I said, I haven't yet looked at it.
In any case, it's definitely people more knowledgeable than me
implementing the security in the open with multiple people looking at the
work. In other words, way better than anything I can create on my own :).
There's probably a FAQ on how KeePassX protects data in memory.
ciao,
der.hans
* 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.
My current approach to passwords includes storing them in an encrypted file
which is only ever decrypted to a RAMdisk, with the idea / intention that, if
power is lost, or the machine is shutdown, the plaintext passwords would
disappear from RAM (except to the extent that (iiuc) there are (NSA) ways to
recover the contents of RAM if power is restored to the machine fairly
quickly). My assumption, without considering hibernation. was that the only
remaining copy of the passwords would be in the encrypted files.
Maybe my concern about these situations is unrealistic, but I want to consider
it, so all comments are welcome.
BTW, I can see that the Master Password approach might be the solution for
most of the problem, unless I (or it) uses copy and paste to put passwords in
a textbox.
On Friday, March 30, 2018 09:44:18 PM Andrew McGlashan wrote:
--
# https://www.LuftHans.com https://www.PhxLinux.org
# Knowledge is useless unless it's shared. - der.hans
Reply to: