Re: BUG #10680: LDAP bind password leaks to log on failed authentication

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > Let's stop having passwords and secrets in a complex configuration file
> > which can have parsing and other failures.
>=20
> > How about allowing users to put that information in an independent file,
> > as do for SSL (admittedly, probably more because it's easier for us to
> > deal with OpenSSL that way, but still)?
>=20
> And then what?  This other file can't possibly be so simple that
> it's immune to having syntax errors, for example. =20

Uh, no, that's exactly the point of the independent file.

It's *only* the password.

fopen() - fails, then log that you can't open the file
fgets() - fails, then log that you can't read the file

(check for newline and remove it, if it's there)

If it grows to be a complex configuration file which can have syntax
errors, then it loses the point, I agree, but I don't hear anyone
complaining about SSL keys or SSH keys or Kerberos keytabs being leaked
in log files- and I'm pretty darn sure they would be complaining if it
was happening, regardless of any "keep your log files secure and only
let trusted people look at them" requirement.

> You're just moving
> the same problems from point A to point B.  More, this would complicate
> configuration and thereby create a whole new set of possible config
> errors, which we'd then feel pressure to ameliorate by adding more
> logging showing what the postmaster is doing.  And that logging would
> have this same issue of maybe it's exposing information that person A
> doesn't want logged ... even though person B needs that very same info
> to help him figure out his configuration mistake.  A likely example of
> that is feeding the wrong password/secret to some auth infrastructure
> service, because you referenced the wrong item in this secondary file.

This is done in other systems and has worked well from my experience.

> The core problem here is that we *need* to put security-relevant info
> into the postmaster log in order to help people resolve problems.  Moving
> around configuration details isn't going to fix that; indeed, the more
> complicated the configuration files, the worse the problem will be.

Having pg_hba be complicated but not having passwords in secrets in it
isn't making this problem worse- we can log all we want about pg_hba.
The point is to remove the sensetive information from the complicated
config file, even if that makes the complicated config file a bit more
complicated.

    Thanks,

        Stephen