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

Steven,

* Steven Siebert (smsiebe(at)gmail(dot)com) wrote:
> 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.

I agree that there is a requirement to not store passwords in config
files, but having secrets stored in independent files actually solves
that- those files are then *not* config files. Consider that Kerberos
has a keytab file which certainly has secrets in it. As for trying to
control what the DBA can see vs. the administrator- that's certainly
good too, but not possible with PG if the DBA is a superuser. It
doesn't matter if it's encrypted or not, PG must know the secret at some
point and a superuser in PG can get access to pretty much anything that
the postgres unix user can.

This is why there is ongoing work to reduce the need for a superuser
role, to make it possible to have an actual DBA role which is *not* a
superuser but is still able to get their job done, while superuser would
be reserved for system administrators.

> 1) replace the secrets with a variable: 'myPassword' changes to
> ${myPasswordRef}.

We can simply have a new option for the radius auth method that is
'pwfile' or similar- there's no need for real variables.

> 2) use pgadmin GUI or a new CLI command ('secphrase' or whatever) to
> create a new encrypted phrase

If you can demonstrate that this would actually be useful then perhaps
it can be considered, but I don't see how this does anything for you-
how would PG get the password to use with the radius server? You'd need
a key somewhere for that which PG can read.

> 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

Sure, we can print the hba line w/ this new option and not have the
secret be leaked to the logfile, but store the actual password for use
by the authentication method.

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

Ok- and then what? You encrypt it with a different key than you use for
decryption, sure, but PG still has to know the decryption key to be able
to actually use the secret.. Now, if you fix radius to not use a shared
secret structure...

Thanks,

Stephen