Database Password Restriction on Install

[Phil]

Hello,

when you install in-portal, you cannot use special characters in DB
password, while they are accepted by MySQL when creating the DB.

If we enter a password containing other characters than alphabetical,
the password is stored in config.php but install cannot continue on
step 3, and when trying to install again, Inportal act as if it was
already installed, but no root password have been setup and I need to
remove all DB info in config.php to restart install.

Can we escape DB name and password to accept all kind?

Phil.

[Dmitry Andrejev]

Hi Phil,

This is strange since I don't think we validate DB password at all.

I'll check on this and will update here.

Anyone else has similar behavior?

DA

--
You received this message because you are subscribed to the Google Groups "In-Portal Bugs Team" group.
To post to this group, send email to in-port...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.

[Alexander Obuhovich]

Nope, we send password directly to mysql_connect function. We have a lot of installation when db password is alpha-numerical.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Phil ..:: domicilis.biz ::..]

Hi Dmitry,

that's the problem, password isn't validated and stored "as it" in
config.php, but because the field is between double quotes, if there
is also quotes or weird charaters in the field, we end up with an
error.
It should be the same with DB name, which is between the same double quotes.

Phil.

2010/3/12 Alexander Obuhovich <aik....@gmail.com>:

[Alexander Obuhovich]

Now I get it, thanks. Here is ini format description (just for the record) http://en.wikipedia.org/wiki/INI_file. I've checked, that we don't escape anything in config.php file. I think, that we should address this issue while converting config.php to PHP format. We already have task for that scheduled from 5.1.0 release.

[Dmitry A.]

Hi Alex,

I quickly looked through the article, but haven't seen much on special
symbols - just some basic stuff. Out of curiosity I am not getting why
it's related if we are just writing and reading to/from the file?

In any case, Phil and others here is a task for converting
"config.php" into PHP format:

http://tracker.in-portal.org/view.php?id=235

DA.

On Mar 12, 1:05 pm, Alexander Obuhovich <aik.b...@gmail.com> wrote:
> Now I get it, thanks. Here is ini format description (just for the record)http://en.wikipedia.org/wiki/INI_file. I've checked, that we don't escape

> anything in config.php file. I think, that we should address this issue
> while converting config.php to PHP format. We already have task for that
> scheduled from 5.1.0 release.
>
> On Fri, Mar 12, 2010 at 12:45 PM, Phil ..:: domicilis.biz ::.. <
>
>
>
>
>
> p...@domicilis.biz> wrote:
> > Hi Dmitry,
>
> > that's the problem, password isn't validated and stored "as it" in
> > config.php, but because the field is between double quotes, if there
> > is also quotes or weird charaters in the field, we end up with an
> > error.
> > It should be the same with DB name, which is between the same double
> > quotes.
>
> > Phil.
>

> > 2010/3/12 Alexander Obuhovich <aik.b...@gmail.com>:

> > > Nope, we send password directly to mysql_connect function. We have a lot
> > of
> > > installation when db password is alpha-numerical.
>

> > > On Fri, Mar 12, 2010 at 7:03 AM, Dmitry Andrejev <dandre...@gmail.com>

> > > wrote:
>
> > >> Hi Phil,
>
> > >> This is strange since I don't think we validate DB password at all.
> > >> I'll check on this and will update here.
> > >> Anyone else has similar behavior?
>
> > >> DA
>

> > >> On Thu, Mar 11, 2010 at 3:48 PM, Phil <p...@domicilis.biz> wrote:
>
> > >>> Hello,
>
> > >>> when you install in-portal, you cannot use special characters in DB
> > >>> password, while they are accepted by MySQL when creating the DB.
>
> > >>> If we enter a password containing other characters than alphabetical,
> > >>> the password is stored in config.php but install cannot continue on
> > >>> step 3, and when trying to install again, Inportal act as if it was
> > >>> already installed, but no root password have been setup and I need to
> > >>> remove all DB info in config.php to restart install.
>
> > >>> Can we escape DB name and password to accept all kind?
>
> > >>> Phil.
>
> > >>> --
> > >>> You received this message because you are subscribed to the Google
> > Groups
> > >>> "In-Portal Bugs Team" group.
> > >>> To post to this group, send email to in-port...@googlegroups.com.
> > >>> To unsubscribe from this group, send email to

> > >>> in-portal-bug...@googlegroups.com<in-portal-bugs%2Bunsubscribe@go oglegroups.com>

> > .
> > >>> For more options, visit this group at
> > >>>http://groups.google.com/group/in-portal-bugs?hl=en.
>
> > >> --
> > >> You received this message because you are subscribed to the Google
> > Groups
> > >> "In-Portal Bugs Team" group.
> > >> To post to this group, send email to in-port...@googlegroups.com.
> > >> To unsubscribe from this group, send email to

> > >> in-portal-bug...@googlegroups.com<in-portal-bugs%2Bunsubscribe@go oglegroups.com>

> > .
> > >> For more options, visit this group at
> > >>http://groups.google.com/group/in-portal-bugs?hl=en.
>
> > > --
> > > Best Regards,
>
> > >http://www.in-portal.com
> > >http://www.alex-time.com
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "In-Portal Bugs Team" group.
> > > To post to this group, send email to in-port...@googlegroups.com.
> > > To unsubscribe from this group, send email to

> > > in-portal-bug...@googlegroups.com<in-portal-bugs%2Bunsubscribe@go oglegroups.com>

> > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/in-portal-bugs?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "In-Portal Bugs Team" group.
> > To post to this group, send email to in-port...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > in-portal-bug...@googlegroups.com<in-portal-bugs%2Bunsubscribe@go oglegroups.com>

[Dmitry A.]

Forgot to post the suggested PHP format for new config.php

$_CONFIG['Database']['DBType'] = 'mysql';
$_CONFIG['Database']['DBHost'] = 'jurmala.com';
$_CONFIG['Database']['DBName'] = 'aidas_live';
$_CONFIG['Database']['DBUser'] = 'root';
$_CONFIG['Database']['DBUserPassword'] = '';
$_CONFIG['Database']['TablePrefix'] = '';
$_CONFIG['Database']['DBCollation'] = 'utf8_general_ci';
$_CONFIG['Database']['DBCharset'] = 'utf8';

$_CONFIG['Misc']['WriteablePath'] = '/system';
$_CONFIG['Misc']['Domain'] = 'www.jurmala.com';

$_CONFIG['Intechnic']['LicenseCode'] = '18692-IN1828-1222-XXXX';
$_CONFIG['Intechnic']['License'] =
'Cl9Sd1FlU30GZlptBDoEY19tVhFSMAduWCRSd1F6VQhXAgAlVmJRf1ULVWIAIAR1DjwEM1ZrAjsPMAEwVjBSMQpoUjVRM1M2Bj1aOQRlBDVfZVZnUmkHMlgyUjdRN1U7V2AAZVY
+UTRVP1U0ADIEPw4yBA1WMgJnD34BZlY5UnIKfVJzUS5TZQZ9Wn4EOgRnXzxWNFJzB2RYP1JoUX9VZldhADVWN1E5VWNVYQBmBD4OYwQzVjoCZw9iAWVWM1I8CjJSZVFiUzYGMVptBGEEY19kVmxSagdlWDFSP';

What you think?

DA.

On Mar 12, 1:05 pm, Alexander Obuhovich <aik.b...@gmail.com> wrote:

> Now I get it, thanks. Here is ini format description (just for the record)http://en.wikipedia.org/wiki/INI_file. I've checked, that we don't escape

> anything in config.php file. I think, that we should address this issue
> while converting config.php to PHP format. We already have task for that
> scheduled from 5.1.0 release.
>
> On Fri, Mar 12, 2010 at 12:45 PM, Phil ..:: domicilis.biz ::.. <
>
>
>
>
>
> p...@domicilis.biz> wrote:
> > Hi Dmitry,
>
> > that's the problem, password isn't validated and stored "as it" in
> > config.php, but because the field is between double quotes, if there
> > is also quotes or weird charaters in the field, we end up with an
> > error.
> > It should be the same with DB name, which is between the same double
> > quotes.
>
> > Phil.
>

> > 2010/3/12 Alexander Obuhovich <aik.b...@gmail.com>:

> > > Nope, we send password directly to mysql_connect function. We have a lot
> > of
> > > installation when db password is alpha-numerical.
>

> > > On Fri, Mar 12, 2010 at 7:03 AM, Dmitry Andrejev <dandre...@gmail.com>

> > > wrote:
>
> > >> Hi Phil,
>
> > >> This is strange since I don't think we validate DB password at all.
> > >> I'll check on this and will update here.
> > >> Anyone else has similar behavior?
>
> > >> DA
>

> > >> On Thu, Mar 11, 2010 at 3:48 PM, Phil <p...@domicilis.biz> wrote:
>
> > >>> Hello,
>
> > >>> when you install in-portal, you cannot use special characters in DB
> > >>> password, while they are accepted by MySQL when creating the DB.
>
> > >>> If we enter a password containing other characters than alphabetical,
> > >>> the password is stored in config.php but install cannot continue on
> > >>> step 3, and when trying to install again, Inportal act as if it was
> > >>> already installed, but no root password have been setup and I need to
> > >>> remove all DB info in config.php to restart install.
>
> > >>> Can we escape DB name and password to accept all kind?
>
> > >>> Phil.
>
> > >>> --
> > >>> You received this message because you are subscribed to the Google
> > Groups
> > >>> "In-Portal Bugs Team" group.
> > >>> To post to this group, send email to in-port...@googlegroups.com.
> > >>> To unsubscribe from this group, send email to

> > >>> in-portal-bug...@googlegroups.com<in-portal-bugs%2Bunsubscribe@go oglegroups.com>

> > .
> > >>> For more options, visit this group at
> > >>>http://groups.google.com/group/in-portal-bugs?hl=en.
>
> > >> --
> > >> You received this message because you are subscribed to the Google
> > Groups
> > >> "In-Portal Bugs Team" group.
> > >> To post to this group, send email to in-port...@googlegroups.com.
> > >> To unsubscribe from this group, send email to

> > >> in-portal-bug...@googlegroups.com<in-portal-bugs%2Bunsubscribe@go oglegroups.com>

> > .
> > >> For more options, visit this group at
> > >>http://groups.google.com/group/in-portal-bugs?hl=en.
>
> > > --
> > > Best Regards,
>
> > >http://www.in-portal.com
> > >http://www.alex-time.com
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "In-Portal Bugs Team" group.
> > > To post to this group, send email to in-port...@googlegroups.com.
> > > To unsubscribe from this group, send email to

> > > in-portal-bug...@googlegroups.com<in-portal-bugs%2Bunsubscribe@go oglegroups.com>

> > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/in-portal-bugs?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "In-Portal Bugs Team" group.
> > To post to this group, send email to in-port...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > in-portal-bug...@googlegroups.com<in-portal-bugs%2Bunsubscribe@go oglegroups.com>

[Phil ..:: domicilis.biz ::..]

Hi guys,

As we go on the road to redo config.php, I'd like to suggest an
important security idea:

We sometime need to give an FTP access to external partners, such as
companies who help for SEO.
When we give this access, they can read config.php and grab DB credentials.
Also, like we have seen before, some malicious script could give such
FTP access.

Should it be possible, like I tought, to install config.php into
cgi-bin folder? I actually install gateway files into this directory
and it makes no problem to inportal to read them here, could we do the
same for this important file?

Phil.

2010/3/14 Dmitry A. <dand...@gmail.com>:

> To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com.

[Alexander Obuhovich]

About "cgi-bin" it won't be working any more since 5.1.0 release, because In-Portal won't be searching for it's code throughout the document root, but only inside "core" and "modules" folders on top level of in-portal installation (where config.php is located).

About FTP access you could given access only to "themes" folder and there won't be a problem.

[Phil ..:: domicilis.biz ::..]

I use cgi-bin only for admin-defined files, related to payment
certificates, the idea was to hide this file in standard install,
without having to do another action, but putting it in cgi-bin is
maybe a bit tricky... I was thinking about an option to specify config
file absolute path :-)

2010/3/14 Alexander Obuhovich <aik....@gmail.com>:

[Dmitry Andrejev]

Hi Phil,

I agree with Alex, we can't depend on cgi-bin folder at any point. What about windows installations?

Basically there are too many complications just because of your clients or someone else. As Alex pointed out it's easy enough to provide FTP access to specific folder.

We can consider the option for moving config.php inside the files down on the road, but don't see it as priority now since it worked just fine for years.

Thanks.

[Phil ..:: domicilis.biz ::..]

Hi there,

it's not a specific demand for me, just an idea, but you are right on
all points, please discard my idea :-)

P.

2010/3/16 Dmitry Andrejev <dand...@gmail.com>:

[Dmitry A.]

Hi guys,

I gave a second though to idea of moving config.php away from the root
of the site.

And more I think about it - more I realize we should move both
config.php and debug.php files elsewhere - ie. tools/ or core/

Why? because in some cases we files will store sensitive information
and it's not a good idea to keep both on top.

Since we are processing the WHOLE site via index.php so let's leave it
there and other system depended files move away so it's more secure
and clients don't have a chance of messing up the site or enabling DBG
for them ;)

DA.

On Mar 15, 7:43 pm, "Phil ..:: domicilis.biz ::.."

<p...@domicilis.biz> wrote:
> Hi there,
>
> it's not a specific demand for me, just an idea, but you are right on
> all points, please discard my idea :-)
>
> P.
>

> 2010/3/16 Dmitry Andrejev <dandre...@gmail.com>:

>
>
>
> > Hi Phil,
>
> > I agree with Alex, we can't depend on cgi-bin folder at any point. What
> > about windows installations?
> > Basically there are too many complications just because of your clients or
> > someone else. As Alex pointed out it's easy enough to provide FTP access to
> > specific folder.

> > We can consider the option for movingconfig.php inside the files down on

> > the road, but don't see it as priority now since it worked just fine for
> > years.
>
> > Thanks.
>
> > On Mon, Mar 15, 2010 at 7:13 PM, Phil ..:: domicilis.biz ::..
> > <p...@domicilis.biz> wrote:
>
> >> I use cgi-bin only for admin-defined files, related to payment
> >> certificates, the idea was to hide this file in standard install,
> >> without having to do another action, but putting it in cgi-bin is
> >> maybe a bit tricky... I was thinking about an option to specifyconfig
> >> file absolute path :-)
>

> >> 2010/3/14 Alexander Obuhovich <aik.b...@gmail.com>:

> >> > About "cgi-bin" it won't be working any more since 5.1.0 release,
> >> > because
> >> > In-Portal won't be searching for it's code throughout the document root,
> >> > but
> >> > only inside "core" and "modules" folders on top level of in-portal

> >> > installation (whereconfig.php is located).

>
> >> > About FTP access you could given access only to "themes" folder and
> >> > there
> >> > won't be a problem.
>
> >> > On Sun, Mar 14, 2010 at 10:58 AM, Phil ..:: domicilis.biz ::..
> >> > <p...@domicilis.biz> wrote:
>
> >> >> Hi guys,
>

> >> >> As we go on the road to redoconfig.php, I'd like to suggest an

> >> >> important security idea:
>
> >> >> We sometime need to give an FTP access to external partners, such as
> >> >> companies who help for SEO.

> >> >> When we give this access, they can readconfig.php and grab DB

> >> >> credentials.
> >> >> Also, like we have seen before, some malicious script could give such
> >> >> FTP access.
>

> >> >> Should it be possible, like I tought, to installconfig.php into

> >> >> cgi-bin folder? I actually install gateway files into this directory
> >> >> and it makes no problem to inportal to read them here, could we do the
> >> >> same for this important file?
>
> >> >> Phil.
>

> >> >> 2010/3/14 Dmitry A. <dandre...@gmail.com>:

> >> >> > Hi Alex,
>
> >> >> > I quickly looked through the article, but haven't seen much on
> >> >> > special
> >> >> > symbols - just some basic stuff. Out of curiosity I am not getting
> >> >> > why
> >> >> > it's related if we are just writing and reading to/from the file?
>
> >> >> > In any case, Phil and others here is a task for converting
> >> >> > "config.php" into PHP format:
>
> >> >> >http://tracker.in-portal.org/view.php?id=235
>
> >> >> > DA.
>
> >> >> > On Mar 12, 1:05 pm, Alexander Obuhovich <aik.b...@gmail.com> wrote:
> >> >> >> Now I get it, thanks. Here is ini format description (just for the
> >> >> >> record)http://en.wikipedia.org/wiki/INI_file. I've checked, that we
> >> >> >> don't
> >> >> >> escape

> >> >> >> anything inconfig.php file. I think, that we should address this
> >> >> >> issue
> >> >> >> while convertingconfig.php to PHP format. We already have task for

> >> >> >> > >>> the password is stored inconfig.php but install cannot

> >> >> >> > >>> continue
> >> >> >> > >>> on
> >> >> >> > >>> step 3, and when trying to install again, Inportal act as if
> >> >> >> > >>> it
> >> >> >> > >>> was
> >> >> >> > >>> already installed, but no root password have been setup and I
> >> >> >> > >>> need to

> >> >> >> > >>> remove all DB info inconfig.php to restart install.

> ...
>
> read more »

[Phil ..:: domicilis.biz ::..]

I'm happy to read this :-)

2010/3/18 Dmitry A. <dand...@gmail.com>:

[Alexander Obuhovich]

Sounds like you are preparing In-Portal for low-security hosting. Anyone with ftp write access could place debug.php file in top or any folder and mess it all. We are not going to process that, since the best we can do is check hosting security and advice user to change something there. If he gives write permission on top folder then then he also can give write permissions to core/tools folder too.

Also, where have you seen cms systems or other php sites, that have configuration file not in top folder?

[Dmitry Andrejev]

Actually you are misleading here.

I am not trying to secure from low-security hosting - no need. I know if FTP account has a leak - nothing is going to help.

The pre-caution what we are try make here is to move all critical files away so they are NOT in the root of the website.

Why? Yesterday, I have came across one of our sites where we are using our SYSTEM PRESETS feature. Of course site has debug.php in the root. The client likes to mess with the template and definitely will end up opening config.php and debug.php - we don't want neither files to be changed. Also, in some cases if files are in the root users can acidently delete them since they are alway on the way...

Trust me - I am trying for better here :)

Then I have checked Drupal, Symfony and other more or less robust frameworks  - NONE, I repeat none put their config files in the root of the website. There is NO need of doing for us too.

I think it's a good time to get over this why we'll be doing the config change and do all things right...

Here is what I propose - we put both config.php and debug.php in system/ folder. It's always writable and for us there is NO problem with putting files there. Just imagine how beautiful and clean it will be in the root of the site.

DA.

[Alexander Obuhovich]

"/system" folder, that a strange place for them, however this whole discussion seems a bit odd to me, so no matter, place them there. I won't interfere.

[Dmitry Andrejev]

Ok, great  - I'll do a new task in 5.1.0 which will be related to the one we are doing conversion of the config.php will be done after.

DA.

[Phil ..:: domicilis.biz ::..]

I was thinking to the same place, /system, because it's system files :-)

I may appears strange for you, but it's easier to do a wrong actin on
a file in root than deleting the whole /system dir :-)

2010/3/19 Alexander Obuhovich <aik....@gmail.com>:

[Dmitry A.]

New task for moving debug.php and config.php is created

630: Move Config.php and Debug.php from root to system/ folder

http://tracker.in-portal.org/view.php?id=630

DA.

On Mar 19, 10:44 am, "Phil ..:: domicilis.biz ::.."

<p...@domicilis.biz> wrote:
> I was thinking to the same place, /system, because it's system files :-)
>
> I may appears strange for you, but it's easier to do a wrong actin on
> a file in root than deleting the whole /system dir :-)
>

> 2010/3/19 Alexander Obuhovich <aik.b...@gmail.com>:

>
>
>
> > "/system" folder, that a strange place for them, however this whole
> > discussion seems a bit odd to me, so no matter, place them there. I won't
> > interfere.
>

> > On Fri, Mar 19, 2010 at 4:56 PM, Dmitry Andrejev <dandre...@gmail.com>

> > wrote:
>
> >> Actually you are misleading here.
> >> I am not trying to secure from low-security hosting - no need. I know if
> >> FTP account has a leak - nothing is going to help.
> >> The pre-caution what we are try make here is to move all critical files
> >> away so they are NOT in the root of the website.
> >> Why? Yesterday, I have came across one of our sites where we are using our
> >> SYSTEM PRESETS feature. Of course site has debug.php in the root. The client
> >> likes to mess with the template and definitely will end up opening
> >> config.php and debug.php - we don't want neither files to be changed. Also,
> >> in some cases if files are in the root users can acidently delete them since
> >> they are alway on the way...
> >> Trust me - I am trying for better here :)
> >> Then I have checked Drupal, Symfony and other more or less robust
> >> frameworks  - NONE, I repeat none put their config files in the root of the
> >> website. There is NO need of doing for us too.
> >> I think it's a good time to get over this why we'll be doing the config
> >> change and do all things right...
> >> Here is what I propose - we put both config.php and debug.php in system/
> >> folder. It's always writable and for us there is NO problem with putting
> >> files there. Just imagine how beautiful and clean it will be in the root of
> >> the site.
>
> >> DA.
>

> >> On Fri, Mar 19, 2010 at 5:33 AM, Alexander Obuhovich <aik.b...@gmail.com>

> >> wrote:
>
> >>> Sounds like you are preparing In-Portal for low-security hosting. Anyone
> >>> with ftp write access could place debug.php file in top or any folder and
> >>> mess it all. We are not going to process that, since the best we can do is
> >>> check hosting security and advice user to change something there. If he
> >>> gives write permission on top folder then then he also can give write
> >>> permissions to core/tools folder too.
>
> >>> Also, where have you seen cms systems or other php sites, that have
> >>> configuration file not in top folder?
>
> >>> On Thu, Mar 18, 2010 at 11:16 PM, Phil ..:: domicilis.biz ::..
> >>> <p...@domicilis.biz> wrote:
>
> >>>> I'm happy to read this :-)
>

> >>>> 2010/3/18 Dmitry A. <dandre...@gmail.com>:

> ...
>
> read more »

[Phil ..:: domicilis.biz ::..]

ok, and what about the primary subject here (db credentials storage)

2010/3/19 Dmitry A. <dand...@gmail.com>:

[Dmitry Andrejev]

Please look through discussion  - Alex mentioned it.

DA.

[Phil ..:: domicilis.biz ::..]

apologizes ^^

2010/3/19 Phil ..:: domicilis.biz ::.. <ph...@domicilis.biz>:

[Alexander Obuhovich]

Here one problem with moving.

We want to move "config.php" from top folder to "/system" folder (or system's only writable folder). That only writable folder is configured inside config.php itself.

So at the end we want to open config.php file, but to locate it we need data from that file.

What should we do.

[Dmitry Andrejev]

Hi Alex,

Answer to your question and other comments:

1. We should use "system/" folder as default path for Config.php and Debug.php. Make sure to adjust all installation checks for permissions accordingly.

2. "WritablePath" path in Config.php should remain used as is for all places as now (no changes).

The single main reason for above - we still rely to the existence of "system/" folder during the installation which totally makes sense and in 99% no one will use anything but system/ folder. Those in 1% still will be able to do what they want by keeping system folder where it is and specifying separate one for Writable operations.

I think it makes sense.

Cheers!

DA.