It looks like the cc_number_enc and cc_cid_enc fields in sales_flat_quote_payment table are encrypted without using any salt. This means that the same plaintext encrypts to the same cryptext, and unfortunately cc_cid is usually only 3 digits long. This makes the encrypted data somewhat vulnerable to a known plaintext attack. This was commented on in the Magento forums as well, when discussing why the cc id is not available by default. ("This method does however provide encryption but is possible to break using a code book algorithm").
Obviously, it would be best to just not store the cc_cid_enc field in the first place, which is the default secure setting for the application. In the chance that a merchant's website is hacked and their database is compromised, they are accepting a hell of a lot of unwanted liability in storing the card id since they are not PCI compliant.
Sunday, September 28, 2008
A good development environment
One of the best things you can do when editing a complex web application is to get a good IDE. I am using the PHP Development Tools for Eclipse, which has the great ability to display where (in the whole project) a function is declared when I am hovering over the function name. This is a giant time saver when you have a project (like Magento) with a zillion little scripts.
If you are using Windows, try and find an All-In-One zips, but if I remember, the install was not so straight forward. Otherwise, install Eclipse and then try to get the PDT installed.
If you are using Linux, just use your package manager to install the eclipse-phpeclipse package.
Also, if you need a good FTP / SFTP client, check out FileZilla. It is, without a question, the best FTP client I have used.
If you are using Windows, try and find an All-In-One zips, but if I remember, the install was not so straight forward. Otherwise, install Eclipse and then try to get the PDT installed.
If you are using Linux, just use your package manager to install the eclipse-phpeclipse package.
Also, if you need a good FTP / SFTP client, check out FileZilla. It is, without a question, the best FTP client I have used.
Saturday, September 27, 2008
Displaying Payment Information
So, the actual task at hand is to allow administrators to store and view credit card information (including the credit card verification code) and process the order offline with their own existing authorization system before purging that information from the database.
Unfortunately, nobody in their right mind will provide this functionality because credit card companies (for good reason) do not want web applications to store the unique number identifying the card. That is the whole point of the number -- only the card owner and the credit card authorizer should know it, and maybe the merchant can temporarily look at it in order to pass it along. In fact, using the saved credit card module is not recommended at all for a live production site!
Storing the CCV number (even in encrypted form) will prevent your application from being PCI compliant, and will most likely violate the terms of service of the merchant. Even further, it may make the merchant negligent in failing to properly secure customer data. There is a lengthy discussion at the Magento forums, and the Magento developers (rightly) don't want anything to do with enabling this functionality. If I were one of them, I wouldn't either.
Nevertheless, many merchants want this functionality because they want to use their existing order process and bolt on an e-commerce site as a online-ified order catalog. Many credit card authorizers now require that merchants supply this number, or face hefty transaction fees without it. As a little side project in my free evenings, I've worked at providing the following functionality for Magento:
It would be a far better plan to just pay for the service of on-line validation with one of the many available providers, both for the security of your customer's data and for your own piece of mind.
Warning: you are reading a blog in the internet! If you need real support or advice hire a real software engineer who knows what they are doing!
Ultimately, it is your responsibility to make appropriate use of this information. I provide no support whatsoever and no assurance that making modifications to your software will not cause even the most trival inconvience nor the most dire consequences. Finally, I do not seek to profit in any way from this work and will not accept anything at all.
Unfortunately, nobody in their right mind will provide this functionality because credit card companies (for good reason) do not want web applications to store the unique number identifying the card. That is the whole point of the number -- only the card owner and the credit card authorizer should know it, and maybe the merchant can temporarily look at it in order to pass it along. In fact, using the saved credit card module is not recommended at all for a live production site!
Storing the CCV number (even in encrypted form) will prevent your application from being PCI compliant, and will most likely violate the terms of service of the merchant. Even further, it may make the merchant negligent in failing to properly secure customer data. There is a lengthy discussion at the Magento forums, and the Magento developers (rightly) don't want anything to do with enabling this functionality. If I were one of them, I wouldn't either.
Nevertheless, many merchants want this functionality because they want to use their existing order process and bolt on an e-commerce site as a online-ified order catalog. Many credit card authorizers now require that merchants supply this number, or face hefty transaction fees without it. As a little side project in my free evenings, I've worked at providing the following functionality for Magento:
- update the existing credit card module to store the card verification number in addition to just the card number
- allow the card verification number to be displayed on the order processing page in the administration portion of the website so the customer can be charged
- add a button to the order processing page which purges the credit card number from the system once the data is no longer needed
- be as secure as possible while doing the above three inherently insecure, and arguably stupid, things
It would be a far better plan to just pay for the service of on-line validation with one of the many available providers, both for the security of your customer's data and for your own piece of mind.
Warning: you are reading a blog in the internet! If you need real support or advice hire a real software engineer who knows what they are doing!
Ultimately, it is your responsibility to make appropriate use of this information. I provide no support whatsoever and no assurance that making modifications to your software will not cause even the most trival inconvience nor the most dire consequences. Finally, I do not seek to profit in any way from this work and will not accept anything at all.
Magento is confusing.
This little blog is here to chronicle my efforts to configure Magento, an open-source e-commerce web application which I think has lots of promise.
Installing Magento on a LAMP server was pretty easy, as long as you have the very most up to date software. I recommend finding a VPS so you can install what you need at will. But configuring and upgrading functionality in the administrative portion of the site is astoundingly confusing and difficult. The Magento Wiki and Magento Forums offer some degree of help, but ultimately new developers are left to untangle the ./app structure themselves. Magento suffers from spaghetti code syndrome, which I think is a result of trying to impose a very well organized object-oriented structure on top of a scripting language. I think all developers who try to do this run into this problem -- I know I have. And to change functionality unfortunately means editing a zillion pages.
Installing Magento on a LAMP server was pretty easy, as long as you have the very most up to date software. I recommend finding a VPS so you can install what you need at will. But configuring and upgrading functionality in the administrative portion of the site is astoundingly confusing and difficult. The Magento Wiki and Magento Forums offer some degree of help, but ultimately new developers are left to untangle the ./app structure themselves. Magento suffers from spaghetti code syndrome, which I think is a result of trying to impose a very well organized object-oriented structure on top of a scripting language. I think all developers who try to do this run into this problem -- I know I have. And to change functionality unfortunately means editing a zillion pages.
Subscribe to:
Posts (Atom)