Hi,
My PHP version is 4.3.2.
I would like to securely encrypt customer information using PHP before storing the data in a MySQL database.
Is it possible to do this using a public / private key system so that once data is encrypted on my web server it can only be decrypted on a pc with the private key (such as a PC in my office)?
Thanks,
Ben.
PHP has an OpenSSL module which supports public/private key encryption. You can read about the module in php manual under [man]openssl[/man]
benny_g wrote:I would like to securely encrypt customer information using PHP before storing the data in a MySQL database.
Why? You would be storing it in a database which is only accessible to your application anyway, on a server which is (obviously) trusted to keep data secure anyway.
Plus also, you'd have to store the encryption key on the same machine as the database (or close by, at least).
If you want to encrypt data to/from the database, you should use MySQL's SSL - but that is only relevant if you have an untrusted network between a trusted application server (running PHP) and a trusted database server (running MySQL).
Don't encrypt stuff if it confers no advantage.
Encrypting things in the database:
- Makes debugging harder
- Makes reporting harder
- Makes application development harder
- Makes searches take longer (because all your data are encrypted, so indexes don't work)
and doesn't provide any addtional security
Mark
on a server which is (obviously) trusted to keep data secure anyway.
When did we start trusting our servers to never be compromised? I certainly don't trust mine that much. If an attacker gets in he might be able to siphon off new customer information coming in, but that's no reason to hand over all the info for all my past customers.
Plus also, you'd have to store the encryption key on the same machine as the database (or close by, at least).
I think you missed the "public / private key system" part.
Don't encrypt stuff if it confers no advantage.
[...]
and doesn't provide any addtional security
Never, never work with credit cards online. Please.
MarkR wrote:Why? You would be storing it in a database which is only accessible to your application anyway, on a server which is (obviously) trusted to keep data secure anyway.
Plus also, you'd have to store the encryption key on the same machine as the database (or close by, at least).
If you want to encrypt data to/from the database, you should use MySQL's SSL - but that is only relevant if you have an untrusted network between a trusted application server (running PHP) and a trusted database server (running MySQL).
Don't encrypt stuff if it confers no advantage.
Encrypting things in the database:
- Makes debugging harder
- Makes reporting harder
- Makes application development harder
- Makes searches take longer (because all your data are encrypted, so indexes don't work)and doesn't provide any addtional security
Mark
I would like to do this as it means I can write a back-end program that runs from my office and uses MySQL on the web server as its data source.
Using public / private key encryption means that if my web server is compromised the decryption key can't be found on the server and used to decrypt the secure data. Also it means that data being transfer from the web server to my office is sent encrypted.
It makes perfect sense to me anyway ;-)
You've all missed the point.
You have to trust your servers not to be compromised. If your server is compromised, there is NOTHING you can do to stop your data from being obtained.
Even if the hard disc is entirely encrypted using the strongest encryption going, the key must be somewhere. And the attacker can simply replace the server with a fake which collects new data anyway. Or install keyloggers etc, to catch the key as it arrives (it must come from somewhere).
There is no point in storing stuff in a DB encrypted. If someone can gain unauthorised access to read it out of the DB, they will be able to obtain it anyway.
You are just obscuring stuff.
If you have an untrusted NETWORK between your web server and your database (which is a highly unlikely situation; I would rather you used a VPN), then you should enable SSL in MySQL which will encrypt everything between the web app and database, but will still store it unencrypted in the database. This is transparent to PHP.
I often work with credit card data, however, I have yet to find a reason for storing them from past transactions (despite my clients requesting that I do so) - I agree that it's a really bad idea.
If I did have a fit of temporary insanity and decide to store credit card details, I would still not encrypt them in the database.
Mark
And the attacker can simply replace the server with a fake which collects new data anyway.
I'm beginning to think you didn't actually read my post. I said: "If an attacker gets in he might be able to siphon off new customer information coming in, but that's no reason to hand over all the info for all my past customers.".
Or install keyloggers etc, to catch the key as it arrives (it must come from somewhere).
You keep missing the "public / private key system" part. The decryption key is never seen on the server. Never.
(which is a highly unlikely situation; I would rather you used a VPN), then you should enable SSL in MySQL which will encrypt everything between the web app and database
Agreed, VPN or an ssl tunnel would be much better than exposing mysql to the world.
If I did have a fit of temporary insanity and decide to store credit card details, I would still not encrypt them in the database.
Then you'd be in violation of Visa CISP, among others, and you'd be subject to a fine as well as possible loss of ability to process credit card transactions.
Ok, granted, you could use an asymmetric encryption system and store the data in a BLOB - using something like PGP.
But then you'd need a way of getting the data back out of the system again - which either means you'd need to have a copy of the private key (or pair key) stored locally, or you'd have to transfer the data to another system where it was.
I've used public key encryption for sending emails containing these things before, which seems reasonable (I wasn't totally happy with the principle of sending CC data in emails though, even encrypted).
I've no idea what the rules are on storing credit card data - I try not to do it - specifically, I never do it on any of my current or new projects (I've worked on projects which did it in the past, but it wasn't my decision to do so).
Encrypting the data using a two-way cipher would be totally pointless, and as far as I can see, CISP does not specify that you must encrypt the data in your database. They only specify that you must encrypt it as it goes over public networks.
If the contents of your database ever go over public networks unencrypted, you have more problems. Mine certainly don't.
Mark
MarkR wrote:or you'd have to transfer the data to another system where it was.
Which I believe benny_g said was the case.
MarkR wrote:as far as I can see, CISP does not specify that you must encrypt the data in your database.
Requirement 3.4 of the PCI data security standard on which CISP is built requires that "sensitive cardholder data [is] unreadable anywhere it is stored". One-way hashes, truncation, one-time pads (with the pads secured elsewhere), or strong encryption.
Then again, requirement 3.1 is that cardholder information be kept to a minimum. If you don't need it, don't keep it; and as soon as you've finished with it, get rid of it. (It was through violating this requirement that CardSystems managed to allow 40 million cardholders' details to be stolen - they weren't supposed to be storing them in the first place.)
I've no idea what the rules are on storing credit card data
I'd suggest you go read over all the CISP stuff anyway, because just accepting credit cards is enough to be bound to it. That is assuming you're accepting credit cards directly, and not using something like paypal or authorize.net sim to accept your credit cards off site.
As far as I'm concerned, all of my projects obey all of the rules of the payment providers I use. We are taking card details on the site in some cases, but always pass them on immediately to a payment service provider without storing them in any permanent way.
Another reason that storing data encrypted is pretty pointless, is that you'd also have to encrypt all your temporary files and swap space in order for it to be effective - something which is difficult or impossible in many operating systems / tool libraries.
So we do not store credit card information directly in any way - i.e. none of it, no card numbers or anything else, only data that we need to repeat or refund payments via our payment provider, who provide various codes which we do store in the database (unencrypted).
Mark
As far as I'm concerned, all of my projects obey all of the rules of the payment providers I use.
If your implication here is that you will not read the CISP documentation to ensure you're in compliance (as far as Visa is concerned, not you), then that's between you and Visa. I hope you never have an issue with your projects.
MarkR wrote:always pass them on immediately to a payment service provider without storing them in any permanent way.
Which is why I mentioned requirement 3.1.
I've certainly never had any need to store such information to carry out commercial transactions. What on Earth would I use it for?
use md5 or sha and be done with it
Neither md5, nor SHA are encryption algorithms. Scrupulous, you are mistaken.
Mark
yea but sha will give you up to 256 bit hash (i think), at least 128...
Last I checked SHA2 went up to 512 bit. But you're talking about one way hashes. We're talking about encryption.
guess i should have read the whole firstpage thoroughly 
