A simple way to prevent credit card fraud? | Hacker News Reader

A simple way to prevent credit card fraud?

6 pointsdeets8 comments

Ok, I'm not a cryptographer, so I might be missing something here big time.

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.

But why 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?

View on HN

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.

Agreed, I never want to store any actual data that someone could use in order to commit fraud. The legal exposure there is too great - let someone else take the blame and I'll switch providers if I have to.

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)

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.

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.

But that just delegates the problem to the gateway. My personal experience with these guys let's me assume the worst. E.g. not being able and willing to only send me confidential information with signed mail and similar things.

But somebody stores the CC-data, and I wonder why that can't be an encrypted storage only the CC-card-companies can decrypt. Of course this would need some protocol, but can it be so hard (especially when that much is at stake?)

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.

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.

Reply on news.ycombinator.com