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 1nhqZk-0006Kl-Rj for pgadmin-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 10:31:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nhqZj-0003t2-Jf for pgadmin-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 10:31:43 +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 1nhqZj-0003sA-9O for pgadmin-hackers@lists.postgresql.org; Fri, 22 Apr 2022 10:31:43 +0000 Received: from mail-oa1-x2c.google.com ([2001:4860:4864:20::2c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nhqZh-0007Np-5V for pgadmin-hackers@postgresql.org; Fri, 22 Apr 2022 10:31:42 +0000 Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-e68392d626so3102576fac.4 for ; Fri, 22 Apr 2022 03:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rWs2GkIPT7ok9U0d+dbIoWaDD0IhJGbo88aviMc5V3I=; b=U/4TulAviGE5SZxbAsBdla9B90PFkZ2G5WluS/9uMCiHQApZ+wiufL+fFhaom2VkfO JM+5YWMb1gSXcPPNYi1kfM30LdVECjyQsVnWNcUt+fhGOHtk6e5aC6X8Lk1e6t1rsBad T82vfWuxXMQ6k7Qhj/DAAlyNX4bZSUc6PsdkbEfNjw0ZgmBMz4cMmrZR8TjZkewsm2F5 sy24gRf+d7iVgiN+Om1p7uATJXgbDnHDs558Z0ghFIMXhyHGbtQb77x/GptrpG8FtS6z muHgc9buQuIvyK0XaR0lJ/qN41YeIr8e/57auo/5BlXQdN2e9sZ6wIGGTEAbeIGrZJHf dkvg== 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=rWs2GkIPT7ok9U0d+dbIoWaDD0IhJGbo88aviMc5V3I=; b=KknJoXat+6VCeHeibj3tl1bs4+RwkSS4qwq9j5h/olUZxbp8sATte0yFOSo723WOqq 7mP8+xEXHS0elHylhb3G4uuyvKEod0osUeLoVpHYxYpttXu//zrwqFC+KKNjMzMJodFa zKRhShh5Z/NLDwdF6isyi3a8Mptchm/kxIoexOkVUkFKvnFlUyJ/uSBgWl5W9X4BTKs2 7K6pBmvU+li1kzkqCywhLGDJUhyjTEmHe0SyJg5jE95P0Zxb0++kjSqV+GH4HuokCyi+ j8mWSJOK1XldGA2cpVkgtcl5SB6o3BgNsYpAoLg3Z2mTJrDE/PmDsElGI2IcWQt6ABEI y+Uw== X-Gm-Message-State: AOAM531fV5IfHyjih9UCE24WgHULIunaSSrOuQCwJykErFUoyxT4rrfh /0KUX5ljTwCSXRwsqI/XNpJqgqverrlNnn+9rbG6Oys3Wo8pIa4WAgv2avnNevepCRfx+eQscWD wOApzWaUKE2gRgpOtcu7pglrpTN+DcI45hCMqJbjhvhWoIhLjTm2pmn31k0qBqv1a25vS3jz4OQ vXxCE0WJwPh0u6QXwAFgxqE4Le4DRlj/GpBQs9ZR/dgve/GNHOpyfrSQQPMA== X-Google-Smtp-Source: ABdhPJzFF6S4B2ns28zJJCULJLpAxrLmECpqykSfBrxSUODJJ0XBEIE90+1nHFu4997VXu5lTOwqrXMa0Rw1EkDidyU= X-Received: by 2002:a05:6870:58d:b0:e5:ad36:3d05 with SMTP id m13-20020a056870058d00b000e5ad363d05mr5708633oap.0.1650623498776; Fri, 22 Apr 2022 03:31:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aditya Toshniwal Date: Fri, 22 Apr 2022 16:01:02 +0530 Message-ID: Subject: Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source To: Dave Page Cc: Khushboo Vashi , Akshay Joshi , pgadmin-hackers Content-Type: multipart/alternative; boundary="0000000000004d86e105dd3bbbbd" X-CLOUD-SEC-AV-Info: enterprisedb,google_mail,monitor X-CLOUD-SEC-AV-Sent: true X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000004d86e105dd3bbbbd Content-Type: text/plain; charset="UTF-8" On Fri, Apr 22, 2022 at 3:57 PM Dave Page wrote: > > > 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. > Got it. Thanks. > > > >> >>> >>> >>>> >>>> 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 > > -- Thanks, Aditya Toshniwal pgAdmin Hacker | Software Architect | *edbpostgres.com* "Don't Complain about Heat, Plant a TREE" --0000000000004d86e105dd3bbbbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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


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


On Fri, Apr 22, 2022 at 3:28 PM D= ave Page <dpage@p= gadmin.org> 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 sc= ripts to export those config vars.

<= div>On the client side, yes. This is server side though. It's not uncom= mon on the server side to include hooks to allow key retrieval from externa= l key management systems.
Even on the server= side. Like the AWS auth keys, or DB passwords. We can include hooks, not a= gainst it. Just discussing.=C2=A0

If you're using an AWS auth key on a server, then you&#= 39;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= ,=C2=A0not 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=C2=A0disk or some= thing like the service Bruce wrote for managing pgcrypto keys.
<= /div>

Got it. Thanks.
=C2=A0
=

=C2=A0

<= div class=3D"gmail_quote">
On Fri, Apr= 22, 2022 at 2:38 PM Khushboo Vashi <khushboo.vashi@enterprisedb.com> w= rote:


On Fri, Apr 22, 2022 at 2:34 PM Dave Page <= ;dpage@pgadmin.org> 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 <dpage@pgadmin.org> wrote:
Hi

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

<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Apr 11, 2022 at 12:00 PM Khush= boo 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 lo= gin password for the user. In the case of auth methods such as OAuth, Kerbe= ros 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 th= e master is disabled, there is no way to store the connection password.

To resolve t= his, we have added an option to config.py (which defaults to None) for an a= lternate encryption key. pgAdmin would use this if a) the master password i= s disabled AND b) there is no suitable key/password available from the auth= module for the user.=C2=A0If the option is set to None, pgAdmin works as it do= es now.=C2=A0

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

I= nstead 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 us= er 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 ma= nagement system to securely retrieve the key to use. If a user really wants= the less secure implementation that this current patch offers, then a simp= le script as follows would offer that (but would not be recommended):
=

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

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

We would probably also want to allow use of a placeholder in which t= he username can be passed, e.g.

MASTER_ENCRYPTION_= KEY_SCRIPT =3D '/path/to/get-key.sh %u'

<= /div>
Sounds good to me.=C2=A0
Does this mean we= are going to remove the current implementation which offers a hard-coded m= aster password?

Yes, I think that is th= e way to go. I don't want to add a config parameter that doesn't se= em like a good solution, and then remove it again in the next release.
Ok, In that case, we need to rev= ert the patch and also need to update the RM #7012 regarding our proposal.= =C2=A0

--
Dave Page
Bl= og: https://pgsn= ake.blogspot.com
Twitter: @pgsnake

EDB: https://www.enterprisedb.com
<= br>


--
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"


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



--
Thanks,
Aditya Toshniwal
pgAdmin Hacker=C2=A0| Software A= rchitect=C2=A0| edbpostgres.com
"Don't Complain about Heat, Plant a TREE&qu= ot;
--0000000000004d86e105dd3bbbbd--