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 1nhpuY-00045P-Bg for pgadmin-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 09:49:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nhpuW-00061c-Sy for pgadmin-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 09:49:08 +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 1nhpuW-0005o2-K5 for pgadmin-hackers@lists.postgresql.org; Fri, 22 Apr 2022 09:49:08 +0000 Received: from mail-oi1-x235.google.com ([2607:f8b0:4864:20::235]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nhpuR-00075R-Kr for pgadmin-hackers@postgresql.org; Fri, 22 Apr 2022 09:49:06 +0000 Received: by mail-oi1-x235.google.com with SMTP id a10so8448799oif.9 for ; Fri, 22 Apr 2022 02:49:02 -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=6+BZEqOsbFqK2hU+0E1w4wPp7o2oQjTDWmDm079bFbA=; b=EJPKxaaRn0gDu09pFk5Xb8fCxgPr5zF8n+tGZ3vqcCMXUjAXT6uSd0e6Rf4lNPDnN8 n8ESgWqUQ8eTJiSG2YIJcIgIIU75ZG7MAmjcJQz6mLlKSpjpfzbDw3S/BbVqhVrza+VX To+RdEJ7Oh/mdLnDVZ2lLxjHbsG9t4JTt9ek2GeCxT3FQkFdoGQ8sKJLGekoCfFmK21k 0Jv9UNOTmpqzfEkW1x3cIYPUPFAMyvEO4Xo3C4aUULH8XEfTN6DLkX9vMPg2jXGS+rxQ sXHxnf9sWSAlaearjZyNhYhJxWY3N8zFwJpnO/jvDesyT9EauG3L6dL1KxZkyHGAD5Vc 8raw== 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=6+BZEqOsbFqK2hU+0E1w4wPp7o2oQjTDWmDm079bFbA=; b=iSgpb9oQFFBMsR3ji0+HPZzUjtlya6O9XEekE6ZjEjZ0obNTGcoFpH8WipHNMzkDxR YCoZlt2ErTQ5EuPGzILPrLV4ZWJEAdR6eJdJbDhZ3NM10o41NBV34sLE8a04VGx66M7z 7nkG9G8YQMPn6zGvjN7xhbk7XoMDjRL8APKNpdn78KPxHgZjnGELc3Uhd9pICc3Gz9ed g7pJVbThJ6yBoIQSEE1Em595sNaX/kW2ji3cLql33suuw6KZBzLDhWu5XYRetd5Sf7Su 8LoUGBIjhxzJxsyx2IX+jYpw35m2pqUT+PntfNife64zUhlwq2qVIJbrAJLeC116y7Ha Us/w== X-Gm-Message-State: AOAM533Ek02FOh/jpPduAXlnGD45v9uEGf8D6SyHLRFsvI0hUJE4Im52 32wL/8royoyMsubowMAnAYW+k0c3rPcJyz2SJUnyU91bY2ys9Y9IFiA/TGkFQGVeQS0jhWhVzF7 dWQXItW/8isMRSJiSQqN7R78ksMdVTKuThK8GatqRwEnLtQVdL9WyGCEEE900QM85CHz6rIn9ZF sBxg/eA5Er1NUfMtgIgZHIPg81dghYx99LNCYyPYMwxbL8qe2AOdJb4U6QEw== X-Google-Smtp-Source: ABdhPJwjKZSSLhGBmrINXoPyZXFmLyDy2DgrjtrJGBaG9LdTb2lUZetHl33l+Ae4j/mmWqC2SDwh2Niecy//uBb/TP0= X-Received: by 2002:aca:3e41:0:b0:2ec:f51d:946 with SMTP id l62-20020aca3e41000000b002ecf51d0946mr6132182oia.138.1650620941410; Fri, 22 Apr 2022 02:49:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aditya Toshniwal Date: Fri, 22 Apr 2022 15:18:25 +0530 Message-ID: Subject: Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source To: Khushboo Vashi Cc: Dave Page , Akshay Joshi , pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000df44e705dd3b2220" 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 --000000000000df44e705dd3b2220 Content-Type: text/plain; charset="UTF-8" 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 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" --000000000000df44e705dd3b2220 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 alternati= ve encryption key.
People can run their scripts to export those config vars= .

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 A= rchitect=C2=A0| edbpostgres.com
"Don't Complain about Heat, Plant a TREE&qu= ot;
--000000000000df44e705dd3b2220--