Re: Password identifiers, protocol aging and SCRAM protocol
От | Michael Paquier |
---|---|
Тема | Re: Password identifiers, protocol aging and SCRAM protocol |
Дата | |
Msg-id | CAB7nPqQ9xZtiuBgwihY0S4kksMVRBJEVAVwbq0hfRPHw0xoOig@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Password identifiers, protocol aging and SCRAM protocol (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Password identifiers, protocol aging and SCRAM protocol
|
Список | pgsql-hackers |
On Thu, Jul 7, 2016 at 7:51 AM, Stephen Frost <sfrost@snowman.net> wrote: > * Michael Paquier (michael.paquier@gmail.com) wrote: >> > 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. OK, I am doing that at the end. And also while moving on... On another topic, here are some ideas to extend CREATE/ALTER ROLE to support SCRAM password directly: 1) protocol PASSWORD value, where protocol is { MD5 | PLAIN | SCRAM }, giving: CREATE ROLE foorole SCRAM PASSWORD value; 2) PASSWORD (protocol) value. 3) Just add SCRAM PASSWORD My mind is thinking about 1) as being the cleanest solution as this does not touch the defaults, which may change a couple of releases later. Other opinions? Note that I am also switching password_encryption to an enum, able to use as values on, off, md5, plain, scram. Of course, on => md5, off => plain to preserve the default. Other things that I am making conservative: - ENCRYPTED PASSWORD still implies MD5-encrypted password - UNENCRYPTED PASSWORD still implies plain text password - PASSWORD used alone depends on the value of password_encryption So it would be possible to move to scram by default by setting password_encryption to 'scram'. Objections are welcome, I am moving into something respecting the default behavior as much as possible. -- Michael
В списке pgsql-hackers по дате отправления: