Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwpi6-0002nr-Nw for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Oct 2016 12:11:07 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bwpi6-0003hU-2T for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Oct 2016 12:11:06 +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 1bwpd3-0003XZ-Ji for pgadmin-hackers@postgresql.org; Wed, 19 Oct 2016 12:05:54 +0000 Received: from mail-it0-x232.google.com ([2607:f8b0:4001:c0b::232]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bwpcy-0006wf-Mv for pgadmin-hackers@postgresql.org; Wed, 19 Oct 2016 12:05:52 +0000 Received: by mail-it0-x232.google.com with SMTP id 4so109992684itv.0 for ; Wed, 19 Oct 2016 05:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JO3l1Z+DG9ZCUMbvH78Up8vPSzniXTKEdMVtSaQhkJo=; b=qTp3vs6WVb1jNXN7ho9G6y0zZ85HWObYTiy+86VISNVtUviEzDX9zxQs7W5aAQpkXC xQAs+5kjf+S+RTkg86ilDl8LuQt1VToCEfe2dLaVGMq1hvry73vAd2clNOoBWaVtDmT6 fmaLGMduXL8z66rK7ck6q/SM5QN3LuyBx2vTd3qOdIC6DCpvURB5JKUnoyXKbhK5RwtK VwPl/uckAIPx7eqUJUisKqGwy7uhoAcw6mN68vAMepBQiMMjwPvKVZqmni1mLc0hnCJs RvM5pJyEXcRPPa0yOj9HUyGp9zoW1y0aKPHNbnBRQlV1cX6b92entFQS8dEr4ukz0CO0 j1qA== 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=JO3l1Z+DG9ZCUMbvH78Up8vPSzniXTKEdMVtSaQhkJo=; b=HZsTCE3GZzZB/jb5WY5XNqjZVn1tmVYakCZplyCLbChf5oRA8MSDSGB6NSpcwiTtZu qHvNVV7pBpPkyknemYSJhBa7OsE8oc1fK/XDvBggYVA5ObNoleMqn1rAUfA5ZH81wmR3 aLZycPQ99eL/OdCsYgpSQ9axXJIfmG5KEU4fVwgzgUyhJwPXTpfehn26vVQJQYllSfMZ rIYyjlOQmix0xEAr1+OGrNm24qGw5bZwM+dz6cYSg5Ma5SXObc2Motxc4oNQ54l6gzwx vcvL5//OZFTigajDDuBxq25Aff3WIBfVCyk0SRdMUHhwoEXJh8BxTKpzcm4R7KKIlDXW VjfA== X-Gm-Message-State: AA6/9Rkw2zGnNhr9V37qg2WSN3DhWymKc6/YgiAjX4OkBWOMXEkCMbQuBAhzY/OoFT5Pgwfl61iKp1fYVcm+Hw== X-Received: by 10.36.68.197 with SMTP id o188mr2432713ita.94.1476878747060; Wed, 19 Oct 2016 05:05:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.82.130 with HTTP; Wed, 19 Oct 2016 05:05:45 -0700 (PDT) In-Reply-To: References: From: Dave Page Date: Wed, 19 Oct 2016 13:05:45 +0100 Message-ID: Subject: Re: RM1849: Auto-generating security keys To: Fahar Abbas Cc: Ashesh Vashi , pgadmin-hackers , Josh Berkus , =?UTF-8?B?RGV2cmltIEfDnE5Ew5xa?= , Magnus Hagander , Sandeep Thakkar , Hamid Quddus Akhtar Content-Type: multipart/alternative; boundary=001a1143a83018fe59053f36a1af 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 --001a1143a83018fe59053f36a1af Content-Type: text/plain; charset=UTF-8 Great, thanks! On Wed, Oct 19, 2016 at 12:42 PM, Fahar Abbas wrote: > > > On Wed, Oct 19, 2016 at 4:03 PM, Fahar Abbas > wrote: > >> >> >> On Wed, Oct 19, 2016 at 3:55 PM, Ashesh Vashi < >> ashesh.vashi@enterprisedb.com> wrote: >> >>> Hi Fahar, >>> >>> Please log the case on redmine. >>> >> https://redmine.postgresql.org/issues/1871 >> >>> Please find the attached patch, please apply it locally, and test it. >>> >>> And, please update the case, and this mail chain accordingly. >>> >> This is resolved now and no error message displayed when we apply the > patch that is already shared. > >> >>> Sure Will test the patch and update the status 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 < >>> fahar.abbas@enterprisedb.com> 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 < >>>> fahar.abbas@enterprisedb.com> 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 >>>> >>> >>> >> >> >> -- >> 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 > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company --001a1143a83018fe59053f36a1af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Great, thanks!

On Wed, Oct 19, 2016 at 12:42 PM, Fahar Abbas <fahar.abbas@enterprisedb.com> wrote:


On Wed, Oct 19, 2016 at 4:03 PM, Fahar A= bbas <fahar.abbas@enterprisedb.com> wrote:


On Wed, Oct 19, 2016 at 3:55 PM, Ashe= sh Vashi <ashesh.vashi@enterprisedb.com> wr= ote:
=
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 ch= ain accordingly.
This is resolved now and no error message displayed when we= apply the patch that is already shared.
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
<= div class=3D"gmail_quote">

Sure Will test the patch and update the status 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 A= bbas <fahar.abbas@enterprisedb.com> wrote:
Here i= s the output of if we copy 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 m= ode...
NOTE: Configuring authentication for SERVER mode.


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

Email address: fahar.abbas@ent= erprisedb.com
Password:
Retype password:
Traceback (most rece= nt 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')<= br>=C2=A0 File "/home/fahar/venv/lib/python3.5/site-packages/flas= k_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 th= e 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 se= tup 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:0= 3 PM, Fahar Abbas <fahar.abbas@enterprisedb.com> = wrote:
Dave,

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

pg-AdminIV Development Envir= onment Setu= p for

1)= Install GIT

sudo apt-get install git

2) Install pip3

sudo apt-get install python3-pip

3) Install virtualenv=

sudo pip3 install virtual= env

4) insta= ll below dependency as it is required for psycopg2 & pycrypto module

sudo apt-get i= nstall libpq-dev

sudo apt-get install python3-dev

5) Create virtual environment

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= font size=3D"2">virtualenv -p python3 venv

6) Create mkdir Projects

7) Clone g= it repo 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\pgA= dmin4\web=C2=A0=C2=A0

1= 1)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 Development 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 - '/home/fahar= /.pgadmin/pgadmin4.db' does not exist.
Entering initial setup m= ode...
NOTE: Configuring authentication for SERVER mode.


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

Email address: fahar.abbas@ent= erprisedb.com
Password:
Retype password:
Traceback (most rece= nt 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')<= br>=C2=A0 File "/home/fahar/venv/lib/python3.5/site-packages/flas= k_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 th= e 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> wrot= e:
Sure,

Will test this thoroughly after complete investi= gation.

Kind Regards,

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

Fahar, can you please = test this thoroughly in desktop and server modes, with both fresh and upgra= ded installations?


Packagers: This change means th= at packages are no longer forced to create a config_local.py file, and ther= e is no longer any need to explicitly set=C2=A0SECURITY_PASSWORD_SALT,=C2=A0S= ECURITY_KEY and=C2=A0CSRF_SESSION_KEY in the config (in fact, they sho= uld be removed for new installations, if you have included them in 1.0)

Thanks.


On Wed, Oct 19, 2016 at 6:46 AM, Ashesh Vas= hi <ashesh.vashi@enterprisedb.com> wrote:
Hi Dav= e,

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:
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 <= ;dpage@pgadmin.org> wrote:
Hi Ashesh,

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

Steps for reproduction on existing pgAdmin 4 environmen= t with 'web' mode.
- Apply the patch
- Start th= e 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 no= t set the SECURITY_KEY, and SECURITY_PASSWORD_SALT properly.

Hmm.
=C2=A0

I had moved the= Security object initialization after fetching these configurations from th= e database.
I have attached a addon patch for the same.

OK, thanks.
=C2=A0=

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 differ= ent strategy for upgrading the configuration file in the 'web' mode= .
I was thinking - we can store the existing security configurati= ons 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 password= s in the same database which is clearly not a good idea. Sigh... Needs more= thought.=C2=A0

OK, so I&= #39;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 genera= l direction, and it looks like this isn't a major problem as from what = I can see, =C2=A0SECURITY_PASSWORD_SALT is (aside from really being a key n= ot 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 has= hes 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 databas= e and created the same user accounts with the same passwords again, and fou= nd that the resulting hashes were different in both databases - thus there = is something else ensuring the hashes are unique across different installat= ions/databases.

So, I believe we can do as you sug= gest and migrate existing values for SECURITY_PASSWORD_SALT, given that the= re's clearly some other per user and per installation/database salting = going on anyway. New installations can have the random value for SECURITY_P= ASSWORD_SALT.
We do not need to generate= the random SECURITY_PASSWORD_SALT during upgrade mode, which was wrong add= ed in my addon patch.

Please find the updated patc= h.

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


--

Thanks & Regar= ds,

<= span style=3D"font-style:italic">Ashesh Vashi
EnterpriseDB INDIA:=C2=A0= Enterpris= e PostgreSQL Company



I don't believe SECURITY_KE= Y and=C2=A0CSRF_SESSION_KEY are issues either, as they're used for purp= oses that are essentially ephemeral, and thus can be changed during an upgr= ade.

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

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

Thank= s.


--
Dave Pa= ge
Blog: http:= //pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterpris= edb.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
Quali= ty Management Group

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



--
Syed F= ahar Abbas
Quality Management Group

EnterpriseDB= Corporation
Phone Office: +92-51-835-8874
Phone Direct: +92-51-846680= 3
Mobile: +92-333-5409707
Skype ID: syed.fahar.abbas
Webs= ite: www.enterpri= sedb.com



--
Syed Fahar Abbas
<= div>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 CorporationPhone Office: +92-51-835-8874
Phone Direct: +92-51-8466803
Mobil= e: +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
=



--
Dave Page
Blog: = http://pgsnake.bl= ogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com<= br>The Enterprise PostgreSQL Company
--001a1143a83018fe59053f36a1af--