Re: reducing our reliance on MD5 - Mailing list pgsql-hackers

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >> We've already got a sufficiency of external authentication mechanisms.
> >> If people wanted to use non-built-in authentication, we'd not be having
> >> this discussion.
>
> > Just to be clear- lots of people *do* use the external authentication
> > mechanisms we provide, particularly Kerberos/GSSAPI.  SASL would bring
> > us quite a few additional mechanisms (SQL-based, Berkley DB, one-time
> > passwords, RSA SecurID, etc..) and would mean we might be able to
> > eventually drop direct GSSAPI and LDAP support and have a better
> > alternative for those who want to use password-based auth.
>
> My point is that we already have got a lot of external authentication
> mechanisms, and it's completely unclear (to me anyway) that there is
> any demand for another one.

To this point, I have had requests for various things which SASL would
provide- ability to use the same password as the Unix host, SecurID
support, and SQL-based (with another PG database) all come to mind.
I agree that such isn't particularly relevant to this discussion though.

> The unsatisfied demand is for a *built in*
> mechanism, specifically one that people have more faith in than MD5.

I agree that there is demand for a new mechanism which isn't MD5.  I
don't think *built in* is at all a requirement however- *easy to use*
is.

> Those who worry about that and don't mind having additional moving parts
> have probably already migrated to one or another of the existing external
> solutions.

Certainly we'd want to make SASL-with-SCRAM easy for users to use.  To
the extent that the moving parts in that arrangement are hidden from
view, hopefully users will use it and we get comfortable enough with it
for distros to set it as the default.

I am catagorically *not* worried about non-libpq client libraries and
applications in this regard.  For starters, those aren't end users,
those are other developers who have a vested interest in supporting
whatever we do.  Further, Java certainly supports SASL, as do quite a
few other languages (Python, PHP, Ruby, there's a few examples in Go it
seems).

> While I won't stand in the way of somebody adding support for an external
> SASL library, I think such work has got basically zero to do with the
> actual problem.

I don't think that's accurate.  If we provide a better mechanism for
password-based authentication, even if it is through SASL, I feel pretty
confident that at least the Debian based distros (which universally
include SASL support for applications that support it) would support it
and might even switch to it for the default (once they were comfortable
with it and enough clients supported it), unless we told them not to.

That doesn't address existing installations, of course, and we'd have to
wait for non-libpq client to update, but things would certainly move
faster if we actually had something for things to move *to*, even if
that thing is SASL-based SCRAM, imv.
Thanks!
    Stephen