[SOLVED] Passwords do not work after migrating customers to another shop

[tumil]

Hi,

I need to migrate my customers' data to another shop.

I used Store Manager to export csv with all information including hashed passwords.

Then I changed the COOKIE_KEY value in the new shop. I copied the one from the old shop. I tried changing RIJNDAEL_KEY as well but nothing helps. Passwords still do not work. I checked the database and the hashed passwords are equal on both shops. What can I do to make the passwords work? I REALLY don't want to make hundreds of my customers reset their paswords

 

I'll appreciate any help

Edited July 26, 2017 by tumil (see edit history)

[selectshop.at]

You migrated from Prestshop to Prestashop, same version ? If yes, you can only migrate by using an empty database and import products direct from database and not via csv import. In this cae import should be done via phpMyAdmin. It is not posible to migrate hashes when you use a new database created by Prestashop install, onyl when ou create it wit. By installing prestashop it creates a new database with new hashes.

 

What you should do: create a new database with phpMyAdmin and transfer all data with phpMyAdmin and database dump and use old cookie_session and Rijndael hash. Than it will work. BUT the version of Prestashop should be the same, if it is not the same than no way ! In this case the only way is by creating new passwords on new hash.

 

The only way to migrate passwords is, when they are not encrypted, so plain text. When they are imported, than they are encrypted with the new hash and will work too. Yo if you don't want our customers have work, than you should decrypt the passwords into plain text with tools.

[tumil]

The old shop is 1.6.0.14, new one is 1.6.1.6

 

So how could I decrypt them? I imagine it won't be easy

[selectshop.at]

You will find tools on the net. Search with Google

[tumil]

Unfortunately these tools do not work. I guess passwords cannot be decrypted without this cookie_key and it is not considered during decryption with tools you mentioned. Anyway, these tools cannot handle this situation.

So... there's nothing I can do?

[selectshop.at]

It depends, if your database is using salt or not. If yes, than impossible to decrypt. In this case you should let your customers renew their passwords.

[selectshop.at]

Why you don't use the 1-click-update module for to upgrade your Prestashop and is using a new install instead ? Inherit one version, it is not necessary to go by this way. Better is to make an upgrade with module.

[DataKick]

Hi,

I need to migrate my customers' data to another shop.

I used Store Manager to export csv with all information including hashed passwords.

Then I changed the COOKIE_KEY value in the new shop. I copied the one from the old shop. I tried changing RIJNDAEL_KEY as well but nothing helps. Passwords still do not work. I checked the database and the hashed passwords are equal on both shops. What can I do to make the passwords work? I REALLY don't want to make hundreds of my customers reset their paswords

 

I'll appreciate any help

 

I've just checked authentication process on both 1.6.0.14 and 1.6.1.7 and it's the same - password is stored to db as md5 hash salted by _COOKIE_KEY_. Nothing else.

 

So the process you described in your original post must work, unless:

 

1) you use some custom code to handle authentication (some module or override that adds additional security or whatnot)

2) you didn't copy value of _COOKIE_KEY_ correctly (I bet this is the problem)

3) password value in db password weren't coppied correctly (for example, there may be an invisible space at the end)

 

 

You can verify the hashing algo using following query.

 

I have customer with password == 'password', my _COOKIE_KEY_ is s2cV9T6YzSm1hH18Bvqrdiv3UNIGted6Czvn4sqkavtd80D28pM2YIiY

 

SELECT email, passwd, MD5('s2cV9T6YzSm1hH18Bvqrdiv3UNIGted6Czvn4sqkavtd80D28pM2YIiYpassword');

 

+--------+----------------------------------+-------------------------------------------------------------------------+

| email  | passwd                           | md5('s2cV9T6YzSm1hH18Bvqrdiv3UNIGted6Czvn4sqkavtd80D28pM2YIiYpassword') |

+--------+----------------------------------+-------------------------------------------------------------------------+

| [email protected] | fd8e8bf54bf006c881d2cb4982cab953 | fd8e8bf54bf006c881d2cb4982cab953                                        |

+--------+----------------------------------+-------------------------------------------------------------------------+

 

As you can see, the generated hash is the same --> hash depends only on _COOKIE_KEY value concatenaded with plain text password.

[tumil]

Hmmm

Maybe I could try with a simple database export/import from phpmyadmin instead of using Store Manager.

The thing is that when I try to import the table exported from the old store, I get the info about 22 or so queries loaded and there is no data imported :/

 

The COOKIE_KEY is the same, but when I checked one of the customers, the password and secure_key were different so I think there is some problem with importing

Edited July 24, 2017 by tumil (see edit history)

[DataKick]

Hmmm

Maybe I could try with a simple database export/import from phpmyadmin instead of using Store Manager.

The thing is that when I try to import the table exported from the old store, I get the info about 22 or so queries loaded and there is no data imported :/

 

The COOKIE_KEY is the same, but when I checked one of the customers, the password and secure_key were different so I think there is some problem with importing

 

Well, how do you import your data? As csv? If so, than the passwords will be hashed once more - csv import expects plain text password, but you are providing already hashes.

 

To overcome this, just (temporarily) edit file controllers/admin/AdminImportController.php and delete lines 2040 - 2401

 

// delete following
if ($customer->passwd)
  $customer->passwd = Tools::encrypt($customer->passwd);

 

Then reimport your csv file and it should work, hopefully 

Edited July 24, 2017 by DataKick (see edit history)

[tumil]

Thanks for your help. It turned out that all this decrypting stuff wasn't necessary and the problem was that some e-mails were connected to both guests and customers accounts and that's why password didn't work

The solution was to delete some guests from csv file - those guests that had their customers accounts as well