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

From: Steven Siebert <smsiebe(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #10680: LDAP bind password leaks to log on failed authentication
Date: 2014-06-19 14:37:22
Message-ID: CAC3nzehiW+L_tX6nvwcegaxh1zQZ2o-19+rOaci2AocbyMkfAA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> Ah, ok. Kerberos and SSL certs aren't immune to that problem, though
> the secrets don't ever end up in the logs- but they still must be
> visible to the server process in order. Of course, if you already
> have access to the server process, there shouldn't be much to gain
> from the Kerberos secret, the RADIUS secret, the SSL private key, or
> the LDAP bind password..

Agreed. In our situation (government), though, we must export out
logs to enterprise logging services where auditors (that wouldn't
otherwise have access to the server/process) would be able to see it.

Despite the arguments of it being in another file...generally, having
clear-text secrets copied around to multiple places is a bad thing. I
think it should be easy to come to compromise...and we're willing to
put in the work once we do figure out the best course of action =)

Thanks!

S

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message gotar 2014-06-19 14:54:42 BUG #10703: Set returning function type mismatch get's propagated despite explicit casting
Previous Message rafael 2014-06-19 13:58:08 BUG #10702: Installing source list