Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kz0Y1-0004Mx-RK for pgadmin-hackers@arkaria.postgresql.org; Mon, 11 Jan 2021 17:00:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kz0Y0-0001Mf-0x for pgadmin-hackers@arkaria.postgresql.org; Mon, 11 Jan 2021 17:00:04 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kz0Xz-0001MQ-04 for pgadmin-hackers@lists.postgresql.org; Mon, 11 Jan 2021 17:00:03 +0000 Received: from mail-ej1-x62a.google.com ([2a00:1450:4864:20::62a]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kz0Xv-0002Ga-0o for pgadmin-hackers@postgresql.org; Mon, 11 Jan 2021 17:00:02 +0000 Received: by mail-ej1-x62a.google.com with SMTP id d17so585868ejy.9 for ; Mon, 11 Jan 2021 08:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UUC2DjbS1yfOBsGdUraX400e+lM9L9XmGTr3x/IR9ug=; b=LOrKd6d7/r/g3vtHEOEw6v0ntAhSVe1yAWx7NEcD8FrWGEUk5lSOMFeHGbZe818HRa Ogn27GdHYOV8wOziHl0Z1ascxHVr/hvtrPnMmA2IWrzcdsaZXTS/0hbWlJg5qHvthKeq LpNIQcUVJPLEhMDNkHjOa9fXyW7M5vyrQseorFNrgZX8DDGysdgGJCT5u8BkmwREGt5M cLJ93HxtbQK78ROwI3WmFR7E0SWiISEvEgf/gkNAvj5dFlvW4/QxU590lLyHzDVxhPTh oJ/rNuh4mz73BoPAWSIMUvylXXRAc7py6LE+mdeIvb3QaBNXCVTml+zY6XMVI5RsZl0P 2N3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UUC2DjbS1yfOBsGdUraX400e+lM9L9XmGTr3x/IR9ug=; b=lXXKQq/F26T/4VtP2qQ1YoMrpl43eDwSVZbCe53qbf0veirJeWLQTFHhVyW2bRti2D Vr5fDvum76es6OcgeEZyD3ShXKRmSMqZVgiVCPJ1xA5dbNLdY0LVkuVaR6FA7HMHuugi BmQm3C/cs3kdu7tGKpWLsnOjQ04Wa1avpH+nf/gLbj+QyqagpbFdf++j2teBzO+jutUY mSJS3wPr7X+qU7t5P4L8myESySGjcuJZVQzxNYqDLmAQx+aYX1l940FsmjNS8MPfs+E/ 1TY/yJkDsH7n4oLLm/e6M2cpdMmHrCdq1XD3zbgYbxkvzPO+D7BPl4ZZf7llF3olE9dm Fuew== X-Gm-Message-State: AOAM530mOHVc4hCw56RQ4BIHY1DonzuEgdwc75Qo0WoFbkOPkTkpNDK2 jRc8XWHi3jn20pnAZCioCIBw1HXVOAnsub88EgGXQw== X-Google-Smtp-Source: ABdhPJy/O8rNEdVMiRsxjBlwQslUNIvsz1kdZyP8O2d/i8DDyN0CsqqACRZw4ymjvdxiJZu1rGUqLi0Nq2eIC9I+V+4= X-Received: by 2002:a17:906:d787:: with SMTP id pj7mr288161ejb.548.1610384398029; Mon, 11 Jan 2021 08:59:58 -0800 (PST) MIME-Version: 1.0 References: <20210102154130.GO27507@tamriel.snowman.net> <20210102155947.GQ27507@tamriel.snowman.net> <20210103173112.GR27507@tamriel.snowman.net> <20210111165011.GP27507@tamriel.snowman.net> In-Reply-To: <20210111165011.GP27507@tamriel.snowman.net> From: Dave Page Date: Mon, 11 Jan 2021 16:59:47 +0000 Message-ID: Subject: Re: [pgAdmin4][Patch] - RM 5457 - Kerberos Authentication - Phase 1 To: Stephen Frost Cc: Magnus Hagander , Khushboo Vashi , pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000ff2b8105b8a2d5a5" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000ff2b8105b8a2d5a5 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 11, 2021 at 4:50 PM Stephen Frost wrote: > Greetings, > > * Dave Page (dpage@pgadmin.org) wrote: > > On Mon, Jan 11, 2021 at 1:15 PM Magnus Hagander > wrote: > > > One question around that though -- when I click "save password" on a > > > database connection in pgadmin, it gets stored on the pgadmin server. > > > Isn't the key used to encrypt that derived from my password? If I'm > > > logging into pgadmin without a password (using kerberos),what would > > > that key be derived from? > > > > Also correct - and right now, the plan is to disable password saving if > > logged in using Kerberos. > > Disable password *saving*, or disable password *using*? > I'm pretty sure I wrote "saving". > > If you're saying that, when Kerberos is enabled, users will never be > prompted to provide a password because password-based auth has been > disabled, then perhaps that's reasonable. I don't know how useful such > a pgadmin setup would be, but at least it wouldn't be violating one of > the core values that using Kerberos brings. > > If you're saying that this is just disabling password *saving*, then > that implies that if someone actually wants to use pgadmin to, uh, log > into a PostgreSQL server which is configured for md5 or SCRAM auth or > LDAP based auth that the way that'll work is that pgadmin will prompt > the user for a password, which the user will provide and which will > then be sent from the client to the pgadmin system in the clear, and > which pgadmin will turn around and use to log into PG with, right? > Yes. > > It's the latter than I'm concerned with because it just wouldn't be > appropriate for a Kerberized service which is set up to use Kerberos to > then prompt the user for a password. > Well you never answered my previous question about that. Why is it appropriate for an FDW to do that, but not pgAdmin? Or for a user on a kerberised machine to use a web browser to access a non-kerberised site? Or frankly pretty much anything outside of a windows domain or kerberos environment that a user inside the environment might want to use? You basically seem to be saying that once a user logs into something using Kerberos, *everything* else they login to from there must also be done using Kerberos - which clearly will not be the case in the vast majority of deployments. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EDB: http://www.enterprisedb.com --000000000000ff2b8105b8a2d5a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 11, 2021 at 4:50 PM Steph= en Frost <sfrost@snowman.net&g= t; wrote:
Greeti= ngs,

* Dave Page (dpage@p= gadmin.org) wrote:
> On Mon, Jan 11, 2021 at 1:15 PM Magnus Hagander <magnus@hagander.net> wrote: > > One question around that though -- when I click "save passwo= rd" on a
> > database connection in pgadmin, it gets stored on the pgadmin ser= ver.
> > Isn't the key used to encrypt that derived from my password?= =C2=A0 If I'm
> > logging into pgadmin without a password (using kerberos),what wou= ld
> > that key be derived from?
>
> Also correct - and right now, the plan is to disable password saving i= f
> logged in using Kerberos.

Disable password *saving*, or disable password *using*?

I'm pretty sure I wrote "saving".
= =C2=A0

If you're saying that, when Kerberos is enabled, users will never be prompted to provide a password because password-based auth has been
disabled, then perhaps that's reasonable.=C2=A0 I don't know how us= eful such
a pgadmin setup would be, but at least it wouldn't be violating one of<= br> the core values that using Kerberos brings.

If you're saying that this is just disabling password *saving*, then that implies that if someone actually wants to use pgadmin to, uh, log
into a PostgreSQL server which is configured for md5 or SCRAM auth or
LDAP based auth that the way that'll work is that pgadmin will prompt the user for a password, which the user will provide and which will
then be sent from the client to the pgadmin system in the clear, and
which pgadmin will turn around and use to log into PG with, right?

Yes.
=C2=A0

It's the latter than I'm concerned with because it just wouldn'= t be
appropriate for a Kerberized service which is set up to use Kerberos to
then prompt the user for a password.

We= ll you never answered my previous question about that. Why is it appropriat= e for an FDW to do that, but not pgAdmin? Or for a user on a kerberised=C2= =A0machine to use a web browser to access a non-kerberised=C2=A0site? Or fr= ankly pretty much anything outside of a windows domain or kerberos environm= ent that a user inside the environment might want to use?

You basically seem to be saying that once a user logs into somethin= g using Kerberos, *everything* else they login to from there must also be d= one using Kerberos - which clearly will not be the case in the vast majorit= y of deployments.

--
Dave Page
Blog: http://pgsnake.blogspot.com
= Twitter: @pgsnake

EDB: http://www.enterprisedb.com

--000000000000ff2b8105b8a2d5a5--