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 1nhqW3-00063B-74 for pgadmin-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 10:27:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nhqW2-0006Lf-3G for pgadmin-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 10:27:54 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nhqW1-0006LW-KA for pgadmin-hackers@lists.postgresql.org; Fri, 22 Apr 2022 10:27:53 +0000 Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nhqVw-0005DL-Ul for pgadmin-hackers@postgresql.org; Fri, 22 Apr 2022 10:27:52 +0000 Received: by mail-ed1-x52b.google.com with SMTP id b24so9856361edu.10 for ; Fri, 22 Apr 2022 03:27:48 -0700 (PDT) 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=rgTyaVV8dsAiuQ2822bZg/+CecaV9V3uL3nzNSdmmWo=; b=eU1b7HE0ng+XjWqtxb+izFP+pFfB5ryZIdWlYo7QBwwhEwuuAkb33Wq1jCQTW/ErhW 4DiD79991BvwVOZZ/uwo+qAoDbG4xkogY4d44pxBFHoP4AXPaWsC/CERcKgrRjpf8NCV NAbD8lF+uC74upNT9beMcrd0d08r7hY+f6dhZXzqiyyfQ9V0f3KpZobuU5KOYEQ6ZoYQ Ne48zuRcGh+D4gFMrRz59ccQyJ/COdNVsApFgKO4xa45AplE+LGU0uhIbjGsAyFiZ5Km t/OUyMWYTqoo7BqopIwpjJ6/K/DR0mPIorQZzfYDrKN15+t2WCXFicjfiLLIcmEa8GVi XACg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rgTyaVV8dsAiuQ2822bZg/+CecaV9V3uL3nzNSdmmWo=; b=kpvWkrLb/3py+97rYq7QNta+mr9N3LH40xd9TWFZwOuuJQpQGQzUlc6uqKo1NS5iTu 5XAuB9/hdc5GBUXgCL2y0FN+nttW9F0A1I/8RbhsFh3xBKZe397CVMqN7pVwAwJx0OkP UN6q8BzOWoQa3qnk6Jt4/KzooMnOAVI648bXGP1hA9d4GFWDwOEzHirgw7A4HJ4xvFSe kpS75Up8oklLsXjhzuhr54MRY0xhgp5eRtrsFjXtqWeNmbM5wA5riHGAyOysDuGNrU5K Gb5WGM0n2okajCI5HxV6szwCMsVVYlxFmhz+1tXYMTJkihHA0vBGY6bBveHQoeQA6TZx pBog== X-Gm-Message-State: AOAM531/HLwDjTR2ZSfafM3I+/yUSeJvGOs+NyFzULzait9MbYNpSBPa 4w2Ptbtbs4Ls9y9ssXFhmBS90/QR6plXpq8x0ZGrMQ== X-Google-Smtp-Source: ABdhPJzhD3Y4/LUmFq7S3maQEjiYXSWceEe+8pwu2Z05CjLDVpHV6Cwu+D5FwfNy6MbD+xXi61AIA2vv//XnGrXWVVg= X-Received: by 2002:a05:6402:909:b0:416:6f3c:5c1d with SMTP id g9-20020a056402090900b004166f3c5c1dmr4048768edz.108.1650623267501; Fri, 22 Apr 2022 03:27:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Fri, 22 Apr 2022 11:27:36 +0100 Message-ID: Subject: Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source To: Aditya Toshniwal Cc: Khushboo Vashi , Akshay Joshi , pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000848ecd05dd3bad72" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000848ecd05dd3bad72 Content-Type: text/plain; charset="UTF-8" On Fri, 22 Apr 2022 at 11:16, Aditya Toshniwal < aditya.toshniwal@enterprisedb.com> wrote: > > > On Fri, Apr 22, 2022 at 3:28 PM Dave Page wrote: > >> >> >> On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal < >> aditya.toshniwal@enterprisedb.com> wrote: >> >>> Hi Dave, >>> >>> Generally, secure keys like API_KEYS and all are supposed to be set in >>> env and are read by the app. Similar is the alternative encryption key. >>> People can run their scripts to export those config vars. >>> >> >> On the client side, yes. This is server side though. It's not uncommon on >> the server side to include hooks to allow key retrieval from external key >> management systems. >> > Even on the server side. Like the AWS auth keys, or DB passwords. We can > include hooks, not against it. Just discussing. > If you're using an AWS auth key on a server, then you're acting as a client for AWS - and DB passwords are a great example of why using a hook is a good thing; it's a very common request from users to have a secure way to retrieve credentials from an external service. Not to mention that a DB password is needed on the client side of a connection, not on the server side. On the server side, the database would query LDAP/Kerberos/whatever. A better example would be querying a key management service to unlock an encrypted disk or something like the service Bruce wrote for managing pgcrypto keys. > >> >> >>> >>> On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi < >>> khushboo.vashi@enterprisedb.com> wrote: >>> >>>> >>>> >>>> On Fri, Apr 22, 2022 at 2:34 PM Dave Page wrote: >>>> >>>>> >>>>> >>>>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi < >>>>> khushboo.vashi@enterprisedb.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi < >>>>>>> akshay.joshi@enterprisedb.com> wrote: >>>>>>> >>>>>>>> Thanks, the patch applied. >>>>>>>> >>>>>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi < >>>>>>>> khushboo.vashi@enterprisedb.com> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please find the attached patch to implement the feature #7012 - >>>>>>>>> Disable master password requirement when using alternative auth source >>>>>>>>> >>>>>>>>> When pgAdmin stores a connection password, it encrypts it using a >>>>>>>>> key that is formed either from the master password, or from the pgAdmin >>>>>>>>> login password for the user. In the case of auth methods such as OAuth, >>>>>>>>> Kerberos or Webserver, pgAdmin doesn't have access to anything long-lived >>>>>>>>> to form the encryption key from, hence it uses the master password. And if >>>>>>>>> the master is disabled, there is no way to store the connection password. >>>>>>>>> >>>>>>>>> To resolve this, we have added an option to config.py (which >>>>>>>>> defaults to None) for an alternate encryption key. pgAdmin would use this >>>>>>>>> if a) the master password is disabled AND b) there is no suitable >>>>>>>>> key/password available from the auth module for the user. If the >>>>>>>>> option is set to None, pgAdmin works as it does now. >>>>>>>>> >>>>>>>> >>>>>>> This change has just been brought to my attention through other >>>>>>> work. I think this is poorly thought out, and could easily be made much >>>>>>> more secure and flexible than the current design. >>>>>>> >>>>>>> Instead of effectively hard-coding a master password, which is only >>>>>>> slightly more secure than not having one in the first place, we should >>>>>>> allow the user to specify the path to a script or program that will return >>>>>>> a key. In a security-conscious environment, the script might query a >>>>>>> centralised key management system to securely retrieve the key to use. If a >>>>>>> user really wants the less secure implementation that this current patch >>>>>>> offers, then a simple script as follows would offer that (but would not be >>>>>>> recommended): >>>>>>> >>>>>>> ==== >>>>>>> #!/bin/sh >>>>>>> >>>>>>> echo "my secret key" >>>>>>> ==== >>>>>>> >>>>>>> We would probably also want to allow use of a placeholder in which >>>>>>> the username can be passed, e.g. >>>>>>> >>>>>>> MASTER_ENCRYPTION_KEY_SCRIPT = '/path/to/get-key.sh %u' >>>>>>> >>>>>>> Sounds good to me. >>>>>> Does this mean we are going to remove the current implementation >>>>>> which offers a hard-coded master password? >>>>>> >>>>>>> >>>>> Yes, I think that is the way to go. I don't want to add a config >>>>> parameter that doesn't seem like a good solution, and then remove it again >>>>> in the next release. >>>>> >>>>> Ok, In that case, we need to revert the patch and also need to update >>>> the RM #7012 regarding our proposal. >>>> >>>>> >>>>> -- >>>>> Dave Page >>>>> Blog: https://pgsnake.blogspot.com >>>>> Twitter: @pgsnake >>>>> >>>>> EDB: https://www.enterprisedb.com >>>>> >>>>> >>> >>> -- >>> Thanks, >>> Aditya Toshniwal >>> pgAdmin Hacker | Software Architect | *edbpostgres.com* >>> >>> "Don't Complain about Heat, Plant a TREE" >>> >> >> >> -- >> Dave Page >> Blog: https://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EDB: https://www.enterprisedb.com >> >> > > -- > Thanks, > Aditya Toshniwal > pgAdmin Hacker | Software Architect | *edbpostgres.com* > > "Don't Complain about Heat, Plant a TREE" > -- Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com --000000000000848ecd05dd3bad72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, 22 Apr 2022 at 11:16, Aditya = Toshniwal <aditya.t= oshniwal@enterprisedb.com> wrote:

On Fri, Apr 22, 2022 at 3:28 PM Dave Page <dpage@pgadmin.org> wrote:
=


On Fri, 22 Apr 2022 = at 10:49, Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:=
Hi Dave,
=
Generally, secure k= eys like API_KEYS and all are supposed to be set in env and are read by the= app. Similar is the alternative encryption key.
People can run their scripts to export those confi= g vars.

On the client side, yes= . This is server side though. It's not uncommon on the server side to i= nclude hooks to allow key retrieval from external key management systems.
Even on the server side. Like the AWS auth ke= ys, or DB passwords. We can include hooks, not against it. Just discussing.= =C2=A0

If you'= re using an AWS auth key on a server, then you're acting as a client fo= r AWS - and DB passwords are a great example of why using a hook is a good = thing; it's a very common request from users to have a secure way to re= trieve credentials from an external service. Not to mention that a DB passw= ord is needed on the client side of a connection,=C2=A0not on the server si= de. On the server side, the database would query LDAP/Kerberos/whatever.

A better example would be querying a key management = service to unlock an encrypted=C2=A0disk or something like the service Bruc= e wrote for managing pgcrypto keys.

=C2=A0

=C2=A0

On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi <khushboo.vashi@en= terprisedb.com> wrote:


On Fri, Apr 22, 2022 at 2:34 PM Dave Page <dpage@pgadmin.org> wrot= e:

On Fri, = 22 Apr 2022 at 09:57, Khushboo Vashi <khushboo.vashi@enterprisedb.com> = wrote:


On F= ri, Apr 22, 2022 at 2:01 PM Dave Page <dpage@pgadmin.org> wrote:
Hi

On Mon, 11 Apr 2022 at 09:20, Akshay Joshi &l= t;akshay= .joshi@enterprisedb.com> wrote:
Thanks, the patch applied.

On Mon, Apr 11, 2022 at 12:00= PM Khushboo Vashi <khushboo.vashi@enterprisedb.com> wrote:
Hi,

Please find the attached patch to implement the feature #7012 - Disable = master password requirement when using alternative auth source
=

When pgAdmin s= tores a connection password, it encrypts it using a key that is formed eith= er from the master password, or from the pgAdmin login password for the use= r. In the case of auth methods such as OAuth, Kerberos or Webserver, pgAdmi= n doesn't have access to anything long-lived to form the encryption key= from, hence it uses the master password. And if the master is disabled, th= ere is no way to store the connection password.

To resolve this, we have added an op= tion to config.py (which defaults to None) for an alternate encryption key.= pgAdmin would use this if a) the master password is disabled AND b) there = is no suitable key/password available from the auth module for the user.=C2= =A0I= f the option is set to None, pgAdmin works as it does now.=C2=A0

=

This change= has just been brought to my attention through other work. I think this is = poorly thought out, and could easily be made much more secure and flexible = than the current design.

Instead of effectively ha= rd-coding a master password, which is only slightly more secure than not ha= ving one in the first place, we should allow the user to specify the path t= o a script or program that will return a key. In a security-conscious envir= onment, the script might query a centralised key management system to secur= ely retrieve the key to use. If a user really wants the less secure impleme= ntation that this current patch offers, then a simple script as follows wou= ld offer that (but would not be recommended):

=3D= =3D=3D=3D
#!/bin/sh

echo "my secret= key"
=3D=3D=3D=3D

We would probabl= y also want to allow use of a placeholder in which the username can be pass= ed, e.g.

MASTER_ENCRYPTION_KEY_SCRIPT =3D '/pa= th/to/get-key.sh %u'

= Sounds good to me.=C2=A0
Does this mean we are going to remove th= e current implementation which offers a hard-coded master password?

Yes,= I think that is the way to go. I don't want to add a config parameter = that doesn't seem like a good solution, and then remove it again in the= next release.

Ok, In that c= ase, we need to revert the patch and also need to update the RM #7012 regar= ding our proposal.=C2=A0

--
=


--
Thanks,
Aditya Toshniwal=
pgAdmin Hacker=C2=A0| Software Architect=C2=A0| = edbpostgres.com
=
&q= uot;Don't Complain about Heat, Plant a TREE"


--
Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake<= br>
EDB: http= s://www.enterprisedb.com



--
Thanks,
Aditya Toshniwal=
pgAdmin Hacker=C2=A0| Software Architect=C2=A0| = edbpostgres.com
=
&q= uot;Don't Complain about Heat, Plant a TREE"


--
<= /div> --000000000000848ecd05dd3bad72--