Re: Rejecting weak passwords

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Rejecting weak passwords
Дата
Msg-id 14883.1255537525@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Rejecting weak passwords  (Dave Page <dpage@pgadmin.org>)
Ответы Re: Rejecting weak passwords  (Dave Page <dpage@pgadmin.org>)
Re: Rejecting weak passwords  (Magnus Hagander <magnus@hagander.net>)
Re: Rejecting weak passwords  (Robert Haas <robertmhaas@gmail.com>)
Re: Rejecting weak passwords  (Mark Mielke <mark@mark.mielke.cc>)
Список pgsql-hackers
Dave Page <dpage@pgadmin.org> writes:
> On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I see one, and I proposed masking passwords in any relevant queries
> before they were written to the stats or logs to mitigate that.

Let's see you do that (hint: "CREATD USER ... PASSWORD" is going to
throw a syntax error before you realize there's anything there that
might need to be protected).

And you ignored the question of insecure transmission pathways, anyway.
By the time the backend has figured out that it's got a CREATE USER
... PASSWORD command, it's already way too late if the client sent it
over a non-SSL connection.

Marko has pointed out repeatedly that a plugin can catch the worst
cases of insecure passwords even when given a pre-md5'd password.
So you can use a plugin that does it that way, or if you want you
can use a plugin that throws error on a pre-md5'd password.  I do
not see a reason for us to add a boatload of questionable logic
that favors the latter approach.
        regards, tom lane


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

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: alpha 2 release notes
Следующее
От: Boszormenyi Zoltan
Дата:
Сообщение: ECPG: store own copy of the prepared statement name