At 06:05 PM 1/28/02 -0500, you wrote: >Just to clarify a few technical issues folks have been talking about: > > >HASHING > >I am somewhat familiar with cc gateways. Generally, to make a cc >purchase your app needs to send a credit card gateway the following >info: credit card number, person's name (as on cc), their billing >address and their card expiry date. > >"Hashing" this information makes it useless for this purpose. > >A hash, for those of you not up on crypto terms, is an algorithm that >takes a string (of any kind) and reduces it down to a fixed-length >(usually) number. Say for MD5 (the most popular) it would reduce an >n-length string don to just 16 bytes. > >You can not retrieve information you have "hash"ed back to the >original string (it's a lossy action). You can only compare hashes to >each and see if they are the same. (If you hash two cc and their >hash's are the same then the cc numbers "probably" the same.) > > >(The type of alg that you can unencrypt the data from is basically >called "symmetric".) > >Anyway, again, hashing cc's, etc has no use for this purpose. FYI.
What I'm suggesting about hashing is using it in coordination with a system like the one that you've described below. You can't unhash the data into something useful but you can validate against the hash. So let's say that you create a credit card validation field in the customer table that's used in the site. In this you store the credit card information-- name as on the card, type of credit card, expiration date, and credit card number. You also have a field that contains the last four digits of the credit card number. On the form, you auto fill the name as on the card either from the database data or session data. You don't auto-fill the expiration date and you put a note next to it that this hasn't been filled as part of your verification system. You auto-fill the credit card field with a bunch of "x"es and the last four digits of the card. When the information goes to the site database, you send the appropriate info through the hash function and compare it to the hashed data in the database. If it matches, you assume that the credit card info matches the info in the customer database that's behind the heavy-duty firewall. If it doesn't match but the last four digits are the same, you send an error message back to the user. This would basically give the illusion of pre-filling the credit card data, but without the security issues of actually storing the info on the website in a retrievable fashion. I recommend including a password in the credit card info hash. Since you could store the password in a hash in the site data, you could combine the password that the user sends with the credit card info before hashing it to check against the site data. Again, you're trying to come up with the most secure way to give the illusion that you're doing something really convenient for them. They'll have to fill out something that isn't stored anywhere else in the site database, even if they don't see it on that form. >STORING CC's > >I advise again it basically for the possible legal reprecussions if >your site is hack, BUT... > >if you you really have to store for monthly billing's etc, the safest >way is something like: > >Buy a seperate computer. Allow only this computer to talk to the cc >gateway. Allow only other computers on that lan to talk to it. Use a >firewall between them. Set the firewall to the most hard-ass settings >possible. > >Now, add software to that computer. Only the bare essentials. >Preferably linux or freebsd with a minimal os install. Apache or >Stronghold. > >Now, lastly... you add 1) a database 2) and something to script you >code in (cf or perl or c++, whatever you prefer). This script has >three function: Add, Delete, Submit-to-gateway. > >The database has a table consisting of the cc-type I mentioned above >plus an ID field which corresponds to the ID of the customer in your >main database. > >When a customer is added (or they change cc's) you send this info to >the firewall's computer and it adds it to it's database. When you need >to bill them you send it the customer's id and the amount. The >computer then looks up their cc info and sends the data to the cc >gateway. > >In this fashion even if you main website is completely penetrated by a >hack, then CAN'T ask the firewall'd computer for any of it's cc info. > >This is basically the template you want to follow if you're building a >large business, because... even in the remote chance somehow they >manage to penetrate firewall'd computer, from a legal stand-point you >will have done about everything that is humanly possible to safe-guard >that information. > >Very usefull if it ever comes up in court. > >--min > ______________________________________________________________________ Dedicated Windows 2000 Server PIII 800 / 256 MB RAM / 40 GB HD / 20 GB MO/XFER Instant Activation · $99/Month · Free Setup http://www.pennyhost.com/redirect.cfm?adcode=coldfusiona FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
