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

> * Occasionally, people mess up and enter their username as their password
> and vice versa.  Logging of connection failures, or indeed mere logging of
> error messages, will therefore expose their password --- admittedly, not
> identified as such, but if you see a subsequent successful connection you
> know whose it was.
>
> * Logging of queries is likely to expose sensitive user data in the form
> of constants in the queries, eg "INSERT INTO customers (name, address,
> credit_card_number) VALUES (...)".  Even if you're not logging all
> queries, failed queries could still expose such data.
>
> * An example pretty directly connected to yours is that people have
> complained about how statement logging will capture "ALTER USER joe
> WITH PASSWORD 'joes-new-password'".
>

Sadly, we (devs/administrators) realize all these things.  Big picture
logic plays no role in the way individuals develop the security
checklists or those accreditors that interpret those checklists.  It's
very black-and-white...either the database supports xyz (in this case,
no clear-text passwords in the log) or it fails that check.

I can give you specific reasons why the points you made above (which
are quite good points) are not applicable to us (ie users don't
directly log into the database, we use service accounts and handle
user auth/authz with PKI at the application level....and we don't log
individual statements because auditing changes are being done in a
different, approved, manner)...but we're digging down to such a
specific corner case it gets silly to argue scenarios.

> So basically, making the logs safe to show to untrusted auditors is a
> fool's errand.  You need to deal with this problem in some other,
> nontechnical, way.  IOW, why exactly don't you trust the auditors,
> and how will you fix that?

Right.  We (my team) agree.  We think it's stupid.  It doesn't matter
what we think. (Welcome to my world).  I'm sorry if I seem frustrated,
it's not with you...it's purely with the situation we're in having to
deal with this ourselves.

Believe me, I really hate to look at it like this, but it comes down
to: is there anything we can do within postgres / the postgres
community to eliminate this one specific 'vulnerability'?  Yes, we're
focusing on just the one vulnerability right now - where clear text
passwords are, arguably, *intentionally* sent into the log.  It's
something that can be fixed...and you have a developer (me) willing to
fix it if given direction on how he should proceed.

There are currently three suggestions on a fix put forth already:
 1) remove the raw line from the log entirely, just keeping the line number
 2) log that one specific event containing the raw log at a lower log
level (ie debug)
 3) parse out the password and continue to log the sanitized line at
the same "level" (all)

I'm OK with the fact that the patch I provided using the first
approach seems to be denied.  Can we consider either approach 2, 3, or
perhaps a combination or 2/3?

I do have alternative means at my disposal (ie use flume, or something
similar, to filter out just the log events I'm interested in and
forward off)...but we wanted to be able to help those behind us that
had similar concerns by fixing it at the source of the 'problem'.  I
want postgres to be unequivocally be approved software for the
government - not conditionally based on complex usages of 3rd party
applications to get it into an approved state.

S