[Asterisk-biz] RE: VISA - MC - Fraud

[David Pollak]

Okay... this is turning into a hard, but fun, problem.

No way to store the MD5 of the CC #.  I did some back of the napkin and 
you could figure out the CC # from the MD5 pretty easily (CC # are 16 
digits, but the last digit is a checksum, so they're only 15 digits.  
There are "common" beginning sequences based on issuing bank, so there 
are only 11 digits.  That's about 2,000 GB of data (MD5 is 160 bits)... 
so creating the "give me an MD5 and I'll give you the CC #" database 
would span 10 300GB hard drives (well, I guess if you multiplied by the 
20 common bank prefixes, you'd get 200 hard drives, but still, it's a 
bounded problem.)

In terms of submitting stuff, the system would have to know and trust 
the organization doing the look-up request.  If I were setting things 
up, I'd make sure both parties had SSL certs issued by VeriSign so we 
know who is on each end of the communications pipe (SOAP 
requests/responses).  I'd spend a lot of money running background checks 
on the company, the company's officers, and the IT staff that had access 
to the keys and the raw CC data.  We have to be able to trust the folks 
who are submitting the raw data (both the people and the machines.)  
That way, everybody in the network knows that everyone else is the 
network is vetted and doesn't have a history of running financial scams, 
etc.

Here's the fun problem... How do we exchange data describing the 
transaction without exchanging "identifying" information which may 
violate both CC agreements and various European and other privacy laws?  
I'm noodling on that, but would love to get input from others.

So, what are some of the things to deal with?
- Running through an IP anonimizer -- most of the anonimizers are run by 
the CIA anyway, but it's pretty easy to get the current hot anonimizers 
and the current IP addresses used by the anonimizers and block them.
- CC and PayPal accounts that show up in IRC channels -- Put bots in the 
hacker and underground channels and block CC #'s and PayPal accounts 
that are exchanged.

How much would merchants pay for such a service (even if it was not a 
profit-making venture, it's going to cost something)?  25 cents a 
transaction?  50 cents a transaction?  How much up-front (doing 
background checks are not free) $5K, $10K?

How could we work to get on the right side of VISA, MasterCard, etc.?  
While they have some incentive to eliminate fraud, they probably don't 
have a ton of incentive to deal with online fraud for smaller vendors 
(they just push the costs back to the vendor in the form of charge-backs 
-- it's tougher for them to push the risk onto Amazon or Target.)  There 
may be an interesting Homeland Security aspect to this as well.  Given 
the dangers of telecommunications fraud or more specifically, the 
dangers of anonymous, untrackable communications, I'd expect they would 
want to have a system that tracked purchases of communications services.

Okay, I'm ranting... but I'd be interested in any thoughts on how to 
package up the identifying information for a CC transaction (CC #, 
purchaser, and address) into a non-identifying, non-reversible hash and 
transmit that with the non-identifying information about the transaction 
(e.g., IP address, city, state, country, postal/zip code, etc.)

On another tangent, has anyone tried shipping out a welcome letter via 
UPS or FedEx as a way of "shipping a physical good", verifying the 
address, and getting a signature?  If anyone has tried it, what were the 
successes or failures of it?

Thanks,

David




snacktime wrote:

>>Why not doing something easier
>>Just for example making a blacklist-e164.org domain and putting
>>the offending numbers with a redirection to nowhere for example
>>As like RBLS's for emails
>>So anybody can use it
>>    
>>
>
>Just so people know.  You can't run a service like that where you
>store cardholder related data (and that includes a hash of the card
>number) without being a registered third pary provider with Visa. 
>That entails going through a security audit once a year done by an
>approved auditing company, and of course having a network that meets
>the criteria.  It's not cheap and it takes a considerable amount of
>time.  For us, the biggest thing was all the written policies and
>documentation they require, but if you don't have the network in place
>that will be a considerable cost also.  Two factor authentication is
>required for local and remote admin access, data backups have to be
>made at regular intervals and archived off site, etc..
>
>Chris
>_______________________________________________
>Asterisk-Biz mailing list
>Asterisk-Biz at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-biz
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-biz/attachments/20050619/e475726f/attachment.htm