[OT] The bad idea that is storing Credit Cards in your datab

Hello Railists and Rubyists,

I know that the topic of handling credit card numbers has been
expounded before on this list (I’ve searched the archives) but I want
to ask the question in a slightly different way, and get your feedback:

Previous discussions on the list center around what to do with the
card number after you have processed the credit card with a payment
gateway (PayFlow Pro, Authorize.net, etc…). In my case, I will
not be processing the payments in real time at all; what I need to
do is to store the credit card information, so that my client can log
into their site’s backend to process orders manually by reading
credit card numbers off the web, and punching them into the POS
machine on their desk.

My plan is this:

  1. protect against casual hijacking of the CC numbers by using 2-way
    encryption, storing the salt somewhere other than in the database
  2. delete the encrypted card number and CVV2 after each order is
    marked as paid

Does anyone have any thoughts? Better ways to do this? Warnings?

Cheers,
Steven L. (BDes Hons., Provisional RGD)
{
c = Steven L. Design;
w = http://www.stevenluscherdesign.com/
e = [email protected];
p = 604.628.9813;
}

PS. Let me apologize that my first posting to the Rails list has been
an off-topic one. What bad form â?? I’m sorry!

On 14/08/06, Steven L. [email protected] wrote:

Does anyone have any thoughts? Better ways to do this? Warnings?

How about simply storing a hash (SHA, TIGER, RIPEMD, MD5, whatever) of
the
information? When the card is keyed in, generate a hash using the same
information, if the hashes are equivalent, the card is valid.

Definately look into getting PCI certification which will decrease your
liability, and be grounds for getting insurance if needed.

http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9001637

-NSHB

On 8/14/06, Hasan D. [email protected] wrote:

information, if the hashes are equivalent, the card is valid.


Kind regards,

Nathaniel B.

Inimit Innovations Inc.
http://inimit.com

On 8/14/06, Steven L. [email protected] wrote:

the payments in real time at all; what I need to do is to store the credit

Does anyone have any thoughts? Better ways to do this? Warnings?

Yes, don’t do it. You are violating visa/mastercard regulations, or
rather your clients are and you are helping them to do so. ANY
service provider that handles cardholder data has to not only be PCI
compliant (and you would be classified as such), but has to be audited
once a year by a visa/mastercard approved auditor. You have the
resources to be compliant and pay minimum $10,000 a year to be
audited?

Chris

On 14-Aug-06, at 7:32 PM, Hasan D. wrote:

How about simply storing a hash (SHA, TIGER, RIPEMD, MD5, whatever)
of the information? When the card is keyed in, generate a hash
using the same information, if the hashes are equivalent, the card
is valid.

Thanks Hasan! That won’t work for my purposes however… as far as I
know, hashes such as those are one-way, and I will need to present
the unencrypted card number on the admin screen at a later date, so
that it may be manually keyed into a POS machine on the desk.

On 14-Aug-06, at 9:58 PM, Nathaniel B. wrote:

Definately look into getting PCI certification which will decrease
your liability, and be grounds for getting insurance if needed.

Thanks Nathaniel! I’ll look into it, but I mean â?? there’s no money
left in this project for certifications and payment gateways.

I wish there was some third party service who was already certified
in some way, that would offer storage of the card numbers only (no
processing). You’d use their gateway to store the card, and then you
can get it back, unencrypted, in a later request. I suppose, though,
that concept would put you no further ahead than homebrew 2-way
encryption?

Further thoughts? Thanks!
Steven L. (BDes Hons., Provisional RGD)
{
c = Steven L. Design;
w = http://www.stevenluscherdesign.com/
}

PS. I just realized that my email signature dates back to my PHP
days. I suppose I’m going to have to change that…

Now, tell me ? if we use a gateway such as PayFlow Pro or Authorize.net,
does that constitute sidestepping the whole PCI certification issue (since
there would be no storing of card data) or is there more to it than that?

I can see how this is going to go. I’m going to have to tell my client that
unless we go with realtime processing, they’re going to have to phone people
for their credit card numbers. Hrm…

Yikes. Capital ‘Y’ Yikes.

Using a payment gateway covers you because then they are the only ones
handling the cardholder data. It’s against regulations to display the
whole cardnumber on a webpage. It’s also a big no no to store cvv
data at all. In addition, you can’t take internet orders using a
retail merchant account. You now have to have an internet merchant
account.

Chris

On Mon, Aug 14, 2006 at 03:29:18PM -0700, Steven L. wrote:

do is to store the credit card information, so that my client can log
into their site’s backend to process orders manually by reading
credit card numbers off the web, and punching them into the POS
machine on their desk.

My plan is this:

  1. protect against casual hijacking of the CC numbers by using 2-way
    encryption, storing the salt somewhere other than in the database
  2. delete the encrypted card number and CVV2 after each order is
    marked as paid
  1. is a good idea.

  2. is a bad idea. You’re just as boned if a determined attacker steals
    your
    credit cards as if a casual attacker does. The probability might be
    less
    (where CC fraud is concerned, though, I think the casual attacker has
    been
    killed off by Darwinian evolution) but you’re still just as screwed.

Does anyone have any thoughts? Better ways to do this? Warnings?

Use asymmetric encryption. The decryption key is stored somewhere
totally
non-web-accessable and the encrypted data gets transferred off the web
at
user’s behest and then decrypted on the local machine.

  • Matt

On 14-Aug-06, at 11:02 PM, snacktime wrote:

You have the resources to be compliant and pay minimum $10,000 a
year to be audited?

Yikes! I sure don’t! Talk about an oversight on my part.

Now, tell me â?? if we use a gateway such as PayFlow Pro or
Authorize.net, does that constitute sidestepping the whole PCI
certification issue (since there would be no storing of card data) or
is there more to it than that?

I can see how this is going to go. I’m going to have to tell my
client that unless we go with realtime processing, they’re going to
have to phone people for their credit card numbers. Hrm…

Yikes. Capital ‘Y’ Yikes.
Steven L. (BDes Hons., Provisional RGD)
{
c = Steven L. Design;
w = http://www.stevenluscherdesign.com/
}

Steven L. wrote:

On 14-Aug-06, at 11:02 PM, snacktime wrote:

You have the resources to be compliant and pay minimum $10,000 a year
to be audited?

Yikes! I sure don’t! Talk about an oversight on my part.

Don’t believe everything you hear on a mailing list.

If your client is of low volume (less than 1 million CC transactions per
year), PCI compliance only requires answering a self evaluation
questionnaire annually and a quarterly network scan. That you were even
considering manual CC entry into a POS device indicates your client is
probably a level 3 or 4 merchant.

PCI compliance does not require $10K audits and isn’t that hard. Go to
the source for more details:
http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp_merchants.html

The fact that you’re asking about data storage & encryption issues tells
me you’re quite capable of meeting the requirements. You’re already
(sadly) paying more attention than at least 80% of the merchants out
there.

One issue you’re going to run into is a conflict between records
retention (for answering chargebacks, issuing refunds, issuing recurring
charges, or return customer convenience) vs data security. You may well
find conflicting guidelines and requirements. The two most common
conflicts are PCI guidelines telling you to not retain card data past
the initial transaction point conflicting with:

  1. a written merchant account agreement that stipulates that you retain
    your detailed CC transaction records for between 1 and 5 years.
  2. US Commerce or Trade requirements that you not charge for a product
    or service until it is rendered (This is problematic for back-ordered
    items, long fulfillment cycles, drop-shipping, and for
    subscription/periodic payment services – most businesses don’t get it
    right and are potentially liable for rather stiff penalties, not that
    they’re enforced very often).

(You might want to consult a lawyer for an opinion if you find that PCI
tells you to behave in ways contrary to contract and federal law.)

As to data storage, I recommend a Hardened Payment Server approach:
build a single purpose OpenBSD payment server who’s sole task is to
encrypt and decrypt card info and interface with your payment
gateway(s). Network security should be extremely high on this box,
pretty much nothing in or out except ssh and a custom port for your
payment services from a known ip list, and openings for the ports needed
to talk to the gateway(s); the box will have almost no software
installed except what’s needed to run that payment encryption and
transaction gateway service.

Upon receipt of a credit card from a web form, your app passes the
payment server the card info and gets an encrypted result for storage.
When you are ready to make a transaction, your main app requests the
payment server to conduct a transaction (passing the encrypted info).
The payment server is the only thing with knowledge of the encryption
key and the capability of turning encrypted card info into plain text.
In normal mode it only does this for the purpose of sending a
transaction to your gateway; in a special admin audit mode it can be
used to decrypt data for plain text display, but you want this to
require significant authentication.

Of course none of it matters if the business is otherwise cavalier with
keeping the data secure and controlling access to the systems.


Devin Ben-Hur 503/860-4114 mailto:[email protected]

You may not have noticed, but we live in one of the safest,
most peaceful, times in human history. In the US, the three
leading causes of death are: killing yourself, killing yourself,
and killing yourself http://tinyurl.com/msxhq.


No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.10/418 - Release Date:
8/14/2006

On Aug 15, 2006, at 12:26 AM, Devin Ben-Hur wrote:

Steven L. wrote:

On 14-Aug-06, at 11:02 PM, snacktime wrote:

You have the resources to be compliant and pay minimum $10,000 a
year to be audited?
Yikes! I sure don’t! Talk about an oversight on my part.

Don’t believe everything you hear on a mailing list.

…snip…very useful and interesting information!

Upon receipt of a credit card from a web form, your app passes the
payment server the card info and gets an encrypted result for
storage. When you are ready to make a transaction, your main app
requests the payment server to conduct a transaction (passing the
encrypted info). The payment server is the only thing with
knowledge of the encryption key and the capability of turning
encrypted card info into plain text. In normal mode it only does
this for the purpose of sending a transaction to your gateway; in a
special admin audit mode it can be used to decrypt data for plain
text display, but you want this to require significant authentication.

I think the better approach is to use public key encryption on the
web machines, passing the encrypted data to the secure payment
server, which decrypts via private key. The private key should be
encrypted itself and passphrase manually entered each time the
payment server is started, so that a hacker will not find it laying
around in a file somewhere, nor will they find a useful private key.


– Tom M.

Don’t believe everything you hear on a mailing list.

Too true.

If your client is of low volume (less than 1 million CC transactions per
year), PCI compliance only requires answering a self evaluation
questionnaire annually and a quarterly network scan.

Not true. This is commonly misunderstood. Compliance and how
compliance is measured are two different things. If the rules say you
can’t store cvv data, then you can’t store it, period. If the rules
say you have to maintain a firewall and provide at least 30 days of
video archives of where you host your servers, that applies to
everyone. Only certain companies are subject to audits, but everyone
is subject to the PCI rules. Enforcement is left up to the acquiring
banks. If one of their merchants is compromised and they were not
following the rules, then the acquiring bank gets fined. The only
safe harbor is going through the audit, or using someone that has.

PCI compliance does not require $10K audits and isn’t that hard. Go to
the source for more details:

Audits are required if you are hosting a service for someone that
handles cardholder data. That classifies you as a service provider
and subject to the audits. If you just sold them the software and
didn’t host it as a service then you would be ok. The client
wouldn’t, but the OP would.

http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp_merchants.html

The fact that you’re asking about data storage & encryption issues tells
me you’re quite capable of meeting the requirements.

Not true again. Go read the requirements, specifically the auditing
procedures which cover what they expect in depth. It’s impossible to
meet the requirements unless you have your own cabinet or cage, with
your own servers and routers. You need 30 days video archive of your
servers, written polices, some type of IDS, a full firewall (not just
a filtering router), etc…

One issue you’re going to run into is a conflict between records
retention (for answering chargebacks, issuing refunds, issuing recurring
charges, or return customer convenience) vs data security. You may well
find conflicting guidelines and requirements. The two most common
conflicts are PCI guidelines telling you to not retain card data past
the initial transaction point conflicting with:

They don’t say that.

Chris Ochs
Payment Online Inc

Wow. Simply wow. What excellent suggestions!

On 15-Aug-06, at 12:26 AM, Matt P. wrote:

Use asymmetric encryption. The decryption key is stored somewhere
totally
non-web-accessable and the encrypted data gets transferred off the
web at
user’s behest and then decrypted on the local machine.

Great one! If I understand you correctly, the card gets encrypted
with a public key, the client then calls the number up on the screen
in its encrypted form, punches it into their local decrypter with
their private key (the password to which is presumably stored in
their brain) and voila â?? plain text!

On 15-Aug-06, at 12:26 AM, Devin Ben-Hur wrote:

Upon receipt of a credit card from a web form, your app passes the
payment server the card info and gets an encrypted result for
storage. When you are ready to make a transaction, your main app
requests the payment server to conduct a transaction (passing the
encrypted info). The payment server is the only thing with
knowledge of the encryption key and the capability of turning
encrypted card info into plain text. In normal mode it only does
this for the purpose of sending a transaction to your gateway; in a
special admin audit mode it can be used to decrypt data for plain
text display, but you want this to require significant authentication.

Another great idea! I somehow start a (BackgrounDRb?) interface
between my Rails app and this Hardened Payment Server, using
authentication that’s stored in my brain. That way, when the
connection dies, access to the admin audit mode dies with it. A
hacker would have to get into the webserver, and find a way to steal
my password out of the interface’s memory, while it’s running,
without bringing it down. Complicated, but interesting!

One issue you’re going to run into is a conflict between records
retention (for answering chargebacks, issuing refunds, issuing
recurring charges, or return customer convenience) vs data security.

Good point! In this instance though, records retention won’t be a
problem. My client needs the number stored in the webserver only long
enough for them to pull it up and type it into their POS machine.
After that, their record will be on the paper slip, and can be safely
deleted from the webserver.

On 15-Aug-06, at 12:35 AM, Tom M. wrote:

I think the better approach is to use public key encryption on the
web machines, passing the encrypted data to the secure payment
server, which decrypts via private key. The private key should be
encrypted itself and passphrase manually entered each time the
payment server is started, so that a hacker will not find it
laying around in a file somewhere, nor will they find a useful
private key.

I think, between these approaches, we’re on to something!

Quality people on this list. Quality. Best first post I’ve ever made.
Steven L. (BDes Hons., Provisional RGD)
{
c = Steven L. Design;
w = http://www.stevenluscherdesign.com/
}

PS. Is it worth mentioning, for the purposes of all this PCI talk,
that I live in Canada? Do we have different rules here?
PPS. Yes, I realize that it’s so ‘pen and paper’ to insert
postscripts at the end of an email.

Tom M. wrote:

On Aug 15, 2006, at 12:26 AM, Devin Ben-Hur wrote:
I think the better approach is to use public key encryption on the web
machines, passing the encrypted data to the secure payment server, which
decrypts via private key. The private key should be encrypted itself and
passphrase manually entered each time the payment server is started,
so that a hacker will not find it laying around in a file somewhere,
nor will they find a useful private key.

I started to feel I was going into too much detail, but this is
absolutely the correct approach – the key is encrypted, the passphrase
to unlock the key is manually entered at start-up.

If the payment server is on a private switched network with the app
servers, they don’t need to use public-key (ssl) interfaces to talk to
each other (if the bad guys are inside your private net they can sniff
the stuff coming through now anyway but they still won’t get access to
the encryption key which lets em raid the whole store of card data). If
the payment server and app servers aren’t on a private switch, then hell
yes, use a secure transport layer when they talk to each other.


Devin Ben-Hur 503/860-4114 mailto:[email protected]

You may not have noticed, but we live in one of the safest,
most peaceful, times in human history. In the US, the three
leading causes of death are: killing yourself, killing yourself,
and killing yourself http://tinyurl.com/msxhq.


No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.10/418 - Release Date:
8/14/2006

On Aug 15, 2006, at 2:02 AM, Steven L. wrote:

Thanks Hasan! That won’t work for my purposes however… as far as
I know, hashes such as those are one-way, and I will need to
present the unencrypted card number on the admin screen at a later
date, so that it may be manually keyed into a POS machine on the desk.

I had to do something like this sometime back in '97 or '98, and what
we ended up doing then was using a text-to-fax gateway app to fax the
details from the server so they were never stored anywhere except the
out-tray of the fax machine. (And before you worry about how easy it
is to intercept a fax, this went through a PBX, and never transited
the public phone network.)

Walter

On Tue, Aug 15, 2006 at 01:09:19AM -0700, Steven L. wrote:

Great one! If I understand you correctly, the card gets encrypted
with a public key, the client then calls the number up on the screen
in its encrypted form, punches it into their local decrypter with
their private key (the password to which is presumably stored in
their brain) and voila ? plain text!

Ayup. If you’re into user-friendliness, you can download the data file
with
the encrypted data off the 'net into a local (GUI or text mode,
probably)
app which reads the encrypted data, prompts for the passphrase to the
private key, does the decryption and throws the data up on screen.

  • Matt


A byte walks into a bar and orders a pint. Bartender asks him “What’s
wrong?” The byte says “Parity error.” Bartender nods and says “Yeah, I
thought you looked a bit off.”

snacktime wrote:

Not true. This is commonly misunderstood. Compliance and how
compliance is measured are two different things. If the rules say you
can’t store cvv data, then you can’t store it, period. If the rules
say you have to maintain a firewall and provide at least 30 days of
video archives of where you host your servers, that applies to
everyone. Only certain companies are subject to audits, but everyone
is subject to the PCI rules. Enforcement is left up to the acquiring
banks. If one of their merchants is compromised and they were not
following the rules, then the acquiring bank gets fined. The only
safe harbor is going through the audit, or using someone that has.

Audit’s are far more expensive then compliance. I do understand the
difference. Having and executing sensible policies is much cheaper then
explaining and justifying your policies to a gang of expensive
busybodies whose job is to find fault with you.

Merchants don’t need to keep video, do you have a citation? Almost every
firewall, system isolation, and access control guideline in the PCI spec
is What You Should Be Doing anyway. (except for the stupid idea of
requiring regular password changes for all employees – the “make sure
they keep 'em on sticky notes” policy)

Audits are required if you are hosting a service for someone that
handles cardholder data. That classifies you as a service provider
and subject to the audits. If you just sold them the software and
didn’t host it as a service then you would be ok. The client
wouldn’t, but the OP would.

I didn’t even consider this, since I assumed the merchant would own and
operate the system. Perhaps a bad assumption. :slight_smile: Attention
consultants: deliver, don’t host, unless you want to be liable for your
clients’ security policies.

The fact that you’re asking about data storage & encryption issues tells
me you’re quite capable of meeting the requirements.

Not true again. Go read the requirements, specifically the auditing
procedures which cover what they expect in depth. It’s impossible to
meet the requirements unless you have your own cabinet or cage, with
your own servers and routers. You need 30 days video archive of your
servers, written polices, some type of IDS, a full firewall (not just
a filtering router), etc…

Written policies are not hard, you should already have them!
I’ve been presuming that a merchant running their own ecommerce
application is running on dedicated hardware. If they’re not, they
should be – don’t do commerce in uncontrolled environments.
Video isn’t required of low level merchants.

The two most common
conflicts are PCI guidelines telling you to not retain card data past
the initial transaction point conflicting with:

They don’t say that.

In Summer 2004 they did. My last company spent money on lawyers dealing
with it. Glad to hear they fixed that misguided requirement.


Devin Ben-Hur 503/860-4114 mailto:[email protected]

You may not have noticed, but we live in one of the safest,
most peaceful, times in human history. In the US, the three
leading causes of death are: killing yourself, killing yourself,
and killing yourself http://tinyurl.com/msxhq.


No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.10/419 - Release Date:
8/15/2006

On Aug 15, 2006, at 1:49 AM, Devin Ben-Hur wrote:

I started to feel I was going into too much detail, but this is
when they talk to each other.
I don’t think you need TLS between the app server and payment server.

The chain should look like this:

Client <- HTTPS -> Application Server <- HTTP -> Payment server.

Sniffing would only be possible within the application server,
through some sort of in-memory or in-swap attack.

Since the application server will encrypt with public key before
transmission to payment server, there’s little need to use TLS
(transport level security) between application server and payment
server, unless not all of the data transfered is encrypted.


– Tom M.

Audit’s are far more expensive then compliance.

Depends. We pay far less for our audits then most companies do, but
we did some heavy negotiating and made it easy for the auditors. We
also didn’t let them give us a bunch of BS about needing to be on
location for a week, etc… For us, the compliance is much more
expensive.

Also, there are all of these little requirements that add up. For
example password management. Most unix systems don’t come with the
password management features that are required, so you have to use
something like kerberos. Key management policies require changing
keys every 90 days, etc… By the time you add all of the requirements
up, it’s way beyond what any small/medium sized merchant can do on
their own.

Merchants don’t need to keep video, do you have a citation?

The rules are the same for everyone, there is no difference between
merchants and providers, otherwise you would see two different
versions of the PCI standard. Requirement 10 is the one that requries
monitoring, and Visa/Mastercard interpret that as meaning at least 30
days video archives. That’s pretty standard now though for most data
centers.

The two most common
conflicts are PCI guidelines telling you to not retain card data past
the initial transaction point conflicting with:

They don’t say that.

In Summer 2004 they did. My last company spent money on lawyers dealing
with it. Glad to hear they fixed that misguided requirement.

Strange. 2004 was our first year of compliance and early 2005 our
first audit. I don’t remember the PCI standard as we went off of
CISP. I remember CISP stating that you couldn’t store the card data
any longer than was necessary. As a matter of fact though you have to
store card numbers, or you can’t issue credits or perform other
functions like recurring billing.

Visa/Mastercard have never liked merchants having access to card data.
Right now they are telling acquirers that merchants need to tell them
what gateway they are going to be using before getting a merchant
account. They will be moving to requiring audits for merchants that
do not use a PCI approved provider. A ton of fraud comes directly
from merchants. Back in the 90’s before I sold my company, one of my
ex clients pulled off the largest credit card fraud in history, over
50 million total. We had dumped him as a client before it all
happened because he seemed shady. A few months after that some
merchant banks gave him their whitelists, and he charged everyone on
the list multiple times and put all the money in offshore banks.
There is still a few million they haven’t recovered, and the guy only
spent 9 months or so in jail.

snacktime wrote:

Merchants don’t need to keep video, do you have a citation?

The rules are the same for everyone, there is no difference between
merchants and providers, otherwise you would see two different
versions of the PCI standard. Requirement 10 is the one that requries
monitoring, and Visa/Mastercard interpret that as meaning at least 30
days video archives. That’s pretty standard now though for most data
centers.

You must mean requirement 9, 10 all realates to network access.

Now that I go back and look at the documents, I see that Requirement
9.1.1 does explicitly mention three month camera record of physical
access. I wonder if that was there in the pre 1.0 draft we had to work
with in 2004.

Interestingly, the assessment questionnaire doesn’t bother to ask about
this at all:

9.1 Are there multiple physical security controls (such as badges,
escorts, or mantraps) in place that would prevent unauthorized
individuals from gaining access to the facility?
9.2 If wireless technology is used, do you restrict access to wireless
access points, wireless gateways, and wireless handheld devices?
9.3 Are equipment (such as servers, workstations, laptops, and hard
drives) and media containing cardholder data physically protected
against unauthorized access?
9.4 Is all cardholder data printed on paper or received by fax protected
against unauthorized access?
9.5 Are procedures in place to handle secure distribution and disposal
of backup media and other media containing sensitive cardholder data?
9.6 Are all media devices that store cardholder data properly
inventoried and securely stored?
9.7 Is cardholder data deleted or destroyed before it is physically
disposed (for example, by shredding papers or degaussing backup media)?


Devin Ben-Hur 503/860-4114 mailto:[email protected]

You may not have noticed, but we live in one of the safest,
most peaceful, times in human history. In the US, the three
leading causes of death are: killing yourself, killing yourself,
and killing yourself http://tinyurl.com/msxhq.


No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.10/419 - Release Date:
8/15/2006

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs