Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source

On Fri, Apr 22, 2022 at 2:34 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
> khushboo(dot)vashi(at)enterprisedb(dot)com> wrote:
>
>>
>>
>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>>> Hi
>>>
>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <
>>> akshay(dot)joshi(at)enterprisedb(dot)com> wrote:
>>>
>>>> Thanks, the patch applied.
>>>>
>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
>>>> khushboo(dot)vashi(at)enterprisedb(dot)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
>
>