Date: Tue, 18 Aug 2015 14:47:08 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Josh Berkus <josh@agliodbs.com>, Peter Eisentraut <peter_e@gmx.net>,
 Heikki Linnakangas <hlinnaka@iki.fi>,
 Michael Paquier <michael.paquier@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: WIP: SCRAM authentication
Message-ID: <20150818184708.GW3685@tamriel.snowman.net>
References: 
 <CA+TgmoYRkGAYC8XAz91qiwDK=wEqXgUbCoaPgiZDnde0cMSj5Q@mail.gmail.com>
 <20150812203732.GN3685@tamriel.snowman.net>
 <CA+Tgmob0T6MgQZ2fFityAsyXiX-rni0hU=LVtaFUv0oo7cdz2w@mail.gmail.com>
 <20150813013607.GS3685@tamriel.snowman.net>
 <WM!f47f2028fc1867e14926553022b78cd909807c8421cfe79fc83dece946e5dacb3c67bbaa75c363e878fc83c4680f7899!@asav-1.01.com>
 <55CCE12B.4030306@agliodbs.com>
 <20150818140637.GI3685@tamriel.snowman.net>
 <CA+TgmoacqxJSojswVDXE_rC_44woWiAXNizEzHTjqF_x_zJs_Q@mail.gmail.com>
 <20150818180730.GT3685@tamriel.snowman.net>
 <CA+TgmobP92kt+1acn1pdY0Kx-9xcaAWdhqOmu2yq216T0-2dJA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="5H4PyCrLBLHHAoJp"
Content-Disposition: inline
In-Reply-To: 
 <CA+TgmobP92kt+1acn1pdY0Kx-9xcaAWdhqOmu2yq216T0-2dJA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--5H4PyCrLBLHHAoJp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Tue, Aug 18, 2015 at 2:07 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > 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.
>=20
> OK, that's an interesting argument.  If SCRAM supports multiple
> password verifiers, and we support SCRAM, then I guess we should
> probably do that, too.  I still don't like it all that much, though.
> I think it's absolutely inevitable that people are going to end up
> with an account with 3 or more different passwords that can all be
> used to log into it, and that won't be good.  How do other systems
> avoid this pitfall?

They provide:

a) ability to configure which algorithms are used at change-password

  MIT Kerberos, kdc.conf: supported_enctypes and
                  kadmin: enctype-salttype

b) ability to configure which algorithms are allowed to be used at all

  MIT Kerberos, libdefaults: default_tgs_enctypes, default_tkt_enctypes,
  and permitted_enctypes, along with allow_weak_crypto which removes all
  those considered 'weak' from the other sets if set to false (the
  default).

c) password aging (to get users to change their password regularly, so
   you know after, say, 90 days of the change to the set configured in
   'a' that all users will have either expired passwords or have been
   updated to the latest set).

Note that we don't need quite so many options, these were done over time
for Kerberos and also address the different types of tickets involved in
that system.

Today, they discourage explicitly setting default_tgs_enctypes and
default_tkt_enctypes.  We really just need to allow configuration of
which should be stored at change-password time and the set of allowed
types.  I wouldn't want those to be the same because you'd want to
remove a compromised type as soon as possible from the "change-password"
set while still allowing those users to connect, to get them to change
their password using self-service (doing it all through the
adminstrators of the system would be very painful in large
organizations).

We also don't strictly need password aging, but it certainly helps.  We
definitely do need to provide administrators with easy interfaces
through functions and tools to manage the password verifiers used.

	Thanks!

		Stephen

--5H4PyCrLBLHHAoJp
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJV032rAAoJEO1sijiDR2RVu6MQAIXowVvOIND0l6N3hG8fcahN
ZqBofkSjcwXBEZd0SOQ9u9EK/DMnYhoa6u1hMNuqEUKN53QM0sp5lCeDm2Q5Yu+6
jaldb0rwQXa+V/08WvWONXZDsXlA9TPD6sK4l3wlSUbpSAcSUMDx1XvwR1a6N6yx
fggVTJiBYg5dPI83VlsPNkip0oh8d34GyG6QDpHC3Wk8wj1mVWlA3bJykP39+D89
YpmWAM8QksMlmuv9PWdQGJNkKx6fwTuRBuO65bAu4gT4I5Vmp56AaaV7+whbZULU
y2a7cMjF/rN6NaHm0ZEQLT3dk5c0NW18MgA3Qb+aFU8btWlvLii0Vvc+/tHpu2nY
ffHvGhi9J2gu+Tb4X5vEqYdj6lmO+2G5aywLP8NMgPODid+yQ30DbCvR2wkTqlni
KGUQ8c0lTNtjIKI2UrpuDgp3Tl5jg16Qp03dIvM0iRUglFZGJwF22arB3P4vNheA
4pRz9OxZjRTGs859fDM6xngo+4MU/9PGglX3grkqimeTHa5/FS5BEs4Cqct62OOz
PBCYBqkvH/lg2VIJmxxbKLYD2CV7FP416BMcUblKx+affwNqTDJgbI2FVBXxXrNg
grYHXs6jda8teGn+PP/mkjbK1769pcd/2yEPU8HYPYaf4+hm+ZmXqfV8MxF/0PSq
lSsuXHVQknEMj3/Lr1ud
=dnCF
-----END PGP SIGNATURE-----

--5H4PyCrLBLHHAoJp--