Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwnwc-00079z-US for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Oct 2016 10:17:59 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bwnwc-0003wZ-9O for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Oct 2016 10:17:58 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bwnwa-0003vv-J7 for pgadmin-hackers@postgresql.org; Wed, 19 Oct 2016 10:17:56 +0000 Received: from mail-lf0-x22b.google.com ([2a00:1450:4010:c07::22b]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bwnwW-0008Bv-1a for pgadmin-hackers@postgresql.org; Wed, 19 Oct 2016 10:17:55 +0000 Received: by mail-lf0-x22b.google.com with SMTP id x79so16834160lff.0 for ; Wed, 19 Oct 2016 03:17:51 -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=1ik69KYgM8V+TQGf2jesiAaDe33SLm+8yeVp7ANnxOI=; b=F2jAf4c5HEFd+56FKi0X0t7V9m5NSu0XuO1Gwp4i5GTLIQug04SvqtmgPI4t49Sj5I z8GKFCxa/NR+gW25Y81OyiKuhYpBFdB4asRpdUjVNeiXgVcHUxPCKjY5IHT7JBA2RlPD tJkDbJu/oCLNtuJ+IA8SMdwns0/9AnvVs9aTLrA2JQTL3pT9D/5P/irEOzv5VVkFzkIX cXYYXHUnc6hNFA/Nk5GvK59X/vOjecNVNxNjcEkq9A/ZJsIDICocfZcEWiG86I0CPXMp /IZ87Cn5J4Ml8H9cq3S2yJEQBDZVEVv+nkGadtSxpapNj3Q+wvBoDhqvaXm1hLB8AyDX 7YRg== 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=1ik69KYgM8V+TQGf2jesiAaDe33SLm+8yeVp7ANnxOI=; b=Tpcljydzzkn/q9KAAWhjlQ5SKQI3kKAZItS823uiRuj3ApRFIu904Ur7xZw/nqoNAp nM9xmf/Wk3j8u8+zv0+93a89qg40Id85VgupXNzHLMp21jD7Utjhm96eSyZvNLPQsNJm GY/Dpt2BjfWcfrwWjrhWnSE0GBvzaJAA3enPLp0Tsz167VLTpeINUdrk+Uvf0taehfu/ fiHnvQxm6nJUxYFOK2f0tiOPpRywc1YzbVJAC2pYHTDAl3wlyyG7IfzJCCCxnmENj80s 8pEDkMhUCKcr88LunJEL8c7KXsEAUlkOaLaNJmZLfWnKcl9JCx+kk97hRRwuTOVpn0sO FoXA== X-Gm-Message-State: AA6/9RlY52TiUNShkI2EsYVbIi8muW+nhiw7GUY88BDlIOKuvP76R5maqw9Q5b/7FHccjS50QERt6CUApGHRftEg X-Received: by 10.25.16.208 with SMTP id 77mr3516391lfq.167.1476872268764; Wed, 19 Oct 2016 03:17:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.92.219 with HTTP; Wed, 19 Oct 2016 03:17:47 -0700 (PDT) In-Reply-To: References: From: Fahar Abbas Date: Wed, 19 Oct 2016 15:17:47 +0500 Message-ID: Subject: Re: RM1849: Auto-generating security keys To: Dave Page Cc: Ashesh Vashi , pgadmin-hackers , Josh Berkus , =?UTF-8?B?RGV2cmltIEfDnE5Ew5xa?= , Magnus Hagander , Sandeep Thakkar , Hamid Quddus Akhtar Content-Type: multipart/alternative; boundary=001a11403294f56e52053f351e6e 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 --001a11403294f56e52053f351e6e Content-Type: text/plain; charset=UTF-8 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 > 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 --001a11403294f56e52053f351e6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here is 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 - &= #39;/home/fahar/.pgadmin/pgadmin4.db' does not exist.
Entering initi= al setup mode...
NOTE: Configuring authentication for SERVER mode.

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

Email addres= s: fahar.abbas@enterprisedb= .com
Password:
Retype password:
Traceback (most recent call l= ast):
=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_securi= ty/utils.py", line 150, in encrypt_password
=C2=A0=C2=A0=C2=A0 sign= ed =3D get_hmac(password).decode('ascii')
=C2=A0 File "/hom= e/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py", lin= e 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_sha512"
python setup.py
pgAdmin 4 - Appl= ication 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

<= /div>User can not do any setup for web based now.


The confi= guration database - '/home/fahar/.pgadmin/pgadmin4.db' does not exi= st.
Entering initial setup mode...
NOTE: Configuring authentication f= or SERVER mode.


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

Email address: fah= ar.abbas@enterprisedb.com
Password:
Retype password:
Tracebac= k (most recent call last):
=C2=A0 File "setup.py", line 449, i= n <module>
=C2=A0=C2=A0=C2=A0 do_setup(app)
=C2=A0 File "s= etup.py", line 96, in do_setup
=C2=A0=C2=A0=C2=A0 password =3D encr= ypt_password(p1)
=C2=A0 File "/home/fahar/venv/lib/python3.5/site-p= ackages/flask_security/utils.py", line 150, in encrypt_password
=C2= =A0=C2=A0=C2=A0 signed =3D get_hmac(password).decode('ascii')
= =C2=A0 File "/home/fahar/venv/lib/python3.5/site-packages/flask_securi= ty/utils.py", line 108, in get_hmac
=C2=A0=C2=A0=C2=A0 'set to = "%s"' % _security.password_hash)
RuntimeError: The configu= ration value `SECURITY_PASSWORD_SALT` must not be None when the value of `S= ECURITY_PASSWORD_HASH` is set to "pbkdf2_sha512"
<= div class=3D"gmail_extra">
On Wed, Oct 19, 20= 16 at 3:03 PM, Fahar Abbas <fahar.abbas@enterprisedb.com>= ; wrote:
Dave,

Testing Environment
=C2=A0
Ubun= tu 16.04 Linux 64:
--------------------------------

pg-AdminIV Development Environment Setup for Ubuntu=C2=A0 :


= 1) Install GIT

sudo apt-get install git

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= font size=3D"2">2) Install pip3<= /p>

sudo apt-get install pytho= n3-pip

3) In= stall virtualenv

sudo pip3 install virtualenv

4) install below dependency as it is required for psy= copg2 & pycrypto module

sudo apt-get install libpq-dev

sudo apt-get install python3-dev

5) Create virt= ual environment

virtualenv -p python3 venv

6) Create mkdir Projects

7) Clone git repo in Projects

git clone http://git.postgre= sql.org/git/pgadmin4.git

= 8) activate virtual environment

source venv/bin/activate

9) Install modules

pip3 install -r requirements_py3.tx= t

= 10) Edit the config.py file to config_local.py =C2=A0= resides in Projects\pgA= dmin4\web=C2=A0=C2=A0

1= 1)Now run setup<= /span>.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 n= ew 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 databas= e - '/home/fahar/.pgadmin/pgadmin4.db' does not exist.
Ente= ring initial setup mode...
NOTE: Configuring authentication for SERVER m= ode.


=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:

Em= ail address: fahar.abbas@enterprisedb.com
Password:
Retype password:
T= raceback (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 encry= pt_password
=C2=A0=C2=A0=C2=A0 signed =3D get_hmac(password).decode('= ;ascii')
=C2=A0 File "/home/fahar/venv/lib/python3.5/= site-packages/flask_security/utils.py", line 108, in get_hmac
= =C2=A0=C2=A0=C2=A0 'set to "%s"' % _security.password_has= h)
RuntimeError: The configuration value `SECURITY_PASSWORD_SALT` must n= ot be None when the value of `SECURITY_PASSWORD_HASH` is set to "pbkdf= 2_sha512"
(venv) fahar@fahar-virtual-machine:~/Projects/pgadmi= n4/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 investigation.

Kind Regards,

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

Fah= ar, can you please test this thoroughly in desktop and server modes, with b= oth fresh and upgraded installations?


Packagers: T= his change means that packages are no longer forced to create a config_loca= l.py file, and there is no longer any need to explicitly set=C2=A0SECURITY_PASSWORD_SALT,=C2=A0SECURITY_KEY and=C2=A0CSRF_SESSION_KEY in the config= (in fact, they should be removed for new installations, if you have includ= ed them in 1.0)

Thanks.


On Wed, Oct 19, 2016 at 6:46 AM, Ashesh Va= shi <ashesh.vashi@enterprisedb.com> wrote:<= br>
Hi Da= ve,

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


On Friday, Octobe= r 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 the attached patch, and apply if yo= u're happy with it?
Overall the patch looked goo= d to me.
But - I encounter an issue in 'web' mode, which = wont happen with 'runtime'.

Steps for repr= oduction on existing pgAdmin 4 environment with 'web' mode.
- Apply the patch
- Start the pgAdmin4 application (stand alon= e 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 Secur= ity object.
Hence - it could not set the SECURITY_KEY, and SECURI= TY_PASSWORD_SALT properly.

Hmm.
=C2=A0

I had moved the Security object initialization a= fter fetching these configurations from the database.
I have atta= ched a addon patch for the same.
<= br>
OK, thanks.
=C2=A0

Now - I run into another issue.
Because - the existing password was hashed using the old SECURITY_PAS= SWORD_SALT, I am no more able to login to pgAdmin 4.

I think - we need to think about different strategy for upgrading the co= nfiguration file in the 'web' mode.
I was thinking - we c= an store the existing security configurations in the database during upgrad= e process in 'web' mode.
<= br>
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 ha= ve both the key and the encrypted passwords in the same database which is c= learly not a good idea. Sigh... Needs more thought.=C2=A0

OK, so I've been thinking about this a= nd 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 th= is isn't a major problem as from what I can see, =C2=A0SECURITY_PASSWOR= D_SALT is (aside from really being a key not a salt) not the only salting t= hat'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 f= ound 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 c= reated two users, then dropped the database and created the same user accou= nts with the same passwords again, and found that the resulting hashes were= different in both databases - thus there is something else ensuring the ha= shes 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 u= ser and per installation/database salting going on anyway. New installation= s can have the random value for SECURITY_PASSWORD_SALT.
<= /div>
We do not need to generate the random SECURITY_PASSWORD_SAL= T during upgrade mode, which was wrong added in my addon patch.
<= br>
Please find the updated patch.

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

<= br class=3D"m_8579966991770304932m_-4019292325802352314m_243684626496757757= 1gmail-m_1577765211293727506gmail-Apple-interchange-newline">--

Thanks &= Regards,

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



I don't believe SECURITY_KEY and=C2=A0CS= RF_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 ha= ve.

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

Thanks.


--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company<= br>




--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

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



--
Syed Fahar Abbas
Qualit= y Management Group

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


--
Syed Fahar Abbas
Quality Management Group

<= /div>EnterpriseDB Corporation
Phone Office: +92-51-835-8874
Phone Dir= ect: +92-51-8466803
Mobile: +92-333-5409707
Skype ID: syed.= fahar.abbas
Website: www.enterprisedb.com



--
Syed Fahar= Abbas
Quality Management Group

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