|
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:
|
_______________________________________________ Asterisk-Biz mailing list Asterisk-Biz@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-biz
