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