| 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: | Whole Thread | Raw Message | 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 |