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 1nhpHN-00023K-DB for pgadmin-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 09:08:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nhpHM-0007QY-7D for pgadmin-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 09:08:40 +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 1nhpHL-0007Of-Uj for pgadmin-hackers@lists.postgresql.org; Fri, 22 Apr 2022 09:08:39 +0000 Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nhpHE-0006nt-Un for pgadmin-hackers@postgresql.org; Fri, 22 Apr 2022 09:08:39 +0000 Received: by mail-lj1-x22e.google.com with SMTP id bj36so8809382ljb.13 for ; Fri, 22 Apr 2022 02:08:32 -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=zUSEQ6y5EEBtUOEz9RG4y9OMUC6TPTYRcDMdgVCFEpk=; b=PJHd/+gnEllzQpWQxwkpR+jk9Gk8pN072aR+03IDoVXxBd6p0SOTiPcnwK9Z/cJglz onSW0VingGpQ5W0EUtwzZj9jYM5ok6pphTNmNCNDTKoO3EPSOEI74coJnUS3HuIQ7nlb 8tKZkEdbuGWN3JgUB9udZUbny75vJrSXXyowQFUhf5yVE5W5wOciB7UbnTfOhRSnlAPr wJfhab1hCGOlsXozJh1x/4cfYsZiWbc+uvN1CMcuUeRgV5LF3aJqD4UJc1DjPUtNmrXJ IjYlUdyVcyo5n8D2vvVgGki0H/H9XONuUJhC4BczZz7PannXoJtVUrnOqc9IK67Cz4Ny Ig8A== 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=zUSEQ6y5EEBtUOEz9RG4y9OMUC6TPTYRcDMdgVCFEpk=; b=WO0fjX1skQ8iGm8avegFbxO1jJkCfX+i+sP8XUiibztC/MQ8JNHk0kTi/f9lT4z06G 0VbobVsJQ/SgqElaLhqR1kZAtohBHTTxtvYEGMd20cC11R4m6Rf6R3RRab2evAKeM/kp lNCGgLO3BuKVyFehzT8veUCtnWDnKTg1Hona+8xay3oMT7Dqjuv0/IeHXOHeuMdjToBU heqxFOwPOkkDTJKYUlTQuStm99QFykRrVfdfp7xyS+YctepYVeCSpzG5UEHRM5VCDbz6 O4sSRfaApA56ayNSNwYirS5BmSBjpQDq6Wi/5ipPijQ5A3Rf1W1qp8gZ8IfdNP42ZTFz 7zjg== X-Gm-Message-State: AOAM530Kj0H3uKEWedVwj9AYVMVZNZRwCgBmPeB3xPMvqARx/PqQKcNj hob0LRbLB0UmT3nLE+XREQYLKOPbgpoTuLhsS9P8PZm0iNoPHDOPRoIo0sHzn7H77QmMTyPHK2D +cLJAl4uU7HZAwfz2fpIPv247CL1e10QRuT3aJScKOtUERpK2bPxsBwBN9Xn+Aycnj22fR7+e2O Q73rca8If4bLQrwhtARkaM3uWGWB6CBMi39ErTbSQBu14Z2KPuUCbPyzZHIw== X-Google-Smtp-Source: ABdhPJweKcVo/BeAsr7dsCaS9dakmoaLgJeqjvac9iYv44tH3PVGk42fTrkxIw0i+GlMIOiD62IN8Bgo41VOcxu6mM4= X-Received: by 2002:a2e:9104:0:b0:24e:e605:39b5 with SMTP id m4-20020a2e9104000000b0024ee60539b5mr2204668ljg.158.1650618511085; Fri, 22 Apr 2022 02:08:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Khushboo Vashi Date: Fri, 22 Apr 2022 14:38:20 +0530 Message-ID: Subject: Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source To: Dave Page Cc: Akshay Joshi , pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000036c8305dd3a92c6" 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 --000000000000036c8305dd3a92c6 Content-Type: text/plain; charset="UTF-8" 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 > > --000000000000036c8305dd3a92c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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


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


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

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

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

Please find the attached patch to implement the featur= e #7012 - Disable master password requirement when using alternative auth s= ource

When pgAdmin stores a connection password, it encrypts it using a key t= hat is formed either from the master password, or from the pgAdmin login pa= ssword 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 mast= er is disabled, there is no way to store the connection password.

To resolve this, w= e have added an option to config.py (which defaults to None) for an alterna= te encryption key. pgAdmin would use this if a) the master password is disa= bled AND b) there is no suitable key/password available from the auth modul= e for the user.=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 this is poorly thought out, and could easily be made much more se= cure 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 securi= ty-conscious environment, the script might query a centralised key manageme= nt system to securely retrieve the key to use. If a user really wants the l= ess secure implementation that this current patch offers, then a simple scr= ipt as follows would offer that (but would not be recommended):
<= br>
=3D=3D=3D=3D
#!/bin/sh

ech= o "my secret key"
=3D=3D=3D=3D

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

MASTER_ENCRYPTION_KEY_SC= RIPT =3D '/path/to/get-key.sh %u'

<= /blockquote>
Sounds good to me.=C2=A0
Does this mean we are g= oing to remove the current implementation which offers a hard-coded master = password?

Yes, I think that is the wa= y to go. I don't want to add a config parameter that doesn't seem l= ike 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.=C2= =A0

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

EDB: https://www.enterprisedb.com

=
--000000000000036c8305dd3a92c6--