Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Aug 18, 2015 at 10:06 AM, Stephen Frost <sfr...@snowman.net> wrote: > > That was the imputus for my earlier suggestion that in a release or two, > > we actively make pg_upgrade error (or perhaps warn first, then error, > > across two releases) if any of the old verifiers exist. > > I think there's basically no chance of that being acceptable. The > time at which it's possible to get rid of MD5 is going to vary widely > between installations. People who are using only libpq or > libpq-derived connectors will be able to get rid of it almost > immediately, if they want, though some won't. People who are using > obscure connectors that are poorly maintained may not even have a > version that supports SCRAM for 5 years. Think about how long it took > us to roll out the standard_conforming_strings changes, and there were > still people who got bitten.
I would expect there to be people who would run into pg_upgrade
complaining, that's why there would be the check. That's actually a
much better situation than what happened around
standard_conforming_strings. Further, users would be able to continue
with their existing version until they're ready to move or it goes out
of support, by which time, if their connector isn't updated, they should
be moving off of it also. We hear about people running 8.4 and older
because of some application which was never maintained or updated, and
that sucks, but it doesn't prevent us from making the changes we need to
make to move the project forward for the users who properly manage their
systems and use supported connectors.
> > The other concern with a single password verifier is that we're locking
> > ourselves into a one-verifier-per-role solution when most of the serious
> > solutions in use today (Active Directory, Kerberos, certificate based
> > systems) allow for more than one.
>
> So what? If you want to delegate authentication to AD or Kerberos, we
> already support that. That's not a reason to invent the same
> functionality inside the server. If you've got a tangible plan, other
> than SCRAM, that would require us to support multiple verifiers, then
> please say what it is. If not, the mere fact that some other people
> support it is not a reason why we should.
SCRAM itself, as has been discussed, supports multiple password
verifiers- that's a specific case all by itself, and it's done
specifically to address the issue that one or another of the algorithms
used is compromised, or that a new algorithm becomes available which is
better. AD and Kerberos support multiple password verifiers because of
this and that it allows you to migrate from one to the next without
having to do wholesale replacment across all systems involved. I bring
them up as examples of the advances in password-based authentication
which we've missed and because they are what users expect from current
password-based authentication systems, not because we support them and
therefore should just push everyone to them.
That said, if we aren't going to move password-based authentication in
PG to beyond the stone age it's currently in, then perhaps we should
just drop it completely and force users to pick a solution which is well
written, uses standard protocols, supports multiple ciphers and hashes
(in case one or more become a problem) and is updated to keep up with
the field. Obviously, that's a strawman and I appreciate that you are
not arguing to keep the status-quo, but I'm trying to make a point that
multiple password verifiers is part of modern authentication technology,
used by multiple standard and broadly installed solutions.
> In fact, we generally have
> taken the approach that needs which are already handled adequately by
> other tools to do not need to also be handled inside the database.
> That's not a perfect approach and we always argue about it around the
> edges, but generally, I think it's served us pretty well.
Unless we take my strawman literally, which I don't think we can, we
can't simply punt on pushing all password-based authentication out of
the server. If we agree that we need to support password-based
authentication then we should be working to maintain it as well as we
do the WAL and other subsystems.
I fully agree that we should leverage existing systems, technologies,
and protocols where possible, to avoid having to add a lot of extra
code which we have to maintain. I believe that this proposal already
meets that goal and we should move forward with full support for SCRAM.
That, in my view at least, means that we also need to provide for
multiple password verifiers.
Thanks!
Stephen
signature.asc
Description: Digital signature
