After explaining the patch to a college we identified potentially execution of another user when it is defined in as a command parameter. To protect agains it I've removed the possibility to pass the 'passcommand'. With the result libpq only allows the PGPASSCOMMAND environment variable, which can only be defined by the executing user, and will be executed by the same user. It only reduces the need of unencrypted password's in a file.
I think this solution is secure enough, shall we solve this feature-request?
Marco van Eck <marco.vaneck@gmail.com> writes: > 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.
> 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.
We're basically not going to accept any added complication that's designed to prevent memory-inspection attacks, because in general that's a waste of effort. All you're doing is (slightly) reducing the attack window.
