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 1nhqLD-0005Tn-0C for pgadmin-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 10:16:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nhqLB-0000ss-J5 for pgadmin-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 10:16:41 +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 1nhqLB-0000sj-3f for pgadmin-hackers@lists.postgresql.org; Fri, 22 Apr 2022 10:16:41 +0000 Received: from mail-ot1-x32f.google.com ([2607:f8b0:4864:20::32f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nhqL7-00057r-UC for pgadmin-hackers@postgresql.org; Fri, 22 Apr 2022 10:16:39 +0000 Received: by mail-ot1-x32f.google.com with SMTP id r14-20020a9d750e000000b00605446d683eso5140960otk.10 for ; Fri, 22 Apr 2022 03:16:37 -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=n8TjA9/+TUA4WVRYEDsKBsD45Qy2+d4oI69bWg1sSh0=; b=aIy/VptUblQrA48TCXlPb+BHl6El2wQ28vmZHLfxbwWDrw+i30YEFqkIMvmR+eIA/i t5rv1VQhiVkjwHufW+NjtDstE7qJkCRP/Et3jVRGvuSFcir3mulAvURrUXXI8P7KXX2s Vz9kvla4AQMUDnNRA5wsg3dMfDYNfTZJCI7G+94oMEfG96wxg+Y6WLdws5iAENFwBBbb p21GOOgZUWJuMTnPipNA6040JTHC7/1VHLRyE1bQPGbnKo8HMDYwBU9PWAd6/+i8mGMW pEq4O7xPS9mJjy+riK6qf+OGaES/WBitru6yGtO0xKOS4tYFaIXK7/peO+Qs55yDVAwH bzrQ== 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=n8TjA9/+TUA4WVRYEDsKBsD45Qy2+d4oI69bWg1sSh0=; b=qM1duxbBYyW5vy+tMsiSkfqfVKtb+2isO6eVLpLVaiG6ex4GSGCdGMq56gxD/dE1y/ pGEfVyy8QcEQpeUAtPtgH/qTQhkVvbkTVut9GHK6zSdW324GdU00gPfF6xcXgK9TKkhz TBsEJnGBkVlEhTlgnO3VrLmef3W3MQ8xPweNy+kz0/fOkCuX2QjSVzlTGVptugRJuDtV iM1dlSn3EBzNPtLH7TkuYJtz1IfqHW+/91e0T+oQyDQqqN5Suuq2kUBhjEAqQ8dXN3Gh 8WIMHNkUEIQlyAkbJDWyL+SPajGz+/vhNYKyXGWXk4XsyWUuwz0fYpysG13haw54soTg 8R/g== X-Gm-Message-State: AOAM531RKOXzm7DbqAh2JFBybEDrM6IU032s0DJaK9mtPHru/2TCrmuf L4Zmc6pOuSLZaJy+QOTYjRrw+X/SGGOBaCKUQAND8bjG+eQxEW8D/Y/w8mizv7fLQHBMkMVnpb6 B+WpdJultLSp9dsR2Dipm84zCQKRIoPe8uFRorRtADvJhtp7N7EmqpON764zX1hMczQc06gbpg4 2K5ah8utkAfhKjmApbi7ZxGU+/1XRy0FbAPgNRnSmFtJmY5AVW6qLNdovAIXCILtA= X-Google-Smtp-Source: ABdhPJyNT5Vl38qgtGf7zbBn4srAffmfcGudHDNmstL3W/tpJdmhTwtrP8ymF4Zfx8ricckn5zCKuoWyvuoso5cioJc= X-Received: by 2002:a9d:7a43:0:b0:605:7490:f71e with SMTP id z3-20020a9d7a43000000b006057490f71emr1406711otm.80.1650622597054; Fri, 22 Apr 2022 03:16:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aditya Toshniwal Date: Fri, 22 Apr 2022 15:46:00 +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="0000000000008e58dd05dd3b859c" 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 --0000000000008e58dd05dd3b859c Content-Type: text/plain; charset="UTF-8" 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. > > > >> >> 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" --0000000000008e58dd05dd3b859c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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


On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal &= lt;a= ditya.toshniwal@enterprisedb.com> wrote:
Hi Dave,

Generally, se= cure 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 sid= e, yes. This is server side though. It's not uncommon on the server sid= e to include hooks to allow key retrieval from external key management syst= ems.
Even on the server side. Like the AWS a= uth keys, or DB passwords. We can include hooks, not against it. Just discu= ssing.=C2=A0
=

=C2=A0

On Fri, Apr 22, 2022 at 2:38 P= M 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@e= nterprisedb.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.

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 - D= isable master password requirement when using alternative auth source

When pg= Admin stores a connection password, it encrypts it using a key that is form= ed 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 encrypt= ion key from, hence it uses the master password. And if the master is disab= led, there is no way to store the connection password.

To resolve this, we have adde= d an option to config.py (which defaults to None) for an alternate encrypti= on 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 u= ser.=C2=A0If 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 t= his is poorly thought out, and could easily be made much more secure and fl= exible than the current design.

Instead of effecti= vely 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-consciou= s environment, the script might query a centralised key management system t= o 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 foll= ows would offer that (but would not be recommended):

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

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

We would p= robably also want to allow use of a placeholder in which the username can b= e passed, e.g.

MASTER_ENCRYPTION_KEY_SCRIPT =3D &#= 39;/path/to/get-key.sh %u'

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

Yes, I think that is the way to go. I do= n't want to add a config parameter that doesn't seem like a good so= lution, 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.=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 A= rchitect=C2=A0| edbpostgres.com
"Don't Complain about Heat, Plant a TREE&qu= ot;
--0000000000008e58dd05dd3b859c--