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 1nhpDI-0001rZ-ED for pgadmin-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 09:04:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nhpDG-0001nn-T2 for pgadmin-hackers@arkaria.postgresql.org; Fri, 22 Apr 2022 09:04:26 +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 1nhpDG-0001ne-KD for pgadmin-hackers@lists.postgresql.org; Fri, 22 Apr 2022 09:04:26 +0000 Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nhpDC-0006lm-8u for pgadmin-hackers@postgresql.org; Fri, 22 Apr 2022 09:04:25 +0000 Received: by mail-ej1-x62c.google.com with SMTP id l7so15138949ejn.2 for ; Fri, 22 Apr 2022 02:04:21 -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=s+fQX9BkxUoWTKmLWn1XBkVb8HCIdOou0QZ8siHKKuU=; b=YK0OyVwzc28LMhAaYaHXw8u4oBaLqCCFZr6DdOGphxRBbFgf0bP/eJwEihtqrxtRXQ YUxDI7+tNbPfRa82nhTN6EABVZJlqebNzr1Z1ME10I+cOXxfLO3z73j1gMwGBXnJI2Mg Yp5bS3eXBUsCtkqiEbow2vVahqvSGBufVbJyjJm6T4EE5Vp8zjgSblPLnmvyKwoNVuqq YLQ+VhE4srvQVOx3ZvYzvnxsr0vGDiuFk3XzwRkrIh2os1TpXDSmEbY6CoiwvZBMa2lC bsdsXVBG9c4x+72QpVMSqRy26U1TmmBSbOoNFrXDQzEeNi28gQIj0Ytgyfo8/hEOx6BP V8tw== 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=s+fQX9BkxUoWTKmLWn1XBkVb8HCIdOou0QZ8siHKKuU=; b=KrUSHy4y55OV1cjr7nuM1fkoyfkIkx9N0VRsPXMv4EC9ja5B0CleDLTFnoBMDsdotR +4/WvT0iTylDUUjkXfjcAoxFpbzAvFePdF9BxCrc8wiSOpxQEfdfSOaqsMJB4XpKUMHw zN/tjltrPOeWJYdtiU/bmjHfuKyIgRpgQg3uABMitj3Lg+GYAZnTHW81E7JYbUJlrvj8 DPbH7DOeONYeWcFsVGf8pIZQEPUPst2Ii69srkPXDtCgdlt7/N70XKVx74LLn6Abk4e8 pvndV9y8Xj0sK3h8Vpo6C4ZWQ/+wJjMZHFBK1FNr1I3E/F3BSVsQDfYtlF0egN+2E7nr 4H3A== X-Gm-Message-State: AOAM533LtRVa8Tsj94W1+qcTaled3el+lPsUp+NlibE36EBzuJpt7nYR 2FsJmbQGt+m8KPdCo0V/mEkgeYwLJhDVtKCDqGLVlg== X-Google-Smtp-Source: ABdhPJx1k3thSUgwLwT0j9/AL0+F/xCI4TX+25nIrXAvZYoDOUg9qQenwxf27V7qf+qUKoKOSXv+HjKkx8Bs4Nb+aHI= X-Received: by 2002:a17:907:7252:b0:6df:75cc:615e with SMTP id ds18-20020a170907725200b006df75cc615emr3157924ejc.683.1650618261169; Fri, 22 Apr 2022 02:04:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Fri, 22 Apr 2022 10:04:10 +0100 Message-ID: Subject: Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source To: Khushboo Vashi Cc: Akshay Joshi , pgadmin-hackers Content-Type: multipart/alternative; boundary="0000000000001e02d205dd3a8310" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000001e02d205dd3a8310 Content-Type: text/plain; charset="UTF-8" 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 >> 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. -- Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com --0000000000001e02d205dd3a8310 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, 22 Apr 2022 at 09:57, Khushbo= o Vashi <khushboo.vas= hi@enterprisedb.com> wrote:


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

On Mon, 11 Apr 20= 22 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<= /a>> wrote:
Hi,

Please find the attached patch to implement th= e feature #7012 - Disable master password requirement when using alternativ= e auth source

When pgAdmin stores a connection password, it encrypts it usin= g 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, Ke= rberos 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.<= /font>

To resolv= e this, we have added an option to config.py (which defaults to None) for a= n alternate encryption key. pgAdmin would use this if a) the master passwor= d is disabled AND b) there is no suitable key/password available from the a= uth module for the user.=C2=A0If the option is set to None, pgAdmin works as it= does now.=C2=A0



Instead of effectively hard-coding a master password, which is only sligh= tly 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 wa= nts the less secure implementation that this current patch offers, then a s= imple 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

<= /div>
We would probably also want to allow use of a placeholder in whic= h the username can be passed, e.g.

MASTER_ENCRYPTI= ON_KEY_SCRIPT =3D '/path/to/get-key.sh %u'



 --0000000000001e02d205dd3a8310--