Re: BUG #10680: LDAP bind password leaks to log on failed authentication - Mailing list pgsql-bugs

Thanks Tom,

Moving the secrets to another file will indeed fix this problem, and I
really don't think it'll take very much to implement this.  As you
mentioned, this increases the complexity of the configuration process,
and I certainly don't want to impose our backwards incompatible change
(on upgrade, they would need to create those new files) on everyone
else in the community.

At risk of adding more work for me, perhaps we can find a compromise
that would not create this backwards incompatible change while
addressing this and another issue that is related to gov requirements:
storing clear text passwords in configuration files.  Similar to the
DBA/auditor role separation, there is a requirement to separate the
roles of the DBA/administrator, and what they have access to - in this
case access to the secret (radiussecret/ldapbindpasswd) the postgres
dba is using to authenticate.  We've been able to mitigate this
because our dba is our admin -- but in reality this is an impediment
that each agency would need to work around as well.

My counter proposal is to optionally allow dbas to encrypt the secrets
used in the configuration file by substituting the actual password
with a variable.  This would allow the configuration to stay the same
for those that do not wish to make use of the feature, but for those
administrators that want to produce logs without clear text passwords
and remove clear text passwords from config files completely, they can
take the following steps:
1) replace the secrets with a variable: 'myPassword' changes to
${myPasswordRef}.
2) use pgadmin GUI or a new CLI command ('secphrase' or whatever) to
create a new encrypted phrase
3) while printing the hba line, the raw line will contain the variable
string but when the actual secret is requested the encrypted value
will be retrieved

Normally, storing anything in reversible encryption is really just the
same as storing it as clear text, but what I propose is to use the
same asymmetric keys used for secure SSL comms
(http://www.postgresql.org/docs/9.3/static/ssl-tcp.html).  PostgreSQL
already has precedence for this (SSL comms) and allows the user to
decide what degree they wish to protect their system: using a
passphrase on the private key forces the user to enter the passphrase
on boot, if no passphrase, it just works.  In the case of using the
same keys for the secret phrases, typing the passphrase once will also
allow for the decryption of the secret phrases.

The encrypted phrases that were created by this process wouldl be
stored in a special file with the key of the reference name and the
value being an b64 encoded encrypted secret.


Thoughts?

S



On Sun, Oct 19, 2014 at 4:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Steven Siebert <smsiebe@gmail.com> writes:
>> I haven't heard a anything after my response to Toms email on 12Oct, is
>> there anything I can do to move the forward on this?  It's actually fine
>> with me if it's preferred to close the issue as won't fixed if the group
>> wants to go another direction...
>
> Well, Stephen was proposing that we make it possible to push all secrets
> into separate files (one file per secret), which would allow DBAs to
> eliminate the problem as long as they were willing to set up such files.
> I'm not entirely sold on that reasoning, because I'm doubtful that people
> would bother; but if you care to look into what that would involve, it
> would help move the discussion forward.
>
>                         regards, tom lane