Though nowadays a full-scale shopping cart migration can be performed in terms of several hours, it is a process of a high back-end complexity. Among a wide specter of entities available for transfer, store owners often complain about the lack of customer password migration possibility. Cart2Cart, for example, has recently established the support of such an entity, though only for a limited number of shopping carts. In fact, we’ve created a dedicated page with a table of migration pairs within which password migration is available. But what differs product from password data migration? In this article we’ll try to figure out what is so tricky about it and what are the risks of incautious code manipulations.
Password Migration Obstacles
Being a string of characters used for user authentication, passwords secure secret/private information from those who should not gain the access to a resource. As any other shopping cart data, they are stored on a server allowing customers to login onto their accounts. The fact that a password database is reachable by anyone who can gain access to the server (legally or illegally), leads to the need to keep the passwords securely themselves. And that is when hashing plays its part.
Hashing - is the transformation of a string of characters (password in our case) into a fixed-length value or key that represents the original string. In other words, hashing plays a cryptographic function and puts a “password” on a password. As a cryptographed output is practically impossible to invert (and get the original character string), we get a reliable way to store customer passwords. So what’s the migration problem?
Every shopping cart out there is a unique piece of code written on different programming languages, using various technologies and offering distinct possibilities. That’s what allows you to choose from - which is good - and that’s what puts limitations on data migration - which is bad. As a result, password migration can not be performed between shopping carts that vary in the hashing algorithms they use. Encrypted passwords would not make any sense for a shopping cart that uses different algorithm, turning them into a bunch of useless character lines.
The Green Light
Nonetheless, customer password transfer is possible provided that:
- Target and Source shopping carts use the same hashing algorithm
- Target and Source shopping carts both use / both don’t use salt*
When both of these conditions are followed, passwords can be smoothly and correctly migrated from a current shopping cart to a desirable one, and Cart2Cart offers such a possibility. Although, each case still requires individual investigation, as problems with password transfer might occur even because of extensions that in some way affect the database.
Code Manipulation Pitfalls
Another thing worth to mention is the fact that some of the dishonest market players claim to offer safe customer password migration possibility within a great amount or even all the existing e-solutions. Whenever you hear such a statement, be aware that most probably it is nothing more but cheating.
Considering the fact that password transfer between shopping carts with different hashing mechanisms can’t be performed, the only way to do it is to change encrypting algorithm on one of the platforms. Supposing it is possible, the modification of a cart’s source code might cause irrevocable and dramatic harm to your online retailer. Customer password database vulnerability, extension installation issues and upgrade inability are objectionable yet possible consequences inflicted by unwary store manipulations.
Answering the headline, password migration is a reality distorted with a bunch of myths. We hope that this material was useful and helped you to paint a clear picture of what stands behind the password migration limitations. If a Target or Source shopping cart is absent in the list of supported ones, there is always a plan B - just ask the customers to recover their passwords after the switch. And remember: safety first!