Horton

Re: Password identifiers, protocol aging and SCRAM protocol

Stephen Frost <sfrost@snowman.net>

View thread View on postgr.es
From: Stephen Frost <sfrost@snowman.net>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Magnus Hagander <magnus@hagander.net>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Robert Haas <robertmhaas@gmail.com>, Julian Markwort <julian.markwort@uni-muenster.de>, David Steele <david@pgmasters.net>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>, Valery Popov <v.popov@postgrespro.ru>
Date: 2016-07-06T22:51:41Z
Lists: pgsql-hackers 
* Michael Paquier (michael.paquier@gmail.com) wrote:
> On Tue, Jul 5, 2016 at 5:50 PM, Magnus Hagander <magnus@hagander.net> wrote:
> > On Tue, Jul 5, 2016 at 10:06 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
> > However, is there something that's fundamentally better with the OpenSSL
> > implementation? Or should we just keep *just* the #else branch in the code,
> > the part we've imported from OpenBSD?
> 
> Good question. I think that we want both, giving priority to OpenSSL
> if it is there. Usually their things prove to have more entropy, but I
> didn't look at their code to be honest. If we only use the OpenBSD
> stuff, it would be a good idea to refresh the in-core code. This is
> from OpenBSD of 2002.

I agree that we definitely want to use the OpenSSL functions when they
are available.

> > I'm not sure how common a build without openssl is in the real world though.
> > RPMs, DEBs, Windows installers etc all build with OpenSSL. But we probably
> > don't want to make it mandatory, no...
> 
> I don't think that it is this much common to have an enterprise-class
> build of Postgres without SSL, but each company has always its own
> reasons, so things could exist.

I agree that it's useful to have the support if PG isn't built with
OpenSSL for some reason.

Thanks!

Stephen

Commits

  1. Support SCRAM-SHA-256 authentication (RFC 5802 and 7677).

  2. Refactor SHA2 functions and move them to src/common/.

  3. Replace isMD5() with a more future-proof way to check if pw is encrypted.

  4. Remove bogus notice that older clients might not work with MD5 passwords.

  5. Refactor the code for verifying user's password.

  6. Replace PostmasterRandom() with a stronger source, second attempt.

  7. Remove support for (insecure) crypt authentication.