Re: BUG #18379: LDAP bind password exposed

Greetings,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> > Whenever a login attempt is made using LDAP authentication, the entire
> > configuration line from the pg_hba.conf file is being logged in the
> > PostgreSQL log files. This includes the LDAP bind password (ldapbindpasswd),
> > which is being recorded in plaintext. This practice poses a serious security
> > risk, as it exposes sensitive credentials in log files that might be
> > accessed by unauthorized individuals.
>
> We do not consider this a bug. There are very many ways that
> sensitive information could appear in the postmaster log file.
> There's no way to block them all, not least because some items
> are ones that the server could not know are sensitive (consider
> for instance credit card details, or medical information in a
> database under HIPAA rules). You *must* make arrangements to
> secure the postmaster log equally carefully as the database itself.

While I agree that users should take steps to secure their log files,
I'd argue that it's best practice to avoid dumping sensitive data into
log files, which it seems like it would be in this case. I'm not
suggesting that this is bug-worthy or that we should go to excessive
lengths to try and prevent every such case, but if someone showed up
with a reasonable patch to replace the sensitive information in a pg_hba
line with ****, I would be on the side of supporting that.

> Having said that, you might consider moving away from LDAP
> authentication. It's not considered best practice anymore,
> notably because it requires the server to see the user's
> unencrypted password, and then turn around and pass that on
> to the LDAP server. GSSAPI/SSPI (a/k/a Kerberos, or Active
> Directory in the Microsoft universe) provide substantially
> better centralized authentication technology that's more
> secure in quite a few ways.

Fully agree with this. The best approach to dealing with this is to
move away from PG's 'ldap' auth type.

Thanks!

Stephen