Rails - Aug 2006 - [OT] The bad idea that is storing Credit Cards in your database

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 Luscher (BDes Hons., Provisional RGD)
{
     c = Steven Luscher Design;
     w = http://www.stevenluscherdesign.com/
     e = design@stevenluscherdesign.com;
     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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060814/f39d2795/attachment.html

On 14/08/06, Steven Luscher <railslist@stevenluscherdesign.com> 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.
-- 
Cheers,
Hasan Diwan <hasan.diwan@gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060815/08d33007/attachment.html

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 Diwan <hasan.diwan@gmail.com>
wrote:
>
>
>
> On 14/08/06, Steven Luscher <railslist@stevenluscherdesign.com>
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.
> --
> Cheers,
> Hasan Diwan <hasan.diwan@gmail.com>
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>

-- 
Kind regards,

Nathaniel Brown

Inimit Innovations Inc.
http://inimit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060815/2f983b07/attachment.html

On 8/14/06, Steven Luscher <railslist@stevenluscherdesign.com>
wrote:
>
> 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?
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 Diwan 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 Brown 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 Luscher (BDes Hons., Provisional RGD)
{
     c = Steven Luscher 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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060815/fd066917/attachment-0001.html

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 Luscher (BDes Hons., Provisional RGD)
{
     c = Steven Luscher Design;
     w = http://www.stevenluscherdesign.com/
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060815/3eac4eca/attachment.html

> 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

>
> Steven Luscher (BDes Hons., Provisional RGD)
> {
>     c = Steven Luscher Design;
>     w = http://www.stevenluscherdesign.com/
> }
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>

On Mon, Aug 14, 2006 at 03:29:18PM -0700, Steven Luscher
wrote:
> 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
2) is a good idea.

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

Steven Luscher 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:devin@ben-hur.net

  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 Luscher 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!
> 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.
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 Mornini

Wow. Simply wow. What excellent suggestions!

On 15-Aug-06, at 12:26 AM, Matt Palmer 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 Mornini 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 Luscher (BDes Hons., Provisional RGD)
{
     c = Steven Luscher 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060815/ca6a65cb/attachment-0001.html

> 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

Tom Mornini 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:devin@ben-hur.net

  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 Tue, Aug 15, 2006 at 01:09:19AM -0700, Steven Luscher
wrote:
> Wow. Simply wow. What excellent suggestions!
> 
> On 15-Aug-06, at 12:26 AM, Matt Palmer 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!
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."

On Aug 15, 2006, at 2:02 AM, Steven Luscher 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

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. :)  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:devin@ben-hur.net

  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:
> Tom Mornini 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.
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 Mornini

>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:devin@ben-hur.net

  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