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