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

* Steven Siebert (smsiebe(at)gmail(dot)com) wrote:
> Thanks for the response. I was actually about to write the patch after
> having let the thread bake a bit =)

Great- would love to have a patch to review. :)

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

Having a password have to be provided at startup is one option, I agree
with that. I'm not sure it makes sense in this case, but perhaps..
We did do that with our KDC when I was operating a NIST Moderate level
system, but we didn't use that approach for the shared secrets on each
server as it just wouldn't have been workable. Storing the files on a
encrypted filesystem which is mounted over loopback and requires a
password to mount would also work though and would remove the need for
PG to do any particular magic in this case.

Let's at least get the 'pwfile' option handled first and then we can
consider alternatives. There's no need to introduce public key
cryptography for the "type-in-the-password-at-startup" solution though;
we'd only be doing that because we could piggy-back on OpenSSL. I
suspect we could do better than that.

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

Sounds great!

If you aren't familiar with it already, you might want to check out our
Developer FAQ and http://commitfest.postgresql.org in particular, as
that's how we track patches which are submitted to the community to try
and avoid patches getting forgotten. :)

Thanks!

Stephen