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 1nhohm-0000I4-Jj for pgadmin-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 08:31:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nhohl-000499-Fa for pgadmin-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 08:31:53 +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 1nhohl-0003xq-3o for pgadmin-hackers@lists.postgresql.org; Fri, 22 Apr 2022 08:31:53 +0000 Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nhohh-0004HO-VV for pgadmin-hackers@postgresql.org; Fri, 22 Apr 2022 08:31:52 +0000 Received: by mail-ed1-x534.google.com with SMTP id f17so9538311edt.4 for ; Fri, 22 Apr 2022 01:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=57pn8Bwk3DLMp4rdM/eIa+Xk2hU5/sBvYJy6KesQ/qs=; b=Rzs88mgHln5Xb/Yd0XelQ0PKMEo/QehpR3yuyCZA4Nr7HW56gohwElWt0JnV7MNPyZ c+sCT4zEtxj89KKxl0MI/KezuWOMLT2Q5k2PKc9EnNV3wacKrnT2uxfmsVCTLwvo/0Ho Ge48nt8CWlT9hxiyHjEe+KUUNXEAqGeHUJDZ0oD3M+f8LZN0AG0BzmbVSEgWnKZOMX0d 5V+13vCDnlAFeFy1d7WT4MiAi94CcUzLORvPtMrLnyPQXFCmzgURFNf2YecEAgswrZm4 +3CFL1SJxNniyySysEg7O3c3mOPjAAEbcLR1cIRGf50mhNqWLeK5xG/e0r++Tjpk1EuE WJvQ== 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=57pn8Bwk3DLMp4rdM/eIa+Xk2hU5/sBvYJy6KesQ/qs=; b=iLo9GCBNfer4w6EXdu+OmHkuYjxE2PNDBUo5Gj0JwB3WLYtCDJ0Rx7CzAvLWH8WnF4 wKGwMzKVMBJrCZkGq0kQvQ+ZFcpSuRz7vPetVN15jQemJqZ8nK/cov3euRS/aIK5DYJE kYp6Jijdadm6AHK9/1jI+8zOLJxH2oJy6PzUQrDEemyXetxCls8MDqfH/zElzIx81kmz ty8xHC9WWJWjnb0BjYfA1lnVbgPB6Q96xlBhx9c7iOy2SMRIkemyjXGASDS6Z4ICrfOF K263+nTqj13s4QSRb/s2WU+Q9blWUbWYLakbqIee6AkdQIlPrQf3IMkuTP8vVMF3/fHe EjIA== X-Gm-Message-State: AOAM5308ccAR1sX3Wjxc2O27Lq5YVJwZPPbcuuM0a81qIT4uInMw9h/R VHwQL5Ea67d9CYykw7sgIiFS1U9axitV++k8GI4W0Q== X-Google-Smtp-Source: ABdhPJzeVyYUAbUn+i7bw4445svMXWK9m163Uab1YBxe4yawtwwWCmKWyjMaM4BANhGf+sUXVktnyHoN+SAaLXkbL9Y= X-Received: by 2002:a05:6402:2753:b0:423:3895:7031 with SMTP id z19-20020a056402275300b0042338957031mr3675399edd.170.1650616307518; Fri, 22 Apr 2022 01:31:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Fri, 22 Apr 2022 09:31:36 +0100 Message-ID: Subject: Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source To: Akshay Joshi Cc: Khushboo Vashi , pgadmin-hackers Content-Type: multipart/alternative; boundary="000000000000ab9cdb05dd3a0e6e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ab9cdb05dd3a0e6e Content-Type: text/plain; charset="UTF-8" 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' -- Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com --000000000000ab9cdb05dd3a0e6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <akshay.joshi@enterprisedb.com<= /a>> wrote:

Hi,
<= font color=3D"#000000" face=3D"verdana, sans-serif">
<= font face=3D"verdana, sans-serif" color=3D"#000000">Please find the attache= d patch to implement the feature #7012 - Disable master password requiremen= t when using alternative auth source

When pgAdmin stores a connection passwor= d, it encrypts it using a key that is formed either from the master passwor= d, or from the pgAdmin login password for the user. In the case of auth met= hods 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 m= aster 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 d= efaults 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/passwor= d available from the auth module for the user.=C2=A0If the option is set to Non= e, pgAdmin works as it does now.=C2=A0

<= /div>

This change has just been brought to = my attention through other work. I think this is poorly thought out, and co= uld easily be made much more secure and flexible than the current design.

Instead of effectively hard-coding a master passwor= d, which is only slightly more secure than not having one in the first plac= e, 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 q= uery a centralised key management system to securely retrieve the key to us= e. 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 n= ot 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'

--
<= div dir=3D"ltr">Dave Page
Blog: https://pgsnake.blogspot.com
Twitter: @pgsnake
EDB: https:= //www.enterprisedb.com

--000000000000ab9cdb05dd3a0e6e--