X-Cart forums

[jrsvsp]

Originally Posted by Ksenia

If you upgrade the database on a dev server, when you move the upgraded DB back to production server you need to edit config.php of production copy as follows:

1)copy $blowfish_key and security keys ($xc_security_key_session, $xc_security_key_config, $xc_security_key_general) from dev copy

or
2) Set these constants to 'false' so that the secret keys will not be checked:

const CHECK_CUSTOMERS_INTEGRITY
const CHECK_XAUTH_USER_IDS_INTEGRITY
const CHECK_RESET_PASSWORDS_INTEGRITY
const CHECK_CONFIG_INTEGRITY

Hi

Could we maybe have a bit of explanation of what these options do ? I much appreciate the tightened security but I think the implications can catch you out. The description in the manual seems to imply this only affects Admin users not all customers (is this correct ?), but is not clear what exactly "checked for authenticity" does.

......defines whether admin and (X-Cart PLATINUM) provider profiles in the xcart_customers table should be checked for authenticity to prevent their malicious faking and stealing.

I assume you will get the same problem if you move a live store to different server? Does regenerating the blowfish key re-set all the secret keys as well ? So can you set the options to "false", log on, regenerate the blowfish key & then set them back to "true" ?


Thanks

[cflsystems]

Yes this is how it will work - you can set them to FALSE to turn them off and then regenerate the blowfish key which will also regenerate these security features keys as well.

The big huge problem here is with upgrades - if you do this then you cannot sync the db later before site goes live since the new blowfish key will be different. If you use the one from the old store you are back to square one...

There is no option to "generate security keys only" so re-generating blowfish key will re-generate security keys as well but there is nothing mentioned about this in admin...

[albertchui]

hi, has anyone successfully install brain tree, it seems it has bug of this mod or not compatible with 4.6, my store was running smooth but after upgraded the payment can not go through brain tree's valve, i contacted xcart, then they upgraded the brain tree to the version for 4.6, i installed it and showed all successfully installed and patched, but still not work, the ridiculous thing is xcart ask me to pay $99 to fix it. anyone can tell the problem will be very appreciated, thanks

albert

[Ksenia]

Originally Posted by cflsystems

@Ksenia
I tried option #1 and it did NOT work. Again if these security features are tied to the IP address they will never work when moved from one server to another unless keys are regenerated which is impossible without login in to admin or doing "forgot password".... Since even with all of them OFF you still can't login to admin the only way left is "forgot password"....

Steve, I'm sorry for delay with reply -I was preparing the "Great Summer Sale" and had a lot on my plate. Now that the countdown is already started, I can ease off a little.

I have consulted with Ildar, Head of maintenance group, below is what I found out.

Default distributional package ( as well as upgrade packs) protect by IP only:
*several pages, such as 'patch/upgrade center', security settings.
*current admin's session ID


if the transfer of the following keys:

$blowfish_key
$xc_security_key_session
$xc_security_key_config
$xc_security_key_general

has not helped, we suppose the possible reasons are:


1)PHP version on dev server is >=PHP5.3, while on production server PHP 5.2 is installed

2)One of the following was not completed successfully on dev server:
-config.php pathcing
-Security keys generation
-signatures update during the upgrade

3)Protection by IP is enabled:
***const BLOCK_UNKNOWN_ADMIN_IP = TRUE;
or
***const ADMIN_ALLOWED_IP = '<YOUR_IPs>';


To find out the exact reason you should contact the support team, as access to your production server is required or successful troubleshooting.

[Ksenia]

Originally Posted by jrsvsp

Could we maybe have a bit of explanation of what these options do ? I much appreciate the tightened security but I think the implications can catch you out. The description in the manual seems to imply this only affects Admin users not all customers (is this correct ?),

Hi Julian.

Yes, 'CHECK_CUSTOMERS_INTEGRITY' is responsible for admins and providers only. The other users ('c' and 'b' - customers and partners) are not affected.

Originally Posted by jrsvsp

but is not clear what exactly "checked for authenticity" does.

Important fields related to admin's account, such as password/id/email/login/usertype/status/signature are combined with *$xc_security_key_session key and the result is encrypted with irreversible hash function sha1, the result is saved in database.

On every admin's action the hash is being calculated and compared with the one from DB.

What it gives:

once the hacker changes whatever field (password/id/email/login/usertype/status/signature SQL), say, via SQL injection, he can not generate the new correct signature as the key ( $xc_security_key_session) is not known to him.

X-Cart will log him out during the next action or will not allow logging in at all.

Originally Posted by jrsvsp

I assume you will get the same problem if you move a live store to different server?

If you don't move

$blowfish_key
$xc_security_key_session
$xc_security_key_config
$xc_security_key_general

the users will not be able to login indeed - just as it happened in previous versions if the wrong $blowfish_key was used.


For versions 4.5.5 and higher, the problem with login is also possible if your old server has PHP >=5.3 and the new one has PHP 5.2.

Originally Posted by jrsvsp

Does regenerating the blowfish key re-set all the secret keys as well ?

Yes.

Originally Posted by jrsvsp

So can you set the options to "false", log on, regenerate the blowfish key & then set them back to "true" ?

If the $blowfish_key is not transferred, or if there's a PHP5.3->PHP5.2 problem, the login will not be possible regardless of the value of these constants.

If the login is successful, but there's a problem with signatures, your scenario will work.

But before you generate the valid signatures you should make sure if the invalid ones are not the result of successful hack attempt ( changes in database)

Thank you.

[cflsystems]

Originally Posted by Ksenia

Steve, I'm sorry for delay with reply -I was preparing the "Great Summer Sale" and had a lot on my plate. Now that the countdown is already started, I can ease off a little.

I have consulted with Ildar, Head of maintenance group, below is what I found out.

Default distributional package ( as well as upgrade packs) protect by IP only:
*several pages, such as 'patch/upgrade center', security settings.
*current admin's session ID


if the transfer of the following keys:

$blowfish_key
$xc_security_key_session
$xc_security_key_config
$xc_security_key_general

has not helped, we suppose the possible reasons are:


1)PHP version on dev server is >=PHP5.3, while on production server PHP 5.2 is installed

2)One of the following was not completed successfully on dev server:
-config.php pathcing
-Security keys generation
-signatures update during the upgrade

3)Protection by IP is enabled:
***const BLOCK_UNKNOWN_ADMIN_IP = TRUE;
or
***const ADMIN_ALLOWED_IP = '<YOUR_IPs>';


To find out the exact reason you should contact the support team, as access to your production server is required or successful troubleshooting.

None of the above. It just didn't work. I still have to do db sync before going live so we'll how it goes.

P.S. The dev server is on PHP 5.3.x and live one is on PHP 5.3.x as well but it was upgraded from PHP 5.2.x - I cannot remember if the upgrade happen before or after.

[stonezafu]

To everyone who has so far posted on this thread

Guys, I just want to say how helpful it's been to read this thread. I'm about to trial-upgrade two sites on my dev server; a 4.4.4 > 4.6.0 and a 4.5.5 > 4.6.0. I've spent most of today just setting up various shop copies to begin the leap-frogging process for 4.4.4 and have already fought hard with the extra security issues so I could break back into my site[s]. As the dev server is on an internal network it doesn't send me email messages, so I can't very well use Forgotten Password. Turning off the new security items in config.php greatly simplified things with a replaced (i.e. imported) blowfish key.

In a strange way it's actually very heartening to see the curses and shrieks of long-time senior users on this thread - they've made a huge time investment in many generations of this software and are giving time [again] to the forum discussion. It puts my day's frustration into perspective. If they can still stick at it, I guess I can.

So a big thank you to one & all, but especially to Addison, Carpeperdiem & Steve[cflsystems] who featured here a lot and appear to have been digging into the code-base very productively on everyone else's behalf.

[cflsystems]

Good luck. You're gonna need it

I have done at least 2 dozens of upgrades to 4.5.5. and 4.6.0 now and not one of them is using the new security features. All these store owners keep them OFF - for one half of them don't even understand what these security features do, mean and how they work, and also all of these owners have issues with these security features so they prefer to turn them OFF instead of having some sort of login issues all the time...

I don't blame them...

[random]

For all users who wasn't able to see Bill Me Later button, even if it is enabled - this issue is related only to upgraded to 4.6 stores and doesn't affect new installations.
There is a simple workaround here - just delete PayPal payment gateway and add it back. Don't worry, payment method configuration will be preserved.

[random]

Originally Posted by cflsystems

This bug still exists in 4.6.0 - I first spotted it in 4.4.x...

In skin/common_files/modules/Advanced_Order_Management/edit_customer.tpl

Thanks for pointing this out (as well as for other bug reports here).
We'll fix it.