PHP Encryption

[mtmosier]

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.

[MarkR]

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

[Weedpacket]

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.)

[mtmosier]

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.

[MarkR]

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

[mtmosier]

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.

[Weedpacket]

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?

[scrupul0us]

use md5 or sha and be done with it

[MarkR]

Neither md5, nor SHA are encryption algorithms. Scrupulous, you are mistaken.

Mark

[scrupul0us]

yea but sha will give you up to 256 bit hash (i think), at least 128...

[mtmosier]

Last I checked SHA2 went up to 512 bit. But you're talking about one way hashes. We're talking about encryption.

[scrupul0us]

guess i should have read the whole firstpage thoroughly 😉