Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwojG-00049m-Fj for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Oct 2016 11:08:14 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bwojG-0006jd-2Z for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Oct 2016 11:08:14 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bwoWt-0002AA-K8 for pgadmin-hackers@postgresql.org; Wed, 19 Oct 2016 10:55:28 +0000 Received: from mail-io0-x231.google.com ([2607:f8b0:4001:c06::231]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bwoWq-0005cY-22 for pgadmin-hackers@postgresql.org; Wed, 19 Oct 2016 10:55:26 +0000 Received: by mail-io0-x231.google.com with SMTP id j37so27227523ioo.3 for ; Wed, 19 Oct 2016 03:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yilK+FyyN80rv04b9wiD2fJGm8HEzd9Qumi7igPZP8E=; b=PyGMruZVGEVPy+UO54yy393CarYHpQfcRgd/5PzoRJTGTYsW2jD8ZHGx9tM6Uir2Lc mFdYRRi1XEd1IAfwcNmI0BqCL/DixwRnljmSCLTaZg1vuN2M9mN/f7dtCs1ACoxuwMQY PwhAqN0TmqSVt97Sk+2q/08QVmxFGnNNmYZk2AeQERZ7Rw4NV1z6pPZCVez4NkrUVvTY NyiZ0m/0lcvyznsXvivZIZtmzD0kQtrhi3BVym5CTxO8m2flf1NHdbYeo79iJOj1pBi+ xpor7qyJ5knDZ1vnwNwIvNPQXkwyGE1oLol0EzLu/yiMFbJGhn1TMb3VXjAXu6P2Fn8F s8Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yilK+FyyN80rv04b9wiD2fJGm8HEzd9Qumi7igPZP8E=; b=YqOFFTrjp1Gsh16LszZyz/lcNRIQ15DIFrj8rN2nDofMj65Qdk29zXaWpTBt3fDL+P zw2cXiXYOdZ4+tXBtavwL6o/J0oefx9UrDwl0ajGvLbV3aRWnUKPBjvrZ2Q7daaq5Gv3 B4bMVNw6T1fEqnv+xCg/pOllYxQj+3gsiQQlK/i5V/zV4h5e7V5/r0jjgQTFhTV9zCjZ OCGCYD4x89bWiwalUpTqzdVDbbiy2MEH6O8Hy4qOGbpvxwingZ0NFF0X53qe+kDfeOhN 1xVo+lz7afZc+vSu+0PTtvhhUlKbmpFD8NzFC/IdtC1R7lTwBJlEZDdcyZ4yRFYf0uT6 FSIw== X-Gm-Message-State: AA6/9Rmc0NUv2azkbp6JdTEK2LD3qr8qfW2jc8399CfC/YW83DgD7J9SPiP5ugHhTymwHd+eO/pSm4XZQcSXnMH1 X-Received: by 10.107.58.70 with SMTP id h67mr4161074ioa.115.1476874522762; Wed, 19 Oct 2016 03:55:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.25.139 with HTTP; Wed, 19 Oct 2016 03:55:02 -0700 (PDT) In-Reply-To: References: From: Ashesh Vashi Date: Wed, 19 Oct 2016 16:25:02 +0530 Message-ID: Subject: Re: RM1849: Auto-generating security keys To: Fahar Abbas Cc: Dave Page , pgadmin-hackers , Josh Berkus , =?UTF-8?B?RGV2cmltIEfDnE5Ew5xa?= , Magnus Hagander , Sandeep Thakkar , Hamid Quddus Akhtar Content-Type: multipart/mixed; boundary=001a114a8ef64efecc053f35a5e0 X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgadmin-hackers Precedence: bulk Sender: pgadmin-hackers-owner@postgresql.org --001a114a8ef64efecc053f35a5e0 Content-Type: multipart/alternative; boundary=001a114a8ef64efec7053f35a5de --001a114a8ef64efec7053f35a5de Content-Type: text/plain; charset=UTF-8 Hi Fahar, Please log the case on redmine. Please find the attached patch, please apply it locally, and test it. And, please update the case, and this mail chain accordingly. -- Thanks & Regards, Ashesh Vashi EnterpriseDB INDIA: Enterprise PostgreSQL Company *http://www.linkedin.com/in/asheshvashi* On Wed, Oct 19, 2016 at 3:47 PM, Fahar Abbas wrote: > Here is the output of if we copy config_local.py and execute python > setup.py > pgAdmin 4 - Application Initialisation > ====================================== > > > The configuration database - '/home/fahar/.pgadmin/pgadmin4.db' does not > exist. > Entering initial setup mode... > NOTE: Configuring authentication for SERVER mode. > > > Enter the email address and password to use for the initial pgAdmin > user account: > > Email address: fahar.abbas@enterprisedb.com > Password: > Retype password: > Traceback (most recent call last): > File "setup.py", line 449, in > do_setup(app) > File "setup.py", line 96, in do_setup > password = encrypt_password(p1) > File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py", > line 150, in encrypt_password > signed = get_hmac(password).decode('ascii') > File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py", > line 108, in get_hmac > 'set to "%s"' % _security.password_hash) > RuntimeError: The configuration value `SECURITY_PASSWORD_SALT` must not be > None when the value of `SECURITY_PASSWORD_HASH` is set to "pbkdf2_sha512" > python setup.py > pgAdmin 4 - Application Initialisation > ====================================== > > User can not do any setup for web based now. > > > The configuration database - '/home/fahar/.pgadmin/pgadmin4.db' does not > exist. > Entering initial setup mode... > NOTE: Configuring authentication for SERVER mode. > > > Enter the email address and password to use for the initial pgAdmin > user account: > > Email address: fahar.abbas@enterprisedb.com > Password: > Retype password: > Traceback (most recent call last): > File "setup.py", line 449, in > do_setup(app) > File "setup.py", line 96, in do_setup > password = encrypt_password(p1) > File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py", > line 150, in encrypt_password > signed = get_hmac(password).decode('ascii') > File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py", > line 108, in get_hmac > 'set to "%s"' % _security.password_hash) > RuntimeError: The configuration value `SECURITY_PASSWORD_SALT` must not be > None when the value of `SECURITY_PASSWORD_HASH` is set to "pbkdf2_sha512" > > On Wed, Oct 19, 2016 at 3:03 PM, Fahar Abbas > wrote: > >> Dave, >> >> Testing Environment >> >> Ubuntu 16.04 Linux 64: >> -------------------------------- >> >> pg-AdminIV Development Environment Setup for Ubuntu : >> >> >> 1) Install GIT >> >> sudo apt-get install git >> >> 2) Install pip3 >> >> sudo apt-get install python3-pip >> >> 3) Install virtualenv >> >> sudo pip3 install virtualenv >> >> 4) install below dependency as it is required for psycopg2 & pycrypto >> module >> >> sudo apt-get install libpq-dev >> >> sudo apt-get install python3-dev >> >> 5) Create virtual environment >> >> virtualenv -p python3 venv >> >> 6) Create mkdir Projects >> >> 7) Clone git repo in Projects >> >> git clone http://git.postgresql.org/git/pgadmin4.git >> >> 8) activate virtual environment >> >> source venv/bin/activate >> >> 9) Install modules >> >> pip3 install -r requirements_py3.txt >> >> *10) Edit the config.py file to config_local.py resides in >> Projects\pgAdmin4\web * >> >> 11)Now run setup.py file (\Projects\pgAdmin4\web) >> python setup.py >> >> If user does not create config_local.py and do Python setup.py for new >> Development then SECURITY_PASSWORD_SALT message is also displayed: >> >> Here is the output: >> ------------------------- >> >> python setup.py >> pgAdmin 4 - Application Initialisation >> ====================================== >> >> >> The configuration database - '/home/fahar/.pgadmin/pgadmin4.db' does not >> exist. >> Entering initial setup mode... >> NOTE: Configuring authentication for SERVER mode. >> >> >> Enter the email address and password to use for the initial pgAdmin >> user account: >> >> Email address: fahar.abbas@enterprisedb.com >> Password: >> Retype password: >> Traceback (most recent call last): >> File "setup.py", line 449, in >> do_setup(app) >> File "setup.py", line 96, in do_setup >> password = encrypt_password(p1) >> File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py", >> line 150, in encrypt_password >> signed = get_hmac(password).decode('ascii') >> File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py", >> line 108, in get_hmac >> 'set to "%s"' % _security.password_hash) >> RuntimeError: The configuration value `SECURITY_PASSWORD_SALT` must not >> be None when the value of `SECURITY_PASSWORD_HASH` is set to "pbkdf2_sha512" >> (venv) fahar@fahar-virtual-machine:~/Projects/pgadmin4/web$ >> >> >> Is this expected? >> >> On Wed, Oct 19, 2016 at 1:37 PM, Fahar Abbas < >> fahar.abbas@enterprisedb.com> wrote: >> >>> Sure, >>> >>> Will test this thoroughly after complete investigation. >>> >>> Kind Regards, >>> >>> On Wed, Oct 19, 2016 at 1:27 PM, Dave Page wrote: >>> >>>> Patch applied. >>>> >>>> Fahar, can you please test this thoroughly in desktop and server modes, >>>> with both fresh and upgraded installations? >>>> >>>> https://redmine.postgresql.org/issues/1849 >>>> >>>> Packagers: This change means that packages are no longer forced to >>>> create a config_local.py file, and there is no longer any need to >>>> explicitly set SECURITY_PASSWORD_SALT, SECURITY_KEY >>>> and CSRF_SESSION_KEY in the config (in fact, they should be removed for new >>>> installations, if you have included them in 1.0) >>>> >>>> Thanks. >>>> >>>> >>>> On Wed, Oct 19, 2016 at 6:46 AM, Ashesh Vashi < >>>> ashesh.vashi@enterprisedb.com> wrote: >>>> >>>>> Hi Dave, >>>>> >>>>> On Sat, Oct 15, 2016 at 8:02 AM, Dave Page wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> >>>>>> On Friday, October 14, 2016, Dave Page wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> On Thursday, October 13, 2016, Ashesh Vashi < >>>>>>> ashesh.vashi@enterprisedb.com> wrote: >>>>>>> >>>>>>>> Hi Dave, >>>>>>>> >>>>>>>> On Tue, Oct 11, 2016 at 9:10 PM, Dave Page >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Ashesh, >>>>>>>>> >>>>>>>>> Can you please review the attached patch, and apply if you're >>>>>>>>> happy with it? >>>>>>>>> >>>>>>>> Overall the patch looked good to me. >>>>>>>> But - I encounter an issue in 'web' mode, which wont happen with >>>>>>>> 'runtime'. >>>>>>>> >>>>>>>> Steps for reproduction on existing pgAdmin 4 environment with 'web' >>>>>>>> mode. >>>>>>>> - Apply the patch >>>>>>>> - Start the pgAdmin4 application (stand alone application). >>>>>>>> - Open pgAdmin home page. >>>>>>>> - Log out (if already login). >>>>>>>> >>>>>>>> And, you will see an exception. >>>>>>>> >>>>>>>> I have figure out the issue with the patch. >>>>>>>> We were setting the SECURITY_PASSWORD_SALT, after initializing the >>>>>>>> Security object. >>>>>>>> Hence - it could not set the SECURITY_KEY, and >>>>>>>> SECURITY_PASSWORD_SALT properly. >>>>>>>> >>>>>>> >>>>>>> Hmm. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> I had moved the Security object initialization after fetching these >>>>>>>> configurations from the database. >>>>>>>> I have attached a addon patch for the same. >>>>>>>> >>>>>>> >>>>>>> OK, thanks. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Now - I run into another issue. >>>>>>>> Because - the existing password was hashed using the old >>>>>>>> SECURITY_PASSWORD_SALT, I am no more able to login to pgAdmin 4. >>>>>>>> >>>>>>>> I think - we need to think about different strategy for upgrading >>>>>>>> the configuration file in the 'web' mode. >>>>>>>> I was thinking - we can store the existing security configurations >>>>>>>> in the database during upgrade process in 'web' mode. >>>>>>>> >>>>>>> >>>>>>> My concern with that is that we'll likely be storing the default >>>>>>> config values in many cases, thus for those users, perpetuating the problem. >>>>>>> >>>>>>> I guess what we need to do is re-encrypt the password during the >>>>>>> upgrade - however, that makes me think; we then have both the key and the >>>>>>> encrypted passwords in the same database which is clearly not a good idea. >>>>>>> Sigh... Needs more thought. >>>>>>> >>>>>> >>>>>> OK, so I've been thinking about this and experimenting for a couple >>>>>> of hours, as well as annoying the crap out of Magnus by thinking out loud >>>>>> in his general direction, and it looks like this isn't a major problem as >>>>>> from what I can see, SECURITY_PASSWORD_SALT is (aside from really being a >>>>>> key not a salt) not the only salting that's done. >>>>>> >>>>>> It looks like it's used system-wide as the key to generate an HMAC of >>>>>> the users password, which is then passed to passlib which salts and hashes >>>>>> it. I did some testing, and found that two users with the same password end >>>>>> up with different hashes in the database, so clearly there is also per-user >>>>>> salting happening. I also created two users, then dropped the database and >>>>>> created the same user accounts with the same passwords again, and found >>>>>> that the resulting hashes were different in both databases - thus there is >>>>>> something else ensuring the hashes are unique across different >>>>>> installations/databases. >>>>>> >>>>>> So, I believe we can do as you suggest and migrate existing values >>>>>> for SECURITY_PASSWORD_SALT, given that there's clearly some other per user >>>>>> and per installation/database salting going on anyway. New installations >>>>>> can have the random value for SECURITY_PASSWORD_SALT. >>>>>> >>>>> We do not need to generate the random SECURITY_PASSWORD_SALT during >>>>> upgrade mode, which was wrong added in my addon patch. >>>>> >>>>> Please find the updated patch. >>>>> >>>>> Otherwise - looks good to me. >>>>> Please commit the new patch (if you're ok with the change). >>>>> >>>>> >>>>> -- >>>>> >>>>> Thanks & Regards, >>>>> >>>>> Ashesh Vashi >>>>> EnterpriseDB INDIA: Enterprise PostgreSQL Company >>>>> >>>>> >>>>> >>>>> *http://www.linkedin.com/in/asheshvashi* >>>>> >>>>> >>>>>> >>>>>> I don't believe SECURITY_KEY and CSRF_SESSION_KEY are issues either, >>>>>> as they're used for purposes that are essentially ephemeral, and thus can >>>>>> be changed during an upgrade. >>>>>> >>>>>> Adding Magnus as I'd appreciate any thoughts he may have. >>>>>> >>>>>> Patch attached - please review (Ashesh, but others too would be >>>>>> appreciated)! >>>>>> >>>>>> Thanks. >>>>>> >>>>>> >>>>>> -- >>>>>> Dave Page >>>>>> Blog: http://pgsnake.blogspot.com >>>>>> Twitter: @pgsnake >>>>>> >>>>>> EnterpriseDB UK: http://www.enterprisedb.com >>>>>> The Enterprise PostgreSQL Company >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Dave Page >>>> Blog: http://pgsnake.blogspot.com >>>> Twitter: @pgsnake >>>> >>>> EnterpriseDB UK: http://www.enterprisedb.com >>>> The Enterprise PostgreSQL Company >>>> >>> >>> >>> >>> -- >>> Syed Fahar Abbas >>> Quality Management Group >>> >>> EnterpriseDB Corporation >>> Phone Office: +92-51-835-8874 >>> Phone Direct: +92-51-8466803 >>> Mobile: +92-333-5409707 >>> Skype ID: syed.fahar.abbas >>> Website: www.enterprisedb.com >>> >> >> >> >> -- >> Syed Fahar Abbas >> Quality Management Group >> >> EnterpriseDB Corporation >> Phone Office: +92-51-835-8874 >> Phone Direct: +92-51-8466803 >> Mobile: +92-333-5409707 >> Skype ID: syed.fahar.abbas >> Website: www.enterprisedb.com >> > > > > -- > Syed Fahar Abbas > Quality Management Group > > EnterpriseDB Corporation > Phone Office: +92-51-835-8874 > Phone Direct: +92-51-8466803 > Mobile: +92-333-5409707 > Skype ID: syed.fahar.abbas > Website: www.enterprisedb.com > --001a114a8ef64efec7053f35a5de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Fahar,

Please log the case on = redmine.
Please find the attached patch, please apply it locally, and t= est it.

And, please update the case, and this mail= chain accordingly.

--

Thanks & Regards,

Ashesh Vashi<= /span>
Ent= erpriseDB INDIA: Enterprise PostgreSQL Company

<= br>

<= a href=3D"http://www.linkedin.com/in/asheshvashi" target=3D"_blank">http= ://www.linkedin.com/in/asheshvashi


On Wed, Oct 19, 2016 at 3:47 PM, Fahar Abbas= <fahar.abbas@enterprisedb.com> wrote:
Here is the output of if we c= opy config_local.py and execute python setup.py
pgAdmin= 4 - Application Initialisation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D


The configuration database - '/home/fahar/.pgadmin/pgadmin4.db' does not exist.
Entering initial setup mode...
NO= TE: Configuring authentication for SERVER mode.


=C2=A0=C2=A0=C2= =A0 Enter the email address and password to use for the initial pgAdmin use= r=C2=A0=C2=A0=C2=A0=C2=A0 account:

Email address: fahar.abbas@enterprisedb.co= m
Password:
Retype password:
Traceback (most recent call last= ):
=C2=A0 File "setup.py", line 449, in <module>
=C2= =A0=C2=A0=C2=A0 do_setup(app)
=C2=A0 File "setup.py", line 96,= in do_setup
=C2=A0=C2=A0=C2=A0 password =3D encrypt_password(p1)
=C2= =A0 File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py", line 150, in encrypt_password
=C2=A0=C2=A0=C2= =A0 signed =3D get_hmac(password).decode('ascii')
=C2=A0 Fi= le "/home/fahar/venv/lib/python3.5/site-packages/flask_secur= ity/utils.py", line 108, in get_hmac
=C2=A0=C2=A0=C2=A0 'set to= "%s"' % _security.password_hash)
RuntimeError: The config= uration value `SECURITY_PASSWORD_SALT` must not be None when the value of `= SECURITY_PASSWORD_HASH` is set to "pbkdf2_sha512"
python setup= .py
pgAdmin 4 - Application Initialisation
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

User can not do any setup for web= based now.


The configuration database - &= #39;/home/fahar/.pgadmin/pgadmin4.db' does not exist.
Entering = initial setup mode...
NOTE: Configuring authentication for SERVER mode.<= br>

=C2=A0=C2=A0=C2=A0 Enter the email address and password to use f= or the initial pgAdmin user=C2=A0=C2=A0=C2=A0=C2=A0 account:

Email a= ddress: f= ahar.abbas@enterprisedb.com
Password:
Retype password:
Traceb= ack (most recent call last):
=C2=A0 File "setup.py", line 449,= in <module>
=C2=A0=C2=A0=C2=A0 do_setup(app)
=C2=A0 File "= ;setup.py", line 96, in do_setup
=C2=A0=C2=A0=C2=A0 password =3D en= crypt_password(p1)
=C2=A0 File "/home/fahar/venv/lib/python3.5= /site-packages/flask_security/utils.py", line 150, in encrypt_pas= sword
=C2=A0=C2=A0=C2=A0 signed =3D get_hmac(password).decode('= ascii')
=C2=A0 File "/home/fahar/venv/lib/python3.5/site-p= ackages/flask_security/utils.py", line 108, in get_hmac
=C2=A0= =C2=A0=C2=A0 'set to "%s"' % _security.password_hash)
= RuntimeError: The configuration value `SECURITY_PASSWORD_SALT` must not be = None when the value of `SECURITY_PASSWORD_HASH` is set to "pbkdf2_sha5= 12"

On Wed, Oct 19, 2016 = at 3:03 PM, Fahar Abbas <fahar.abbas@enterprisedb.com> wrote:
D= ave,

Testing Environment
=C2=A0
Ubuntu = 16.04 Linux 64:
--------------------------------

pg-AdminIV Development Environment Setup = for Ubu= ntu=C2=A0 :

=

1) Inst= all GIT

sudo= apt-get install git

2) Install pip3

sudo apt-get install python3-pip

3) Install virtualenv

=

= sudo pip3 install virtualenv<= /span>

4) install b= elow dependency as it is required for psycopg2 & pycrypto module=

sudo apt-get insta= ll libpq-dev

sudo apt-get install python3-dev

5) Create virtual environment

virtualenv -p python3 venv<= /font>

6) Create mkdir Projects

7) Clone git r= epo in Projects

git clone http://git.postgresql.org/git/pgadmin4.git=

8) activate virtua= l environment

source venv/bin/activate

9) Install modules

pip3 install -r requirements_py3.txt

10)= Edit the config.py file to config_local.py =C2=A0resides in Project= s\pgAdmin4\web=C2=A0=C2=A0

11)Now run setup.py file =C2=A0(\Projects\pgAdmin4\web)

=C2=A0 =C2=A0 python setup.py
If user does not create config_local.py and do Python setup.py for new De= velopment then SECURITY_PASSWORD_SALT message is also displayed:

Here is the output:
-------------------------

= python setup.py
pgAdmin 4 - Application Initialisation
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D


The configuration database - &#= 39;/home/fahar/.pgadmin/pgadmin4.db' does not exist.
Entering i= nitial setup mode...
NOTE: Configuring authentication for SERVER mode.

=C2=A0=C2=A0=C2=A0 Enter the email address and password to use fo= r the initial pgAdmin user=C2=A0=C2=A0=C2=A0=C2=A0 account:

Email ad= dress: fa= har.abbas@enterprisedb.com
Password:
Retype password:
Traceba= ck (most recent call last):
=C2=A0 File "setup.py", line 449, = in <module>
=C2=A0=C2=A0=C2=A0 do_setup(app)
=C2=A0 File "= setup.py", line 96, in do_setup
=C2=A0=C2=A0=C2=A0 password =3D enc= rypt_password(p1)
=C2=A0 File "/home/fahar/venv/lib/python3.5/= site-packages/flask_security/utils.py", line 150, in encrypt_pass= word
=C2=A0=C2=A0=C2=A0 signed =3D get_hmac(password).decode('ascii')
=C2=A0 File "/home/fahar/venv/lib/python3.5/site-pa= ckages/flask_security/utils.py", line 108, in get_hmac
=C2=A0= =C2=A0=C2=A0 'set to "%s"' % _security.password_hash)
= RuntimeError: The configuration value `SECURITY_PASSWORD_SALT` must not be = None when the value of `SECURITY_PASSWORD_HASH` is set to "pbkdf2_sha5= 12"
(venv) fahar@fahar-virtual-machine:~/Projects/pgadmin4/web= $


Is this expected?

On Wed, Oct 19,= 2016 at 1:37 PM, Fahar Abbas <fahar.abbas@enterprisedb.com= > wrote:
=
Sure,

Will test this thoroughly after complete investigat= ion.

Kind Regards,

On Wed, Oct 19, 2016 at 1:27 PM, Dave Page <dpage@pgadmin= .org> wrote:
Patch applied.

Fahar, can you please test this thorou= ghly in desktop and server modes, with both fresh and upgraded installation= s?


Thanks.


On Wed, Oct 19, 2016 at 6:46 AM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:
Hi Dave,

<= /div>
On Sat, Oct 15, 2016 at 8:02 AM, Dave Page <dpage= @pgadmin.org> wrote:
Hi


On Friday, October 14, 2016, Dave Page <dpage@pgadmin.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Hi

On Thursday, Oct= ober 13, 2016, Ashesh Vashi <ashesh.vashi@enterprisedb.com&g= t; wrote:
Hi Dave,

On Tue, Oct 11, 2016 at 9:10 PM, Dave Page <= dpage@pgadmin.org> wrote:
Hi Ashesh,

Can you please review the a= ttached patch, and apply if you're happy with it?
Overall the patch looked good to me.
But - I encounter an issue= in 'web' mode, which wont happen with 'runtime'.

Steps for reproduction on existing pgAdmin 4 environment wi= th 'web' mode.
- Apply the patch
- Start the pg= Admin4 application (stand alone application).
- Open pgAdmin home= page.
- Log out (if already login).

And= , you will see an exception.

I have figure out the= issue with the patch.
We were setting the SECURITY_PASSWORD_SALT= , after initializing the Security object.
Hence - it could not se= t the SECURITY_KEY, and SECURITY_PASSWORD_SALT properly.
<= /div>

Hmm.
=C2=A0

I had moved the Sec= urity object initialization after fetching these configurations from the da= tabase.
I have attached a addon patch for the same.

OK, thanks.
=C2=A0

Now - I= run into another issue.
Because - the existing password was hash= ed using the old SECURITY_PASSWORD_SALT, I am no more able to login to pgAd= min 4.

I think - we need to think about different = strategy for upgrading the configuration file in the 'web' mode.
I was thinking - we can store the existing security configurations = in the database during upgrade process in 'web' mode.

My concern with that is that we&= #39;ll likely be storing the default config values in many cases, thus for = those users, perpetuating the problem.

I guess wha= t we need to do is re-encrypt the password during the upgrade - however, th= at makes me think; we then have both the key and the encrypted passwords in= the same database which is clearly not a good idea. Sigh... Needs more tho= ught.=C2=A0

OK, so I'= ve been thinking about this and experimenting for a couple of hours, as wel= l as annoying the crap out of Magnus by thinking out loud in his general di= rection, and it looks like this isn't a major problem as from what I ca= n see, =C2=A0SECURITY_PASSWORD_SALT is (aside from really being a key not a= salt) not the only salting that's done.=C2=A0

It looks like it's used system-wide as the key to generate an HMAC of = the users password, which is then passed to passlib which salts and hashes = it. I did some testing, and found that two users with the same password end= up with different hashes in the database, so clearly there is also per-use= r salting happening. I also created two users, then dropped the database an= d created the same user accounts with the same passwords again, and found t= hat the resulting hashes were different in both databases - thus there is s= omething else ensuring the hashes are unique across different installations= /databases.

So, I believe we can do as you suggest= and migrate existing values for SECURITY_PASSWORD_SALT, given that there&#= 39;s clearly some other per user and per installation/database salting goin= g on anyway. New installations can have the random value for SECURITY_PASSW= ORD_SALT.
We do not need to generate the= random SECURITY_PASSWORD_SALT during upgrade mode, which was wrong added i= n my addon patch.

Please find the updated patch.

Otherwise - looks good to me.
Please comm= it the new patch (if you're ok with the change).


--

Thanks & R= egards,

Ashesh Vashi
EnterpriseDB INDIA:= =C2=A0Ent= erprise PostgreSQL Company



I don't believe SE= CURITY_KEY and=C2=A0CSRF_SESSION_KEY are issues either, as they're used= for purposes that are essentially ephemeral, and thus can be changed durin= g an upgrade.

Adding Magnus as I'd appreciate = any thoughts he may have.

Patch attached - please = review (Ashesh, but others too would be appreciated)!

<= div>Thanks.

<= br>--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

Ent= erpriseDB UK: htt= p://www.enterprisedb.com
The Enterprise PostgreSQL Company





--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitte= r: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgr= eSQL Company



-- =
Syed Fahar Abbas
Quality Management Group

EnterpriseDB Corporation
Phone Office: +92-51-835-8874
Phone Direct:= = +92-51-8466803
Mobile: +92-333-5409707
Skype ID: syed.fahar.= abbas
Website: www.enterprisedb.com



--
Syed Fahar Abbas
Quality Man= agement Group

EnterpriseDB Corporation
Phone Office: +92-51= -835-8874
Phone Direct: +92-51-8466803
Mobile: +92-333-5409707
Skype ID: syed.fahar.abbas
Website: www.enterprisedb.com



--
Syed Fahar Abbas
Quality Management Group
=
EnterpriseDB Corporation
Phone Office: +92-51-835-8874
Phone = Direct: +92-51-8466803
Mobile: +92-333-5409707
Skype ID: syed.fahar.a= bbas
Website: = www.enterprisedb.com

--001a114a8ef64efec7053f35a5de-- --001a114a8ef64efecc053f35a5e0 Content-Type: application/octet-stream; name="reload_config_setup.patch" Content-Disposition: attachment; filename="reload_config_setup.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iugsxtk20 ZGlmZiAtLWdpdCBhL3dlYi9zZXR1cC5weSBiL3dlYi9zZXR1cC5weQppbmRl eCAxMjQ2NWYzLi5jM2QzYjM2IDEwMDc1NQotLS0gYS93ZWIvc2V0dXAucHkK KysrIGIvd2ViL3NldHVwLnB5CkBAIC00MzcsNiArNDM3LDggQEAgRXhpdGlu Zy4uLiIiIiAlICh2ZXJzaW9uLnZhbHVlKSkKICAgICAgICAgY29uZmlnLlNF Q1JFVF9LRVkgPSBiYXNlNjQudXJsc2FmZV9iNjRlbmNvZGUob3MudXJhbmRv bSgzMikpCiAgICAgICAgIGNvbmZpZy5TRUNVUklUWV9QQVNTV09SRF9TQUxU ID0gYmFzZTY0LnVybHNhZmVfYjY0ZW5jb2RlKG9zLnVyYW5kb20oMzIpKQog CisgICAgICAgIGFwcC5jb25maWcuZnJvbV9vYmplY3QoY29uZmlnKQorCiAg ICAgICAgIGRpcmVjdG9yeSA9IG9zLnBhdGguZGlybmFtZShjb25maWcuU1FM SVRFX1BBVEgpCiAgICAgICAgIGlmIG5vdCBvcy5wYXRoLmV4aXN0cyhkaXJl Y3RvcnkpOgogICAgICAgICAgICAgb3MubWFrZWRpcnMoZGlyZWN0b3J5LCBp bnQoJzcwMCcsIDgpKQo= --001a114a8ef64efecc053f35a5e0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers --001a114a8ef64efecc053f35a5e0--