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

Stephen,

Thanks for the response. I was actually about to write the patch after
having let the thread bake a bit =)

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

Ah! That makes a lot of sense. Thanks for the context.

>
>
> We can simply have a new option for the radius auth method that is
> 'pwfile' or similar- there's no need for real variables.
>
>
Easy enough - I can do it this way...much cleaner.

> > 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.
>
> That was really in the context of taking the approach of encrypting the
password...if it's a simple file...no biggie....don't really think this is
necessary.

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

perfect!

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

lol. well, the idea of piggybacking on the way SSL comms works is that
this has already been addressed - at the DBA makes the choice (based on
their requirements) if they want to have to type it in each time they
restart the service or put it in a file...I wouldn't be introducing a
foreign concept to postgres. Of course, it's moot...I'm more than happy a
patch based around your suggestions - and it'll meet our needs for the
STIGs.

I'll move forward with writing the patch now, I'm grateful for the
additional feedback.

Thanks!

S