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 1nhp78-0001YC-Bt for pgadmin-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 08:58:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nhp77-00023G-9K for pgadmin-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 08:58:05 +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 1nhp76-000237-I6 for pgadmin-hackers@lists.postgresql.org; Fri, 22 Apr 2022 08:58:05 +0000 Received: from mail-lf1-x129.google.com ([2a00:1450:4864:20::129]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nhp72-0006jH-BO for pgadmin-hackers@postgresql.org; Fri, 22 Apr 2022 08:58:03 +0000 Received: by mail-lf1-x129.google.com with SMTP id y32so13131584lfa.6 for ; Fri, 22 Apr 2022 01:57:59 -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=JO7TIpx/jhkPD44Y4cliQE71dFD5Z32wrN1p4EX3+DY=; b=eoFeRRt70hOxuVr4mr+todMtX+PaIr0dvev2Zd95HBmFFZIGKOmtcx3QiVM4tn31Th Xq2ErwG0r/WVIuOBLgP1VCovGTG4u0WgHj5EjGWhCtEmJWeWHUhM2U/F5RNhr1UGKRgH Sxttdsj6jn0hQ8sE70TPIpsHkPQqMIaecUICaa/f7NPy8Dr2g2QhpkhRl1C09IGYmR6c 8rselBHcq0dszG8Wu+7ptDNfjNdyeRRsy0diGmBoQiqumDZ4GQ6RViVrBlVPLYgjMJkc gtN6ls5IbfsmTBIm/BZOSgWY+Bc1Y0bnBoIRzbKWSu3Mwlf1lQjCkhSoQackTNNr5tcC OeMw== 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=JO7TIpx/jhkPD44Y4cliQE71dFD5Z32wrN1p4EX3+DY=; b=8BJtBz2iGp6JBUsnKq9IbnwmjXYxZPV7zH2l8Xlsv09+WtUOwMx49gRuMrZAO2MPoN W/krOYk9x8Pcg4qVpeA6IFSrIy1UCLwTf1FOKmDIVgFLFGj78mtu27ZqibYw2Jrr2ddd x6AkCjSc2iuJWNB0pcnz0YDvHzQ9uBWf7oR2lsrcS7UXyzc0XIfLPigZ61Zb3dZgCs30 TAyzIGYbIjdyEwqXLmOxULjoiVHtHGqRGz1WsdhsCrgBZ1Rg2l6uCJoWbwwg1tv0YaAz xqbYcnQA1gWEvyQryJxmTI1u+fz9Hriv+WYDl+pw+ZrRxXtPuiEa3Ut3f10zTHW284eC u2Yg== X-Gm-Message-State: AOAM532mdypjY0ut51Mpfb714fSQbXzyIlQs03yUQRaJP1X3CjqReF1r bOhgQzrIYG7Sgjpfh41MrbbHBQrB2U/DlWYSI0rbBiFJFo48FX1+bdYAaPoN1PltcvpR986b10H i4VjzzREvqnOGXfTyI1qsPFos3SbB+og9SEAWX0yJv9mERk2nudELohcwU9pi1+ajTYVbjc6yFm f9L7iRHfASK/4Y1n9mqaEZj6HFds61p6cRfrsTXtqSrqE3WTpbn/vTwZsd2A== X-Google-Smtp-Source: ABdhPJxE2gC3k/j8HKH0SA5kT8ggKNh1Rr1YeG7Eg4FNiA5Puob6Ppdv7f5fOIoTbxxYM0af814rIRZRtn+7BEiYiho= X-Received: by 2002:a05:6512:33a2:b0:470:a764:81fb with SMTP id i2-20020a05651233a200b00470a76481fbmr2348064lfg.493.1650617879176; Fri, 22 Apr 2022 01:57:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Khushboo Vashi Date: Fri, 22 Apr 2022 14:27:48 +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="0000000000005943fe05dd3a6c50" 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 --0000000000005943fe05dd3a6c50 Content-Type: text/plain; charset="UTF-8" On Fri, Apr 22, 2022 at 2:01 PM Dave Page wrote: > Hi > > On Mon, 11 Apr 2022 at 09:20, Akshay Joshi > 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? > -- > Dave Page > Blog: https://pgsnake.blogspot.com > Twitter: @pgsnake > > EDB: https://www.enterprisedb.com > > --0000000000005943fe05dd3a6c50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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

On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <akshay.joshi@enterprised= b.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 p= atch to implement the feature #7012 - Disable master password requirement w= hen 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 method= s 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 mast= er password. And if the master is disabled, there is no way to store the co= nnection password.

To resolve this, we have added an option to config.py (which defa= ults 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 a= vailable from the auth module 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 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 current pat= ch offers, then a simple script as follows would offer that (but would not = be recommended):

=3D=3D=3D=3D
#!/bin/sh<= /div>

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.

<= div>MASTER_ENCRYPTION_KEY_SCRIPT =3D '/path/to/get-key.sh %u'
=

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