public inbox for [email protected]help / color / mirror / Atom feed
[pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source 14+ messages / 7 participants [nested] [flat]
* [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source @ 2022-04-11 06:29 Khushboo Vashi <[email protected]> 0 siblings, 1 reply; 14+ messages in thread From: Khushboo Vashi @ 2022-04-11 06:29 UTC (permalink / raw) To: pgadmin-hackers 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. Thanks, Khushboo Attachments: [application/octet-stream] RM_7012.patch (7.2K, 3-RM_7012.patch) download | inline diff: diff --git a/docs/en_US/alternate_encryption_key.rst b/docs/en_US/alternate_encryption_key.rst new file mode 100644 index 000000000..4bc470a34 --- /dev/null +++ b/docs/en_US/alternate_encryption_key.rst @@ -0,0 +1,33 @@ +.. _alternate_encryption_key: + +********************************** +`Alternate Encryption Key`:index: +********************************** + +pgAdmin would use the alternate encryption key to secure and later unlock the saved server +passwords if the master password is disabled AND there is NO suitable key/password available +from the authentication module for the user in server mode. + +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 authentication 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 master password +is disabled pgAdmin would use the alternate encryption key, if it is set. + + +.. note:: You can set the alternate encryption key by setting the configuration + parameter *ALTERNATE_ENCRYPTION_KEY=<Key>*. + See :ref:`config_py` for more information on configuration parameters and how + they can be changed or enforced across an organisation. + +.. note:: If the master password and the alternate encryption key is disabled, + then all the saved passwords will be removed. + + +.. warning:: By setting this option, you should be fully aware of the potential security + risk of using the same encryption key for multiple users, that may be accessible to + sysadmins who would not normally be able to use pgAdmin. + + It is **not recommended** that you use the alternate encryption key instead of master password + if you use the *Save Password* option. diff --git a/docs/en_US/connecting.rst b/docs/en_US/connecting.rst index 8d1a3e4cf..df1874c37 100644 --- a/docs/en_US/connecting.rst +++ b/docs/en_US/connecting.rst @@ -38,6 +38,13 @@ It is set by the user and can be disabled using config. master_password +The Alternate Encryption Key is used to secure and later unlock saved server passwords. +It is **not recommended** to use the alternate encryption key. + +.. toctree:: + + alternate_encryption_key + After defining a server connection, right-click on the server name, and select *Connect to server* to authenticate with the server, and start using pgAdmin to manage objects that reside on the server. diff --git a/docs/en_US/master_password.rst b/docs/en_US/master_password.rst index ced1c7eb5..48edfdf49 100644 --- a/docs/en_US/master_password.rst +++ b/docs/en_US/master_password.rst @@ -5,7 +5,9 @@ ************************ A master password is required to secure and later unlock the saved server -passwords. This is applicable only for desktop mode users. +passwords. This is applicable for desktop mode users and for the auth methods +such as OAuth, Kerberos or Webserver where pgAdmin doesn't have access to anything +long-lived to form the encryption key. * You are prompted to enter the master password when you open the window for the first time after starting the application. @@ -23,15 +25,15 @@ passwords. This is applicable only for desktop mode users. See :ref:`config_py` for more information on configuration parameters and how they can be changed or enforced across an organisation. -.. note:: If the master password is disabled, then all the saved passwords will - be removed. +.. note:: If the master password and :ref:`alternate_encryption_key` is disabled, + then all the saved passwords will be removed. .. warning:: If the master password is disabled, then the saved passwords will - be encrypted using a key which is derived from information within the - configuration database. Use of a master password ensures that the encryption - key does not need to be stored anywhere, and thus prevents possible access - to server credentials if the configuration database becomes available to an - attacker. + be encrypted using the :ref:`alternate_encryption_key` or a key which is derived + from information within the configuration database. Use of a master password + ensures that the encryption key does not need to be stored anywhere, and thus + prevents possible access to server credentials if the configuration database + becomes available to an attacker. It is **strongly** recommended that you use the master password if you use the *Save Password* option. diff --git a/web/config.py b/web/config.py index f8733fe0a..14e3b3ec0 100644 --- a/web/config.py +++ b/web/config.py @@ -553,6 +553,27 @@ ALLOW_SAVE_TUNNEL_PASSWORD = False ########################################################################## MASTER_PASSWORD_REQUIRED = True +########################################################################## +# 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 or Kerberos, pgAdmin +# doesn't have access to anything long-lived to form the encryption key from, +# hence it uses the master password. + +# So, pgAdmin would use this alternate encryption key if +# a) the master password is disabled +# AND +# b) there is NO suitable key/pass available from the auth module for the user. + +# By setting this option, you should fully aware of the potential security +# risk of using the same encryption key for multiple users, +# that may be accessible to sysadmins who would not normally +# be able to use pgAdmin. +########################################################################## +ALTERNATE_ENCRYPTION_KEY = None + ########################################################################## # Allows pgAdmin4 to create session cookies based on IP address, so even # if a cookie is stolen, the attacker will not be able to connect to the diff --git a/web/pgadmin/browser/__init__.py b/web/pgadmin/browser/__init__.py index 4a7e18eb0..4525206ee 100644 --- a/web/pgadmin/browser/__init__.py +++ b/web/pgadmin/browser/__init__.py @@ -750,7 +750,8 @@ def index(): auth_source = session['auth_source_manager'][ 'source_friendly_name'] - if not config.MASTER_PASSWORD_REQUIRED and 'pass_enc_key' in session: + if not config.MASTER_PASSWORD_REQUIRED and 'pass_enc_key' in session\ + and not config.ALTERNATE_ENCRYPTION_KEY: session['allow_save_password'] = False response = Response(render_template( diff --git a/web/pgadmin/utils/master_password.py b/web/pgadmin/utils/master_password.py index 27db924cf..ba00963a7 100644 --- a/web/pgadmin/utils/master_password.py +++ b/web/pgadmin/utils/master_password.py @@ -33,6 +33,9 @@ def get_crypt_key(): elif config.MASTER_PASSWORD_REQUIRED \ and enc_key is None: return False, None + elif not config.MASTER_PASSWORD_REQUIRED and config.SERVER_MODE and \ + config.ALTERNATE_ENCRYPTION_KEY: + return True, config.ALTERNATE_ENCRYPTION_KEY elif not config.MASTER_PASSWORD_REQUIRED and config.SERVER_MODE and \ 'pass_enc_key' in session: return True, session['pass_enc_key'] ^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source @ 2022-04-11 08:19 Akshay Joshi <[email protected]> parent: Khushboo Vashi <[email protected]> 0 siblings, 1 reply; 14+ messages in thread From: Akshay Joshi @ 2022-04-11 08:19 UTC (permalink / raw) To: Khushboo Vashi <[email protected]>; +Cc: pgadmin-hackers Thanks, the patch applied. On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi < [email protected]> 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. > > Thanks, > Khushboo > -- *Thanks & Regards* *Akshay Joshi* *pgAdmin Hacker | Principal Software Architect* *EDB Postgres <http://edbpostgres.com>* *Mobile: +91 976-788-8246* ^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source @ 2022-04-22 08:31 Dave Page <[email protected]> parent: Akshay Joshi <[email protected]> 0 siblings, 1 reply; 14+ messages in thread From: Dave Page @ 2022-04-22 08:31 UTC (permalink / raw) To: Akshay Joshi <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; pgadmin-hackers Hi On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <[email protected]> wrote: > Thanks, the patch applied. > > On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi < > [email protected]> 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 ^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source @ 2022-04-22 08:57 Khushboo Vashi <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 1 reply; 14+ messages in thread From: Khushboo Vashi @ 2022-04-22 08:57 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Akshay Joshi <[email protected]>; pgadmin-hackers On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> wrote: > Hi > > On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <[email protected]> > wrote: > >> Thanks, the patch applied. >> >> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi < >> [email protected]> 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 > > ^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source @ 2022-04-22 09:04 Dave Page <[email protected]> parent: Khushboo Vashi <[email protected]> 0 siblings, 1 reply; 14+ messages in thread From: Dave Page @ 2022-04-22 09:04 UTC (permalink / raw) To: Khushboo Vashi <[email protected]>; +Cc: Akshay Joshi <[email protected]>; pgadmin-hackers On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi < [email protected]> wrote: > > > On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> wrote: > >> Hi >> >> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <[email protected]> >> wrote: >> >>> Thanks, the patch applied. >>> >>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi < >>> [email protected]> 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 ^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source @ 2022-04-22 09:08 Khushboo Vashi <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 1 reply; 14+ messages in thread From: Khushboo Vashi @ 2022-04-22 09:08 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Akshay Joshi <[email protected]>; pgadmin-hackers On Fri, Apr 22, 2022 at 2:34 PM Dave Page <[email protected]> wrote: > > > On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi < > [email protected]> wrote: > >> >> >> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> wrote: >> >>> Hi >>> >>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi < >>> [email protected]> wrote: >>> >>>> Thanks, the patch applied. >>>> >>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi < >>>> [email protected]> 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 > > ^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source @ 2022-04-22 09:48 Aditya Toshniwal <[email protected]> parent: Khushboo Vashi <[email protected]> 0 siblings, 1 reply; 14+ messages in thread From: Aditya Toshniwal @ 2022-04-22 09:48 UTC (permalink / raw) To: Khushboo Vashi <[email protected]>; +Cc: Dave Page <[email protected]>; Akshay Joshi <[email protected]>; pgadmin-hackers Hi Dave, Generally, secure keys like API_KEYS and all are supposed to be set in env and are read by the app. Similar is the alternative encryption key. People can run their scripts to export those config vars. On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi < [email protected]> wrote: > > > On Fri, Apr 22, 2022 at 2:34 PM Dave Page <[email protected]> wrote: > >> >> >> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi < >> [email protected]> wrote: >> >>> >>> >>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> wrote: >>> >>>> Hi >>>> >>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi < >>>> [email protected]> wrote: >>>> >>>>> Thanks, the patch applied. >>>>> >>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi < >>>>> [email protected]> 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 >> >> -- Thanks, Aditya Toshniwal pgAdmin Hacker | Software Architect | *edbpostgres.com* <http://edbpostgres.com; "Don't Complain about Heat, Plant a TREE" ^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source @ 2022-04-22 09:58 Dave Page <[email protected]> parent: Aditya Toshniwal <[email protected]> 0 siblings, 1 reply; 14+ messages in thread From: Dave Page @ 2022-04-22 09:58 UTC (permalink / raw) To: Aditya Toshniwal <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; Akshay Joshi <[email protected]>; pgadmin-hackers On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal < [email protected]> wrote: > Hi Dave, > > Generally, secure keys like API_KEYS and all are supposed to be set in env > and are read by the app. Similar is the alternative encryption key. > People can run their scripts to export those config vars. > On the client side, yes. This is server side though. It's not uncommon on the server side to include hooks to allow key retrieval from external key management systems. > > On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi < > [email protected]> wrote: > >> >> >> On Fri, Apr 22, 2022 at 2:34 PM Dave Page <[email protected]> wrote: >> >>> >>> >>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi < >>> [email protected]> wrote: >>> >>>> >>>> >>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> wrote: >>>> >>>>> Hi >>>>> >>>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi < >>>>> [email protected]> wrote: >>>>> >>>>>> Thanks, the patch applied. >>>>>> >>>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi < >>>>>> [email protected]> 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 >>> >>> > > -- > Thanks, > Aditya Toshniwal > pgAdmin Hacker | Software Architect | *edbpostgres.com* > <http://edbpostgres.com; > "Don't Complain about Heat, Plant a TREE" > -- Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source @ 2022-04-22 10:16 Aditya Toshniwal <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 2 replies; 14+ messages in thread From: Aditya Toshniwal @ 2022-04-22 10:16 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; Akshay Joshi <[email protected]>; pgadmin-hackers On Fri, Apr 22, 2022 at 3:28 PM Dave Page <[email protected]> wrote: > > > On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal < > [email protected]> wrote: > >> Hi Dave, >> >> Generally, secure keys like API_KEYS and all are supposed to be set in >> env and are read by the app. Similar is the alternative encryption key. >> People can run their scripts to export those config vars. >> > > On the client side, yes. This is server side though. It's not uncommon on > the server side to include hooks to allow key retrieval from external key > management systems. > Even on the server side. Like the AWS auth keys, or DB passwords. We can include hooks, not against it. Just discussing. > > > >> >> On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi < >> [email protected]> wrote: >> >>> >>> >>> On Fri, Apr 22, 2022 at 2:34 PM Dave Page <[email protected]> wrote: >>> >>>> >>>> >>>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Thanks, the patch applied. >>>>>>> >>>>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi < >>>>>>> [email protected]> 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 >>>> >>>> >> >> -- >> Thanks, >> Aditya Toshniwal >> pgAdmin Hacker | Software Architect | *edbpostgres.com* >> <http://edbpostgres.com; >> "Don't Complain about Heat, Plant a TREE" >> > > > -- > Dave Page > Blog: https://pgsnake.blogspot.com > Twitter: @pgsnake > > EDB: https://www.enterprisedb.com > > -- Thanks, Aditya Toshniwal pgAdmin Hacker | Software Architect | *edbpostgres.com* <http://edbpostgres.com; "Don't Complain about Heat, Plant a TREE" ^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source @ 2022-04-22 10:26 Ashesh Vashi <[email protected]> parent: Aditya Toshniwal <[email protected]> 1 sibling, 0 replies; 14+ messages in thread From: Ashesh Vashi @ 2022-04-22 10:26 UTC (permalink / raw) To: Aditya Toshniwal <[email protected]>; +Cc: Dave Page <[email protected]>; Khushboo Vashi <[email protected]>; Akshay Joshi <[email protected]>; pgadmin-hackers On Fri, Apr 22, 2022 at 3:46 PM Aditya Toshniwal < [email protected]> wrote: > > > On Fri, Apr 22, 2022 at 3:28 PM Dave Page <[email protected]> wrote: > >> >> >> On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal < >> [email protected]> wrote: >> >>> Hi Dave, >>> >>> Generally, secure keys like API_KEYS and all are supposed to be set in >>> env and are read by the app. Similar is the alternative encryption key. >>> People can run their scripts to export those config vars. >>> >> >> On the client side, yes. This is server side though. It's not uncommon on >> the server side to include hooks to allow key retrieval from external key >> management systems. >> > Even on the server side. Like the AWS auth keys, or DB passwords. We can > include hooks, not against it. Just discussing. > Environment variables are good for static values. Here - we're talking about dynamic data (per user security key), hence - hooks are the best way forward. -- Ashesh > >> >> >>> >>> On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi < >>> [email protected]> wrote: >>> >>>> >>>> >>>> On Fri, Apr 22, 2022 at 2:34 PM Dave Page <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Thanks, the patch applied. >>>>>>>> >>>>>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi < >>>>>>>> [email protected]> 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 >>>>> >>>>> >>> >>> -- >>> Thanks, >>> Aditya Toshniwal >>> pgAdmin Hacker | Software Architect | *edbpostgres.com* >>> <http://edbpostgres.com; >>> "Don't Complain about Heat, Plant a TREE" >>> >> >> >> -- >> Dave Page >> Blog: https://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EDB: https://www.enterprisedb.com >> >> > > -- > Thanks, > Aditya Toshniwal > pgAdmin Hacker | Software Architect | *edbpostgres.com* > <http://edbpostgres.com; > "Don't Complain about Heat, Plant a TREE" > ^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source @ 2022-04-22 10:27 Dave Page <[email protected]> parent: Aditya Toshniwal <[email protected]> 1 sibling, 1 reply; 14+ messages in thread From: Dave Page @ 2022-04-22 10:27 UTC (permalink / raw) To: Aditya Toshniwal <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; Akshay Joshi <[email protected]>; pgadmin-hackers On Fri, 22 Apr 2022 at 11:16, Aditya Toshniwal < [email protected]> wrote: > > > On Fri, Apr 22, 2022 at 3:28 PM Dave Page <[email protected]> wrote: > >> >> >> On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal < >> [email protected]> wrote: >> >>> Hi Dave, >>> >>> Generally, secure keys like API_KEYS and all are supposed to be set in >>> env and are read by the app. Similar is the alternative encryption key. >>> People can run their scripts to export those config vars. >>> >> >> On the client side, yes. This is server side though. It's not uncommon on >> the server side to include hooks to allow key retrieval from external key >> management systems. >> > Even on the server side. Like the AWS auth keys, or DB passwords. We can > include hooks, not against it. Just discussing. > If you're using an AWS auth key on a server, then you're acting as a client for AWS - and DB passwords are a great example of why using a hook is a good thing; it's a very common request from users to have a secure way to retrieve credentials from an external service. Not to mention that a DB password is needed on the client side of a connection, not on the server side. On the server side, the database would query LDAP/Kerberos/whatever. A better example would be querying a key management service to unlock an encrypted disk or something like the service Bruce wrote for managing pgcrypto keys. > >> >> >>> >>> On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi < >>> [email protected]> wrote: >>> >>>> >>>> >>>> On Fri, Apr 22, 2022 at 2:34 PM Dave Page <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Thanks, the patch applied. >>>>>>>> >>>>>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi < >>>>>>>> [email protected]> 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 >>>>> >>>>> >>> >>> -- >>> Thanks, >>> Aditya Toshniwal >>> pgAdmin Hacker | Software Architect | *edbpostgres.com* >>> <http://edbpostgres.com; >>> "Don't Complain about Heat, Plant a TREE" >>> >> >> >> -- >> Dave Page >> Blog: https://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EDB: https://www.enterprisedb.com >> >> > > -- > Thanks, > Aditya Toshniwal > pgAdmin Hacker | Software Architect | *edbpostgres.com* > <http://edbpostgres.com; > "Don't Complain about Heat, Plant a TREE" > -- Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source @ 2022-04-22 10:31 Aditya Toshniwal <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 1 reply; 14+ messages in thread From: Aditya Toshniwal @ 2022-04-22 10:31 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; Akshay Joshi <[email protected]>; pgadmin-hackers On Fri, Apr 22, 2022 at 3:57 PM Dave Page <[email protected]> wrote: > > > On Fri, 22 Apr 2022 at 11:16, Aditya Toshniwal < > [email protected]> wrote: > >> >> >> On Fri, Apr 22, 2022 at 3:28 PM Dave Page <[email protected]> wrote: >> >>> >>> >>> On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal < >>> [email protected]> wrote: >>> >>>> Hi Dave, >>>> >>>> Generally, secure keys like API_KEYS and all are supposed to be set in >>>> env and are read by the app. Similar is the alternative encryption key. >>>> People can run their scripts to export those config vars. >>>> >>> >>> On the client side, yes. This is server side though. It's not uncommon >>> on the server side to include hooks to allow key retrieval from external >>> key management systems. >>> >> Even on the server side. Like the AWS auth keys, or DB passwords. We can >> include hooks, not against it. Just discussing. >> > > If you're using an AWS auth key on a server, then you're acting as a > client for AWS - and DB passwords are a great example of why using a hook > is a good thing; it's a very common request from users to have a secure way > to retrieve credentials from an external service. Not to mention that a DB > password is needed on the client side of a connection, not on the server > side. On the server side, the database would query LDAP/Kerberos/whatever. > > A better example would be querying a key management service to unlock an > encrypted disk or something like the service Bruce wrote for managing > pgcrypto keys. > Got it. Thanks. > > > >> >>> >>> >>>> >>>> On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Apr 22, 2022 at 2:34 PM Dave Page <[email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> wrote: >>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Thanks, the patch applied. >>>>>>>>> >>>>>>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi < >>>>>>>>> [email protected]> 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 >>>>>> >>>>>> >>>> >>>> -- >>>> Thanks, >>>> Aditya Toshniwal >>>> pgAdmin Hacker | Software Architect | *edbpostgres.com* >>>> <http://edbpostgres.com; >>>> "Don't Complain about Heat, Plant a TREE" >>>> >>> >>> >>> -- >>> Dave Page >>> Blog: https://pgsnake.blogspot.com >>> Twitter: @pgsnake >>> >>> EDB: https://www.enterprisedb.com >>> >>> >> >> -- >> Thanks, >> Aditya Toshniwal >> pgAdmin Hacker | Software Architect | *edbpostgres.com* >> <http://edbpostgres.com; >> "Don't Complain about Heat, Plant a TREE" >> > > > -- > Dave Page > Blog: https://pgsnake.blogspot.com > Twitter: @pgsnake > > EDB: https://www.enterprisedb.com > > -- Thanks, Aditya Toshniwal pgAdmin Hacker | Software Architect | *edbpostgres.com* <http://edbpostgres.com; "Don't Complain about Heat, Plant a TREE" ^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source @ 2023-05-03 09:44 Yogesh Mahajan <[email protected]> parent: Aditya Toshniwal <[email protected]> 0 siblings, 1 reply; 14+ messages in thread From: Yogesh Mahajan @ 2023-05-03 09:44 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; Akshay Joshi <[email protected]>; pgadmin-hackers; Aditya Toshniwal <[email protected]> Hi Dave/Team, As per the new design, pgAdmin should add a config to specify a path for script/program to retrieve an encryption key & use it to encrypt the passwords. The script/program will be at an application level and not a user level. This feature will be applicable only in case of server mode as we are going to use OS level secret storage for the same in Desktop mode. Thanks, Yogesh Mahajan EnterpriseDB On Fri, Apr 22, 2022 at 4:01 PM Aditya Toshniwal < [email protected]> wrote: > > On Fri, Apr 22, 2022 at 3:57 PM Dave Page <[email protected]> wrote: > >> >> >> On Fri, 22 Apr 2022 at 11:16, Aditya Toshniwal < >> [email protected]> wrote: >> >>> >>> >>> On Fri, Apr 22, 2022 at 3:28 PM Dave Page <[email protected]> wrote: >>> >>>> >>>> >>>> On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal < >>>> [email protected]> wrote: >>>> >>>>> Hi Dave, >>>>> >>>>> Generally, secure keys like API_KEYS and all are supposed to be set in >>>>> env and are read by the app. Similar is the alternative encryption key. >>>>> People can run their scripts to export those config vars. >>>>> >>>> >>>> On the client side, yes. This is server side though. It's not uncommon >>>> on the server side to include hooks to allow key retrieval from external >>>> key management systems. >>>> >>> Even on the server side. Like the AWS auth keys, or DB passwords. We can >>> include hooks, not against it. Just discussing. >>> >> >> If you're using an AWS auth key on a server, then you're acting as a >> client for AWS - and DB passwords are a great example of why using a hook >> is a good thing; it's a very common request from users to have a secure way >> to retrieve credentials from an external service. Not to mention that a DB >> password is needed on the client side of a connection, not on the server >> side. On the server side, the database would query LDAP/Kerberos/whatever. >> >> A better example would be querying a key management service to unlock an >> encrypted disk or something like the service Bruce wrote for managing >> pgcrypto keys. >> > > Got it. Thanks. > >> >> >> >>> >>>> >>>> >>>>> >>>>> On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Apr 22, 2022 at 2:34 PM Dave Page <[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Thanks, the patch applied. >>>>>>>>>> >>>>>>>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi < >>>>>>>>>> [email protected]> 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 >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> Thanks, >>>>> Aditya Toshniwal >>>>> pgAdmin Hacker | Software Architect | *edbpostgres.com* >>>>> <http://edbpostgres.com; >>>>> "Don't Complain about Heat, Plant a TREE" >>>>> >>>> >>>> >>>> -- >>>> Dave Page >>>> Blog: https://pgsnake.blogspot.com >>>> Twitter: @pgsnake >>>> >>>> EDB: https://www.enterprisedb.com >>>> >>>> >>> >>> -- >>> Thanks, >>> Aditya Toshniwal >>> pgAdmin Hacker | Software Architect | *edbpostgres.com* >>> <http://edbpostgres.com; >>> "Don't Complain about Heat, Plant a TREE" >>> >> >> >> -- >> Dave Page >> Blog: https://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EDB: https://www.enterprisedb.com >> >> > > -- > Thanks, > Aditya Toshniwal > pgAdmin Hacker | Software Architect | *edbpostgres.com* > <http://edbpostgres.com; > "Don't Complain about Heat, Plant a TREE" > ^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source @ 2023-05-03 13:41 Dave Page <[email protected]> parent: Yogesh Mahajan <[email protected]> 0 siblings, 0 replies; 14+ messages in thread From: Dave Page @ 2023-05-03 13:41 UTC (permalink / raw) To: Yogesh Mahajan <[email protected]>; +Cc: Khushboo Vashi <[email protected]>; Akshay Joshi <[email protected]>; pgadmin-hackers; Aditya Toshniwal <[email protected]> On Wed, 3 May 2023 at 10:45, Yogesh Mahajan <[email protected]> wrote: > Hi Dave/Team, > > As per the new design, pgAdmin should add a config to specify a path for > script/program to retrieve an encryption key & use it to encrypt the > passwords. > Right. > The script/program will be at an application level and not a user level. > This feature will be applicable only in case of server mode as we are going > to use OS level secret storage for the same in Desktop mode. > Yes. However, we can pass parameters to the hook. For example, we might do something like: MASTER_PASSWORD_HOOK = '/path/to/key_client.sh %U %E' Where at runtime %U is replaced with the username and %E is replaced with the user's email address. Those are just examples of course - there may be other parameters that make sense to make available. > > Thanks, > Yogesh Mahajan > EnterpriseDB > > > On Fri, Apr 22, 2022 at 4:01 PM Aditya Toshniwal < > [email protected]> wrote: > >> >> On Fri, Apr 22, 2022 at 3:57 PM Dave Page <[email protected]> wrote: >> >>> >>> >>> On Fri, 22 Apr 2022 at 11:16, Aditya Toshniwal < >>> [email protected]> wrote: >>> >>>> >>>> >>>> On Fri, Apr 22, 2022 at 3:28 PM Dave Page <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Dave, >>>>>> >>>>>> Generally, secure keys like API_KEYS and all are supposed to be set >>>>>> in env and are read by the app. Similar is the alternative encryption key. >>>>>> People can run their scripts to export those config vars. >>>>>> >>>>> >>>>> On the client side, yes. This is server side though. It's not uncommon >>>>> on the server side to include hooks to allow key retrieval from external >>>>> key management systems. >>>>> >>>> Even on the server side. Like the AWS auth keys, or DB passwords. We >>>> can include hooks, not against it. Just discussing. >>>> >>> >>> If you're using an AWS auth key on a server, then you're acting as a >>> client for AWS - and DB passwords are a great example of why using a hook >>> is a good thing; it's a very common request from users to have a secure way >>> to retrieve credentials from an external service. Not to mention that a DB >>> password is needed on the client side of a connection, not on the server >>> side. On the server side, the database would query LDAP/Kerberos/whatever. >>> >>> A better example would be querying a key management service to unlock an >>> encrypted disk or something like the service Bruce wrote for managing >>> pgcrypto keys. >>> >> >> Got it. Thanks. >> >>> >>> >>> >>>> >>>>> >>>>> >>>>>> >>>>>> On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Apr 22, 2022 at 2:34 PM Dave Page <[email protected]> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Thanks, the patch applied. >>>>>>>>>>> >>>>>>>>>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi < >>>>>>>>>>> [email protected]> 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 >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Thanks, >>>>>> Aditya Toshniwal >>>>>> pgAdmin Hacker | Software Architect | *edbpostgres.com* >>>>>> <http://edbpostgres.com; >>>>>> "Don't Complain about Heat, Plant a TREE" >>>>>> >>>>> >>>>> >>>>> -- >>>>> Dave Page >>>>> Blog: https://pgsnake.blogspot.com >>>>> Twitter: @pgsnake >>>>> >>>>> EDB: https://www.enterprisedb.com >>>>> >>>>> >>>> >>>> -- >>>> Thanks, >>>> Aditya Toshniwal >>>> pgAdmin Hacker | Software Architect | *edbpostgres.com* >>>> <http://edbpostgres.com; >>>> "Don't Complain about Heat, Plant a TREE" >>>> >>> >>> >>> -- >>> Dave Page >>> Blog: https://pgsnake.blogspot.com >>> Twitter: @pgsnake >>> >>> EDB: https://www.enterprisedb.com >>> >>> >> >> -- >> Thanks, >> Aditya Toshniwal >> pgAdmin Hacker | Software Architect | *edbpostgres.com* >> <http://edbpostgres.com; >> "Don't Complain about Heat, Plant a TREE" >> > -- Dave Page VP, Chief Architect, Database Infrastructure Blog: https://www.enterprisedb.com/dave-page Twitter: @pgsnake EDB: https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 14+ messages in thread
end of thread, other threads:[~2023-05-03 13:41 UTC | newest] Thread overview: 14+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2022-04-11 06:29 [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source Khushboo Vashi <[email protected]> 2022-04-11 08:19 ` Akshay Joshi <[email protected]> 2022-04-22 08:31 ` Dave Page <[email protected]> 2022-04-22 08:57 ` Khushboo Vashi <[email protected]> 2022-04-22 09:04 ` Dave Page <[email protected]> 2022-04-22 09:08 ` Khushboo Vashi <[email protected]> 2022-04-22 09:48 ` Aditya Toshniwal <[email protected]> 2022-04-22 09:58 ` Dave Page <[email protected]> 2022-04-22 10:16 ` Aditya Toshniwal <[email protected]> 2022-04-22 10:26 ` Ashesh Vashi <[email protected]> 2022-04-22 10:27 ` Dave Page <[email protected]> 2022-04-22 10:31 ` Aditya Toshniwal <[email protected]> 2023-05-03 09:44 ` Yogesh Mahajan <[email protected]> 2023-05-03 13:41 ` Dave Page <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox