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 --
