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 1pu92q-00074F-SN for pgadmin-hackers@arkaria.postgresql.org; Wed, 03 May 2023 09:45:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pu92p-00078T-D7 for pgadmin-hackers@arkaria.postgresql.org; Wed, 03 May 2023 09:45:07 +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 1pu92o-000756-K6 for pgadmin-hackers@lists.postgresql.org; Wed, 03 May 2023 09:45:06 +0000 Received: from mail-yb1-xb31.google.com ([2607:f8b0:4864:20::b31]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1pu92h-000HO7-8O for pgadmin-hackers@postgresql.org; Wed, 03 May 2023 09:45:05 +0000 Received: by mail-yb1-xb31.google.com with SMTP id 3f1490d57ef6-b9d8b458e10so6805688276.1 for ; Wed, 03 May 2023 02:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1683107098; x=1685699098; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0LYoyLK7YpKta4XOQVJ0NkoA+jBjfD8y+xA9M45uOe0=; b=UMQYPVskdnsA/UsGuaZ0kVAFMPDA7WM16gQOlTf9yNKjdOCpsweJwR/hoT7SBiOWHS 6PH6R0SHbHLyTD5KVge057XglEXXT1In9YaYZL6es74F9IHNGKD9WDD6L5C5qZjB88pP fKVB/U7W/2aEybOdMTwxRu9wdA9e4YblLKtPY8j7RQR50+MXj4V1q79d8Y8VBQjHWvfl XChAP8EvJo9JbrBeJLDwUTViIVTqJ/ijdGQt8yDi/D8BYWfKbai/vpG/QLWVSlYk0bKG l8KX+V1D5mMzrQBvy/OR49uqFv30jZedKHqdxyVdt5+tmsQv6ONNNed9SYL/FRvx46Xi gXDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683107098; x=1685699098; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0LYoyLK7YpKta4XOQVJ0NkoA+jBjfD8y+xA9M45uOe0=; b=Ssa1eXUPHN4JCYguWmiNA7we5W58apGvgG44YhuSVYANahYo9W0NIxo3MtJk8o8M7s Gj3c1XI9r/D6tFydDRyOc5ZEf2H8ciwyZjEAmJGT3c+FPDdSZBIsM64gQ0OOMGYAkBBX 7EojlmuOHaHd/6d62o32mrAL7n5rXyyxulzUPmV5BAvyHp4t+pXLy7bkZgSC8Wny2DKi QrRvoxx7wgP0TSW0Nz3PaYL65KX+LKaJ7wQAssOBm2EVttNHrl/oFn6Oe+yaOBDBukPL 42cFz5+3jylbH2bpf7ThQD7M67TS0unsoihxcAtof9H1j2eqXrDaUgDlc+RqTnUNAcrF kJfg== X-Gm-Message-State: AC+VfDwzqkd6hm8EURZZzQevDFZxr3Te+NmhCt0sWL3+Tsk3CC97oSYA nNgZjP8h12Kr+6PVzUR5Y+gcR9dYGxqhTagENkLtAfHboiR2SAWmrKPQYByhXcwR1v/jgWptihY ByYDQ+0nTu1+FN/Vj5fJS0KGO0pUkAb4ydmmJXQh6K97f1h5zsNaNCysQ8Tk0XwyCRzxhfRTCLv UycCBmq9/LYYx2F4s/ANLXh+5bZLdxNrmiRyi/peS3dob9jzA6BYBBnefB8Q== X-Google-Smtp-Source: ACHHUZ7496AgqYooLfD3L1pOD3KDOWw3DPavycOqNn47+4+J8F1lSHrTeNAEqJ2EkG/hQX66OszOp1+53s08GQ4X/n8= X-Received: by 2002:a25:3258:0:b0:b92:49ed:7b55 with SMTP id y85-20020a253258000000b00b9249ed7b55mr19223238yby.2.1683107098439; Wed, 03 May 2023 02:44:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yogesh Mahajan Date: Wed, 3 May 2023 15:14:22 +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 , Aditya Toshniwal Content-Type: multipart/alternative; boundary="000000000000b8d76405fac6e88f" 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 --000000000000b8d76405fac6e88f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave/Team, As per the new design, pgAdmin should add a config to specify a path for script/program to retrieve an encryption key & use it to encrypt the passwords. The script/program will be at an application level and not a user level. This feature will be applicable only in case of server mode as we are going to use OS level secret storage for the same in Desktop mode. Thanks, Yogesh Mahajan EnterpriseDB On Fri, Apr 22, 2022 at 4:01=E2=80=AFPM Aditya Toshniwal < aditya.toshniwal@enterprisedb.com> wrote: > > 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 i= n >>>>> env and are read by the app. Similar is the alternative encryption ke= y. >>>>> 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 extern= al >>>> key management systems. >>>> >>> Even on the server side. Like the AWS auth keys, or DB passwords. We ca= n >>> 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 hoo= k >> 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/whateve= r. >> >> 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 t= he pgAdmin >>>>>>>>>>> login password for the user. In the case of auth methods such a= s OAuth, >>>>>>>>>>> Kerberos or Webserver, pgAdmin doesn't have access to anything = long-lived >>>>>>>>>>> to form the encryption key from, hence it uses the master passw= ord. 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 woul= d use this >>>>>>>>>>> if a) the master password is disabled AND b) there is no suitab= le >>>>>>>>>>> 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 mad= e 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 wi= ll return >>>>>>>>> a key. In a security-conscious environment, the script might quer= y a >>>>>>>>> centralised key management system to securely retrieve the key to= use. If a >>>>>>>>> user really wants the less secure implementation that this curren= t patch >>>>>>>>> offers, then a simple script as follows would offer that (but wou= ld 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 whic= h >>>>>>>>> the username can be passed, e.g. >>>>>>>>> >>>>>>>>> MASTER_ENCRYPTION_KEY_SCRIPT =3D '/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 i= t 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" > --000000000000b8d76405fac6e88f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave/Team,

As per the new design, pgAdmin should=C2=A0add a config to specify a pa= th for script/program to retrieve=C2=A0an encryption key & use it to en= crypt the passwords.
The script/program will be at an appli= cation level and not a user level. This feature will=C2=A0be applicable onl= y in case of server mode as we are going to use OS level secret storage for= the same in Desktop mode.

Thanks,
Yogesh Mahajan
EnterpriseDB


On Fri, Apr 22,= 2022 at 4:01=E2=80=AFPM Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:

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


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


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

On Fri, 2= 2 Apr 2022 at 10:49, Aditya Toshniwal <aditya.toshniwal@enterprisedb.com= > wrote:
Hi Dave,

Generall= y, 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 clien= t side, yes. This is server side though. It's not uncommon on the serve= r 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.=C2=A0

= 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 secur= e 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 th= e server side. On the server side, the database would query LDAP/Kerberos/w= hatever.

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

Got it. Thanks.

=C2=A0

=C2=A0
On Fri, A= pr 22, 2022 at 2:38 PM Khushboo Vashi <khushboo.vashi@enterprisedb.com>= wrote:


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.co= m> wrote:
Thanks, th= e patch applied.

On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <<= a href=3D"mailto:khushboo.vashi@enterprisedb.com" target=3D"_blank">khushbo= o.vashi@enterprisedb.com> wrote:
Hi,
Please find the atta= ched patch to implement the feature #7012 - Disable master password require= ment when using alternative auth source

When pgAdmin stores a connection pass= word, it encrypts it using a key that is formed either from the master pass= word, 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 acce= ss to anything long-lived to form the encryption key from, hence it uses th= e 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 (whic= h 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/pass= word available from the auth module for the user.=C2=A0If the option is set t= o None, pgAdmin works as it does now.=C2=A0


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

Instead of effectively hard-coding a master pa= ssword, 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 mi= ght query a centralised key management system to securely retrieve the key = to use. If a user really wants the less secure implementation that this cur= rent patch offers, then a simple script as follows would offer that (but wo= uld 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 the username can be passed, e.g.
MASTER_ENCRYPTION_KEY_SCRIPT =3D '/path/to/get-key.sh %u&#= 39;

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

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.
<= br clear=3D"all">
Ok, In that case, we need to rever= t the patch and also need to update the RM #7012 regarding our proposal.=C2= =A0

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

EDB: https://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 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"
--000000000000b8d76405fac6e88f--