Password Encryption
Permalink
I am working on the plan for upgrading a clients site from 5.6 to 5.8, clearly this will be a very manual process, especially due to the large amount of customised build out.
My question is about Password Encryption. When the new site is running the plan is to transfer in the existing users in the 5.6 system. There are about 180,000 users listed in the user table, of which there are about 50,000 active users. I understand that the encryption used is different between C5.6 and C5.8. What I want to avoid is having to ask every single user to reset their password, that would not be pretty. I intend to script the transfer of the users in a separate php process. I also need to make sure that the uid for each row is maintained between systems. That uid is used as a foreign key.
Is there a way to decrypt the password in C5.6? I do not expect a reply here and I am happy to provide my email address to anyone that can provide a positive solution.
I have full access to the existing code base, including seeds etc.
Thanks for any advice.
FaganSystems
My question is about Password Encryption. When the new site is running the plan is to transfer in the existing users in the 5.6 system. There are about 180,000 users listed in the user table, of which there are about 50,000 active users. I understand that the encryption used is different between C5.6 and C5.8. What I want to avoid is having to ask every single user to reset their password, that would not be pretty. I intend to script the transfer of the users in a separate php process. I also need to make sure that the uid for each row is maintained between systems. That uid is used as a foreign key.
Is there a way to decrypt the password in C5.6? I do not expect a reply here and I am happy to provide my email address to anyone that can provide a positive solution.
I have full access to the existing code base, including seeds etc.
Thanks for any advice.
FaganSystems
Actually, it seems C5 5.7 and above are checking for legacy salt for passwords and there is a setting where you can the salt value so I suppose that's meant to allow you to import legacy user accounts.
If you look in concrete/config/concrete.php you will see on line 692 that you can set a legacy salt value
Then in concrete/src/User/User.php you will see the _construct function checks for that value to decide if it is a legacy password or not and uses a specific function to check if the password is valid (around line 171)
you can check this tutorial to find out how to set your setting value:https://documentation.concrete5.org/developers/configuration-and-key...
If you look in concrete/config/concrete.php you will see on line 692 that you can set a legacy salt value
Then in concrete/src/User/User.php you will see the _construct function checks for that value to decide if it is a legacy password or not and uses a specific function to check if the password is valid (around line 171)
you can check this tutorial to find out how to set your setting value:https://documentation.concrete5.org/developers/configuration-and-key...
Hmm, looks like everything necessary is in place for password conversion - except for the actual import of legacy user data.
(There is a csv to user import addon in the PRB at the moment. Its a bit slow resolving issues and does not do anything special with passwords, but may provide the rest of the solution)
(There is a csv to user import addon in the PRB at the moment. Its a bit slow resolving issues and does not do anything special with passwords, but may provide the rest of the solution)
[Comment deleted]
We just finished migrating from V5.6 to 8.1.
We used the 5.6 data and password salt, and we were able to migrate without having user changed their password with no problem.
If you need some assistance, we can help.
We used the 5.6 data and password salt, and we were able to migrate without having user changed their password with no problem.
If you need some assistance, we can help.
HI katz515,
Thanks for the offer, we are still in the planning stage but very close to starting.
The big challenge is the very large amount of custom code build out that still makes use of many of the core id's such as C5 uID, fileid being the biggest two. It is a large site, 185,000 users of which some 80,000 are still active, 420,000 files, many are linked to extended data in the users dataset, This alone will be a challenge to move it to a 5.7 or 5.8 (final version v8.1) and still maintain the relationships.
There is also a collection of content pages of custom types, both Blogs and Productions that I am hoping I can transfer with the legacy transfer tool.
The sheer scale of the amount of data means its not going to be a quick transfer but I have to make it as automated as possible so that when the actual go live occurs I can get all of the latest data with a minimum of down time. A lot of the project time will be in migrating the custom code.
What sort of site did you migrate?
Thanks
Martyn
Thanks for the offer, we are still in the planning stage but very close to starting.
The big challenge is the very large amount of custom code build out that still makes use of many of the core id's such as C5 uID, fileid being the biggest two. It is a large site, 185,000 users of which some 80,000 are still active, 420,000 files, many are linked to extended data in the users dataset, This alone will be a challenge to move it to a 5.7 or 5.8 (final version v8.1) and still maintain the relationships.
There is also a collection of content pages of custom types, both Blogs and Productions that I am hoping I can transfer with the legacy transfer tool.
The sheer scale of the amount of data means its not going to be a quick transfer but I have to make it as automated as possible so that when the actual go live occurs I can get all of the latest data with a minimum of down time. A lot of the project time will be in migrating the custom code.
What sort of site did you migrate?
Thanks
Martyn
You could modify the 5.7/5.8 password mechanism use the old (5.6) encryption alongside the new (5.7/5.8) encryption, then upgrade users to the new encryption as and when they login. After a few months, the old encryption could then be removed and anyone left over due to inactivity would have to do a new password procedure.