On Tue, Jul 24, 2018 at 12:25:31PM +0200, Marco van Eck wrote:
> Indeed having unencrypted password lying (.pgpass or PGPASSWORD or -W)
> around is making my auditors unhappy, and forcing me to enter the password
> over and over again. With a simple test it seems the password entered by
> the user also stays in memory, since it is able to reset a broken
> connection. Finding the password in memory is not trivial, but prevention
> is always preferred.
Sometimes the auditors are just wrong. Say you're using Kerberos, so
you put service keys in... "keytab files" -- that's just like putting a
password in a file because they are equivalent. Or server certificates
and their private keys... -- where are you going to put them if not in
some file?
Sure, you could put keys in a TPM (except they are orders of magnitude
too slow) or some other hardware token that doesn't suck (except those
are expensive). But now you still need unattended access to the token,
and who cares what the keys _are_ when you can just _use_ them to
escalate privilege anyways??
Forcing attended operation of otherwise automatic systems is not a good
idea, and it is very expensive too.
A quick search turns up tools for finding cryptographic keys in memory.
Passwords can't be much harder.
> It might be an idea to wipe the password after the login, and decrypt/read
> it again if it needs to reconnect. Would this make the solution more
> secure? I had a quick look at the code and the patch would stay compact.
> Please let me know of doing this would make sense.
But you still wanted to automate things, no?
You can't protect from local hosts compromises. You have to protect the
host. Please, no security theater. Do you think the day after a
massive data breach at your company you can tell the press "gee, I dunno
how they got the password, it was only loaded in memory!" and save it
from liability? (If there's no liability either way, that's a different
problem.)
Nico
--