silversurfer5150 — 2012-03-07T05:38:59-05:00 — #1
I have been building a custom checkout for my e-commerce cms and I need to store some sensitive data about customers in my DB. I have managed to secure the site with an SSL certificate. I just wanted a few pointers about how to encrypt this data, which encryption algorithms etc.
If I describe how I think I can do it, would someone be kind enough to correct me if I'm wrong?
So sequence of events
- Customer enters data, form is posted.
- Detect post variables and encrypt sensitive parts using SHA-1 OR MD5?
- Insert into DB.
So the data is encrypted, how do I retrieve it, is there some code someone could share demonstrating this. Is it protected against SQL injection attacks?
Are there any other types of attack that I can protect against using the PHP code itself or is it mainly to do with firewalls ,server security etc?
serverstorm — 2012-03-07T10:08:46-05:00 — #2
Please seem my comments inline below.
If you want to encrypt/decrypt info then you need to use a two way encryption method.
You can use MyCrypt in php but it normally needs to be installed and configured. Googling I found this which is reasonibly good: [URL="http://www.itnewb.com/tutorial/PHP-Encryption-Decryption-Using-the-MCrypt-Library-libmcrypt"]http://www.itnewb.com/tutorial/PHP-Encryption-Decryption-Using-the-MCrypt-Library-libmcrypt
A way to do two-way not using MyCrypt Crypt_Blowfish from PEAR http://pear.php.net/package/Crypt_Blowfish
When you uses a two-way encryption/decrytion you run the encrypted data through the decryption methods. This type of encryption does not protect against SQL injection attacks.
Go to [ shifflet.org](http:// shifflet.org) to learn how to protect against SQL injection as well as other security vector attacks.
You seem to be on the right track, so keep going, research some more and make sure that your security is designed from the start and not later as a retro-fit. It is far easier this way.
Hope this helps,
silversurfer5150 — 2012-03-07T10:59:45-05:00 — #3
that's absolutey great, so kind of you to take the time
I have stumbled across some of the same things when googling this topic so at least you have confirmed that I'm on the right tracks.
I was also wondering if you think I should encrypt all information, I am taking simple demographic info through to card data - the whole spectrum really.
Would it be a reasonable thing to do to write some sort of loop that loops through every element in the $_POST array and encrypts each in turn before storing.
Is that even possible with the way these methods work or is it a bit overkill and should I just stick to passwords and card data?
serverstorm — 2012-03-07T12:02:04-05:00 — #4
I would always hash passwords using a combo of username + password + SALT (maybe even +PEPPER) and then validate users against it.
Unless your data needs to be REALLY secure, I would stay away from encrypting all data inside the DB. If you feel you need to do this, then look at your Database to Encrypt/Decrypt rather than doing it in PHP.
Again any data input into the application needs to be sanitized, you need to really think about all different ways you are inputting data into your application - can you trust the data or not?
I would focus on ensuring the input data limits the ability to hack or exploit. If exploited, then your design should not try to limit damage. I would also focus you have secured PHP and your DB. Make sure your server is only accessible by people you allow to access it (hard-drive theft). Don't use ROOT passwords - make explict users for any O.S. and Database users, limit hosts that are allowed to connect to the database, this includes those on your LAN and any VPN connections. Lock down your firewall so you only expose port 443 (Port 80 only if you need it). You are using the Cert so this will help against sniffers.
It is a lot of work to secure an application. It is one of the reasons that so many PHP apps are exploitable.
So I would stick to what I have mentioned plus passwords and card data?
silversurfer5150 — 2012-03-07T13:34:24-05:00 — #5
Thanks again Steve,
I have just one more question.
When you say look at your database to encrypt the data what do you mean exactly?
I am one of these really lazy developers who basically learned enough MySql to create, add, edit and delete things from the db. I can barely do a left join but I haven't had to until now because I am a strong obj-oriented programmer and I find that php has so many cool array methods, date/time functions etc, that I can do most things without performing complex MySql. Bit of an excuse I know but I definitely want to learn and improve.
serverstorm — 2012-03-07T13:44:13-05:00 — #6
This from the MySQL site provides a lot of info plus examples and considerations regarding encrypting data using MySQL: http://dev.mysql.com/doc/refman/5.1/en/encryption-functions.html
I love SQL so I have been eating up as much of it as I can recently, but fair point of only learning what you have needed to. Some people would argue that this is a more efficient way of thinking than simply learning for the sake of learning
Good luck with this!
felgall — 2012-03-07T15:13:03-05:00 — #7
One thing to realise is that encrypting the data in the database is not going to make it any more secure unless the database is on a server in a different datacenter from the server hosting the web site. Even then the encryption only makes the data more secure with respect to those people who only have access to the server hosting the database. Anyone with access to the server where the encryption/decryption code is located can easily use that code to decrypt the content.
All that encrypting the data in the database does is to ensure that the staff who maintain the server do not get to see what the content really is while maintaining the server. It would prevent their accidentally finding out things from the data - it wouldn't prevent them deliberately decrypting the data (it is unlikely that any of them would consider such an act though - at least not if they want to keep their job).
silversurfer5150 — 2012-03-07T15:32:51-05:00 — #8
Ok that's great to know so if I were to take your advice, what kind of performance overheads would I be looking at when the e-commerce engine runs due to the cross domain DB calls?
Also I presume that to set it up like that, I will have to just specify a remote host name in the db creation part of the installer, replacing what is usually localhost with a url, is that right?
thanks for your input
felgall — 2012-03-07T20:40:49-05:00 — #9
What exactly is it you are planning to store - credit card numbers and similar sensitive data is not allowed to be held on any computer that is accessible from the internet - there is a legal requirement that any database holding such data cannot be accessed remotely at all.
silversurfer5150 — 2012-03-08T06:01:49-05:00 — #10
I am going to store cred card details and demographic data on my server database. There's no law against it in the uk you just have to follow the correct regulations. I have a unique situation where i must wait for my distributors to fulfill the order, they receive a hyperlink from my site via email. They must then login and access the data.
Where do you propose I store them? Do you mean something like half in an email and half in the db?
serverstorm — 2012-03-08T07:49:41-05:00 — #11
Some payment processors allow you to do 'delayed transaction'. The user enters their credit card data and it is submitted to the gateway (not stored on the local server). They have a web portal that you log into and can complete the transactio
The Payment Card Industry Data Security Standard (PCI DSS)
ns - this would be done after you fulfill the order; this gets around the liability issues of storing credit card data on your server and reduces your complexity.
[LEFT]The Major Credit Card companies have created the Payment Card Industry Data Security Standard (PCI DSS) http://www.pcicomplianceguide.org. It is not a law, but in many ways it wraps up the 'best security practices' that are required. So you should understand what is required to properly secure all aspects of your sales process.
There may well be laws in certain countries/states/provinces/regions, so you do have to know your laws. It is generally not a good idea to store this type of data as it opens 'to many can of worms' ; however if your situation dictates that you must store this data yourself then you need to continue to learn what is necessary to safely do it.
I recommend that you talk with your payment processing company and ask what provisions they have for 'your type of payment flow'. You are not the first person faced with this task and given how hard the Credit companies have gotten slammed in the past year, you may find they are willing to provide options that help you keep the credit information with them instead of you.
Hope this helps,
silversurfer5150 — 2012-03-08T09:30:03-05:00 — #12
Thanks again Serverstorm,
I have already contacted PayPal business and they won't do fulfillment orders, they won't hold the data on a secure portal. I'm not sure who else does it, if anyone has any ideas, please let me know because I simply cannot take payments myself with this business model.
I do not even wish to find a distributor who offers a payment gateway because I have modded the engine in such a way that it allows me to select which distributor a given product will be shipped by. This way I am not tied into any one distributor and I can shop around for the best deals on different items.
The fact of the matter is that I have come up with a business model which serves the interests of the merchant(me) and not those of the big payment gateway companies and distributors.
I understand that it is a high learning curve but I am confident that I can find the best solution and protect people's data to a very high level but like I said, if anyone knows of a good delayed transaction payment gateway please let me know. I have googled and can't find one.
serverstorm — 2012-03-08T09:43:11-05:00 — #13
As I have been focusing on your encryption and security, I just now thought of one of the systems that we designed that has a 'delayed payment' feature. Essentially our payment provider allows us to securely ftp a XML file of orders to their server. Each week our system automatically generates this file and uploads/reports the success of the transfer. The bank processes this the next day.
We stay away from PayPal like wildfire as their rates are ridiculous; although they make it easier than any other bank to get a merchant (type of) account with them so I guess that's why the charge a premium to balance out this 'greater risk'.
These guys are who we use and they have been great http://beanstream.com; they are based on the West Coast of Canada near Victoria B.C.. It doesn't really matter where they are because they do all of the service for your type of application online. We use them and we are 4500Km apart. I would give them a call on your I.P. Based Phone/Skype
silversurfer5150 — 2012-03-08T10:17:27-05:00 — #14
Cool thanks Steve, I'll check them out