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

Tom, thanks for the quick response =)

> If you had in mind to *force*
> people to use out-of-line secret storage, I agree that ain't happening.

That's certainly something I don't want to do at all, which is why I
expressed concern.  I didn't see the idea of using a token/variable to
identify that the password lives in another file in the previous
emails, sorry if I missed it.  Since this is the same idea I had
presented for the variables, this obviously works for me =)

> This sounds like more complication with no real benefit.

Depends on the perspective again, I guess.  To those attempting to use
PostgreSQL in a secure environment following NIST best practices -- it
is a benefit =).  But, like I mentioned, I've successfully mitigated
that in our situation, so it's just a thought for those coming behind
me.

Honestly, it is more complicated...and not really necessary in my
situation.  But, IMO, that goes the same for moving the passwords out
of the one config file and to other file(s), since I've already
provided a patch that solves the problem of having clear text
passwords in the log file by filtering which also retains the
debugging benefit.  Honestly, I can't really see how this new approach
does anything more for security than what I already provided....but
I'm more than happy to oblige.  If anyone has the patients to explain
it to me, I would appreciate it =).

I really just wanted to offer this solution to the community, which
does provide additional security (removing clear text passwords from
config files, optionally) using existing security mechanism available
(SSL support baked in already).  I can provide a patch for any
approach there consensus for.

>Also, we've generally avoided putting any strong encryption capability into core
> Postgres because of worries about US export regulations.  Perhaps that
> worry is obsolete, but I'm not sure.

Most of the US export restrictions were removed about 15ish years ago
- unless you're using encryption specifically designed for the
military, you're good.

Further, Postgres already provides native SSL support
(http://www.postgresql.org/docs/9.3/static/ssl-tcp.html)...and my
proposal simply piggy backs on this.  I wasn't suggesting to
incorporate any new encryption technologies.

Like I said, I'm quite OK with not implementing this more complicated
solution -- just wanted to offer it up since it popped into my head.

S