

A simple way to prevent credit card fraud? - deets

Ok, I'm not a cryptographer, so I might be missing something here big time.<p>But the whole PSN-disaster (I'm a customer) made me think: there is good reason to store credit card information, like the PSN did. Because, frankly, I'd be annoyed to enter a 16 digit number each time I buy some 10 buck game.<p>But <i>why</i> can't SONY (and anybody else who works with credit-cards) just encrypt them with a public key they agreed on with the CC-company, and only they can decrypt it? So if there was a security breach, we just revoke the key, and are done with it? Is that too simple?
======
Ixiaus
The best way to handle it is to have your gateway handle the storage of CC
data - gateways (Authorize.net - CIM, Braintree - Vault, etc...) have the
resources and incentive to be PCI compliant.

With it stored on your gateway's servers, they will usually provide an API
that you can use to issue transactions against the stored user data (it
shouldn't _return_ the CC data, just run transactions against it).

I'm heavily against storing CC data on my own servers - I store the last 4
digits (for display purposes to users) but that is _it_.

~~~
CoachRufus87
is it a PCI violation to store the expiration month/year of a customers CC
(for the purpose of knowing when a CC expires and reminding the card holder to
update their info)

~~~
Ixiaus
I believe it is a violation to store the expiration date without encrypting
it. I could be wrong, here is a link to PCI DSS standards documents.

~~~
CoachRufus87
hey could you send me that link again?

Edit: I looked up the document, TL;DR - you don't need to encrypt the
cardholder name, service code, or expiration date unless you are also storing
an associated primary account number.

------
asharp
There is something similar called token payments that is what most people
(hopefully) use.

Basically when you get somebodies CCard, you take the details and pass them to
the provider (storing them nowhere). You then receive back a token.

You can then bill said token like a standard card, but on compromise you can
just invalidate all the tokens and no sensitive data has leaked.

------
tgrass
If developers do not quickly self-police, we will inevitably see government
web regulation on password and cc security, which itself will lead to demands
and ultimately the reality of web development accreditation.

