Re: [HACKERS] password_encryption, default and 'plain' support

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] password_encryption, default and 'plain' support
Дата
Msg-id 30294.1493828096@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] password_encryption, default and 'plain' support  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] password_encryption, default and 'plain' support  (Heikki Linnakangas <hlinnaka@iki.fi>)
Re: [HACKERS] password_encryption, default and 'plain' support  (Albe Laurenz <laurenz.albe@wien.gv.at>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, May 3, 2017 at 7:31 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> So, I propose that we remove support for password_encryption='plain' in
>> PostgreSQL 10. If you try to do that, you'll get an error.

> I have no idea how widely used that option is.

Is it possible that there are still client libraries that don't support
password encryption at all?  If so, are we willing to break them?
I'd say "yes" but it's worth thinking about.

>> Another question that's been touched upon but not explicitly discussed, is
>> whether we should change the default to "scram-sha-256". I propose that we
>> do that as well. If you need to stick to md5, e.g. because you use drivers
>> that don't support SCRAM yet, you can change it in postgresql.conf, but the
>> majority of installations that use modern clients will be more secure by
>> default.

> I think that we should investigate how many connectors have support
> for SCRAM or are likely to do so by the time v10 is released.  A *lot*
> of people are using connectors that are not based on libpq, especially
> JDBC but I think many of the others as well.

Yes, there's an awful lot out there besides libpq.  I do not think it is
reasonable at all to change this default in v10.  Maybe v11, depending on
how fast JDBC et al move.  If we try to force it in v10, we are going to
get a heck of a lot of complaints about "I changed my password and now
I can't get in at all using <x>", where <x> is also going to include
back-rev psql.  (And I'm not even considering the possibility of nasty
bugs in the SCRAM code.)  Making SCRAM the default in the first version
where it's even available is moving way too fast IMO.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] transition table behavior with inheritance appearsbroken (was: Declarative partitioning - another take)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] transition table behavior with inheritance appearsbroken (was: Declarative partitioning - another take)