Re: scram and \password

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: scram and \password
Date: 2017-05-01 16:04:10
Message-ID: CA+TgmobVav0oLXutZreDLz4fzpWKaPKAjsBcOxBom2+L-3n17A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 27, 2017 at 3:22 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> You could argue, that since we need to document how to avoid the query and
> the blocking, we might as well always require the application to run the
> "show password_encryption" query before calling PQencryptPasswordConn(). But
> I'd like to offer the convenience for the majority of applications that
> don't mind blocking.

I still think that's borrowing trouble. It just seems like too
critical of a thing to have a default -- if the convenience logic gets
it wrong and encrypts the password in a manner not intended by the
user, that could (a) amount to a security vulnerability or (b) lock
you out of your account. If you ask your significant other "where do
you want to go to dinner?" and can't get a clear answer out of them
after some period of time, it's probably OK to assume they don't care
that much and you can just pick something. If you ask the
commander-in-chief "which country should we fire the missiles at?" and
you don't get a clear and unambiguous answer, just picking something
is not a very good idea.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-05-01 16:06:54 Re: PQhost may return socket dir for network connection
Previous Message Robert Haas 2017-05-01 15:52:37 Re: Cached plans and statement generalization