Responsible Handling of Billing Information? 259
moving on asks: "I've
been asked by a client to build a fee based subscription service using
surepay as the vendor for processing credit
card transactions. Subscribers to the service will be billed X amount per month and
that is the rub. Surepay does not offer recurring billing so I will need to
store credit card numbers and related info. The question is then, how does one
best do this in the most responsible manner?" The trick here is giving
consumers the service they have come to expect from most websites,
without exposing their personal information to would-be thieves. Do you
think such a system is possible?
encryption (Score:4, Informative)
Re:encryption (Score:5, Informative)
> (internal and external)
If you're unable to do this (due to staggered billing or something) the "next best" option is a heavily restricted network.
Give your machine with the personal information precisely one network connection and plug it into precisely one machine that can talk to the secured machine on precisely one port. Have your border firewall or equivalent drop any outgoing packets from either of these machines. Only let people do work on this machine from the console. Also use a straight cable between the machines.. ethernet port to ethernet port, crossover cable.
Then you have your webserver talk to the intermediate machine to handle transactions. Process submits authorization or billing request to intermediary, intermediary talks with the database, and issues a "yes" or "no" to the querying program. At some point you'll probably have to actually transmit user data to actually do the billing, so obviously everything in this chain will be encrypted.
Then install the best intrusion detection tools you can find/afford on all these machines and hire alert people to monitor logs. Treat any unexpected traffic as an attack and have someone walk over to your machines and physically unplug the machine from the intermediary until the situation can be identified/resolved.
This obviously assumes one believes that physical separation is important and effective, which I happen to do.
If server theft is a concern you'll also want to yank out floppy drives, physically secure the server somehow, look the bios, and if you absolutely require being able to copy data to this machine give it a read-only cdrom drive.
IMO, I wouldn't back up the server except for a hard drive image you can use to reinstall everything to a known state. Were I joe online shopper, I'd much rather re-enter cc info than worry that tapes were floating around the country with my data on it.
If you did even half of this, you'd have several times the level of safety than I've personally seen on some other online merchants, and I've been through a good number of data centers.
Re:encryption (Score:2)
Most of the time this simply won't be an option. You have to keep backups. And not just so that Joe Shopper has the convenience of having his CC remembered. For starters, another poster noted that this information will be needed to correlate to chargebacks from the CC companies. Secondly, you might not just be storing CC numbers on such a server. What if you were storing other "personal information" that you wanted to ensure was secure? Depends on what you're selling, but purchase history might be one of these. That history and other data is of real value to merchants and can't be exposed to risk of loss due to hard drive failure (which is a high-probability event, relatively speaking).
In my opinion, if you can secure the machine, you can secure the backups. Hire an armored car if you think it is necessary, but storing backup tapes in a safety deposit box or other secure (off-site) location is pretty secure, especially if the information on the backup is encrypted.
Re:encryption (Score:2)
...while you're at it, give the secure machine a private IP address [isi.edu]. That way, (most?) packets from the outside to that machine be dropped before you ever see them. One more layer of crap for a would-be intruder to get through.
Honeypot (Score:2)
Re:encryption (Score:2)
It's not always "some idiot" that removes files.
Where I work, we do our payroll in-house. A couple weeks ago, we were trying to transmit the direct-deposit info to the bank, and it wasn't working. Well, it's probably our fault for keeping this in what's supposed to be a "temporary" location (like a /tmp for this specific application), but it turns out that, when that area was cleaned out to free up some disk space, the file that contains our user/password for the bank's system was deleted. Fortunately, I was able to pull it off a backup tape.
And then a few days later, we couldn't change vendor information, because the latest update for our accounting software was missing that file.
Re:encryption (Score:3, Informative)
Look at the guidelines in the Visa CISP. They have good information about this... the bottom line is: use asynchronous encryption (store your private key elsewhere and use it once-monthly to decrypt the data as you send it), use a firewall, and patch your OS often.
Cart before the horse (Score:5, Insightful)
"My Honda isn't a Ferrari..." (Score:3, Insightful)
Some things you can "sup-up", but certain features don't come on the Yugos of the world...Good luck on reprogramming the manager instead
Re:Cart before the horse (Score:2, Insightful)
I will say that the algorithms are fairly easy once all the requirements are known (the designer just hacked it - no requirement spec exists). The big problem is that you will probably find that there are tons of other things you want it to do as your requirements for recurring billing change over time.
Right on. (Score:2)
I suggest you offload it to someone else if possible. This will reduce your PR liability and allow someone else to worry about the headache. I am assuming that you are asking this here because you have no full-time computer security staff (I would not even attempt something like this without the full-time security staff in place).
Re:Cart before the horse (Score:2)
or somebodies brother in law owns the billing company.
Re:Cart before the horse (Score:3, Insightful)
Your advice is applicable to very small net businesses. It is unsuitable to serious e-commerce sites because, among other things, it leaves you completely at the mercy of the clearing provider. Imagine sending an email to all your subscribers saying "Dear valued customer, due to a dispute with our former clearing provider we have lost your card number. Could you please take a moment to go to https://...." You would lose a substantial portion of your hard-won userbase that way.
Re:Cart before the horse (Score:5, Informative)
duh...PASSPORT :P (Score:4, Offtopic)
Amazon.com (Score:4, Informative)
Using GPG always appealed to me (Score:4, Informative)
Cheers.
Re:Using GPG always appealed to me (Score:2)
The only thing that I would add to that is also partitioning the CC-number space so that an attacker who breaks one key doesn't get all the numbers, just a subset. And easy way to do this is to generate a new GPG key (say once per day) on the secure private-keys machine, and copy across the public key only to the servers. These can then encrypt the CCno with the public key, and also store the key used in the same DB entry.
That plus a bit of salting so that two different customers using the same CC number (say Husband and Wife who share a CC) don't show up as the same, and all is happy.
The dangerous bit is still going to be personel issues and access control to the private key storage, though passphrases can be used here.
I guess the issue is that if your system is going to have to be able to decrypt the CC real-time, then you can't have most of the access controls that we're talking about here. A computer is going to have to take an incoming message and load the CCno into memory at some point.
Split up the CC# (Score:2, Insightful)
Even if someone cracks the server, the database itself will not yield valid CC's.
But it's still on the server (Score:4, Informative)
If it's readable by the web server, then it's also readable by a cracked web server.
You really need the secret info on a separate machine, with the CC machine never regurgitating anything except a simple answer (valid / invalid) in response to the full set of info (CC#, expiration, name, address). The only info a cracked web server can get is answers to random info, and it would take too long for the cracked web server to try random possibilities.
Re:Split up the CC# (Score:5, Insightful)
This goes to show why it is very dangerous to "Ask Slashdot" about anything important or security related.
Re:Split up the CC# (Score:2, Informative)
Suppose you decide to store the latter half of the card number in a cookie, and some other site decides to store the beginning part in a cookie
It's worse than that. The beginning part of the CCN is just a designation for your bank.
How does Surepay store it? (Score:4, Insightful)
Maybe your question could be asked how to safely transfer it?
Choose another processor? (Score:2, Redundant)
Re:Choose another processor? (Score:2, Insightful)
There's also something to be said for keeping this data distributed. One humonguos database is a tempting target, and cracking one protection scheme nets a large return. Many small databases each with a different implementation would require a much larger expenditure of effort for the same return and might raise an alarm if other(s) got cracked first.
dont connect it to the net (Score:3, Interesting)
If you want it to be safe, use something simple and one way, like sending the details over a serial line with the rx wire cut. Cut off the database from the Internet as much as possible. Also try and restrict access within the organisation. The last thing you want is customers to find out their data has been stolen, if it happens remember you have no legal obligation to tell anyone. Keep quiet and maybe your company will still be around in 6 months time.
Re:dont connect it to the net (Score:2)
Most of the solutions posited so far in this discussion keep ignoring the fact that the data has to kept safe *and useable*. In this instance the data has to not only be stored, but sent to Surepay. For an E-Commerce site, the idea is that credit card info should not have to be re-entered everytime the user wants to purchase something. Credit card numbers are not passwords, so the simple 'box only returns a yes/valid' response won't really work for rebilling.
Why don't you ask a porn provider (Score:2, Troll)
Re:Why don't you ask a porn provider (Score:2)
Re:Why don't you ask a porn provider (Score:3, Informative)
Too bad
Simple (Score:2, Funny)
Make sure you use encryption (Score:3)
Use DESEDE or something equal. The main goal is to make it so if someone break into your database, they can't get clear text passwords, credit card numbers or expiration date. If you want to be really hardcore, you can have a different secret key for each user, which is decrypted at runtime to generate the appropriate key used to decrypt the credit card information. Make so that once the system is up, no one can get credit card information without asking the customer. This way the information is only in plain text when the charges are made to the card.
Re:Make sure you use encryption (Score:2)
All you have to do now is purchase a couple of dozen servers to do all this encryption.
Paper (Score:2)
Re: (Score:2, Offtopic)
Re:Paper (Score:3, Funny)
--
Damn the Emperor!
Re:Paper (Score:2)
Hire people to do it all manually. [snip] paper in a locked filing cabinet can't be hacked
Actually, the people are usually the easiest to 'Hack'. It's usually called social engineering.
storing info in a "secure" location. (Score:4, Insightful)
One assumes that the web server is insecure, and therefore is going to store the data on another "secure" machine.
One needs to make a very specific interface that one can use for the "insecure" machine to talk to the "secure" storage machine (this is the machine that is going to do the cc verification also)
Presumably, the "secure" machine is not going to be running any services that are accesible to remote users besides whats needed for the the web server to talk to it. One can do something like only allow the machine to talk to the "insecure" webserver, but this doesn't buy you much more security, as all someone has to do is crack the "insecure" web server and you are at the same place you were before.
Getting back to the interface these programs speak. One basically needs an "input" func, and a "status" func.
Basically when one register with the site, the werb server doesn't store any information about the credit card on itself, as it immeadily connects to the "secure" machine and uses the input function to inform it about the new account.
It can then use the status function to determine that status of that account
status can be OK, or NOT_CHECKED_YET, or NOT ACCEPTED or the like. but basically something that is read only by the server.
Both of these services should be easy for the "secure" machine to check that its getting properly formed requests (i.e. is someone is trying to attack it). One can also make a script that then verifies each account each month, and since one can do this over a phoneline, you don't even need to allow any other outbound connection from this machine.
yes, a little bit more thought probably has to go into this, but this is what I came up with a while ago. feel free to criticize away.
Lockbox, & let the customer decide... (Score:3, Insightful)
Though there is no really good way to do it, the safest way to do it is to isolate credit card info onto a seperate box, limit the access to that box to the absolute minimum required to request a charge, and have that box then directly contact the credit card clearinghouse rather than return a CC# for use by the other half of your application.
Encryption (SSL minimum, preferably also encrypted in store with keys being supplied by the other half of the application) is necessary, the lockbox code needs to be as limited in capability as can be, and what remains must be thoroughly audited to limit the likelihood of breach. No other services should run on that box, and physical access must be tight. A shared cage at Exodus doesn't do it.
Whatever you do technically, I think the most important thing is... don't forget to let the customer decide. Any app that stores CC info should allow the customer to decide NOT to have their info stored. I rarely see sites that allow me to "opt out" of having them store my credit card info, and I'd rather retype it than trust them.
Re:Lockbox, & let the customer decide... (Score:3, Informative)
Even if they are not storing your credit card info for you to use again (i.e. a profile) they are almost definately storing the info for their own reasons.
The rationale behind this is that when there is a chargeback (when a customer tells their issuing bank a transaction is fraudulent or otherwise bad) the merchant is responsible for convincing the credit card company that it was a good transaction.
The problem is that when Visa and MC tell you that you have a chargeback all they give you is the Credit Card number, date, and amount. You need to have stored in your system the details of the transaction linked to that credit card number. Otherwise you can never fight chargebacks and you'll get screwed (for aboveboard merchants ~.4% of transactions result in chargebacks).
So it's unlikely that anyone who knows what they are doing would build a system that doesn't store your credit card data. Hopefully they are securing it well.....
Re:Lockbox, & let the customer decide... (Score:2)
Re:Lockbox, & let the customer decide... (Score:2)
As long as you can keep your data safe from your employees simply encrypting the data with something robustish (RSA, Triple DES with a good size key) is gonna be enough protection).
Also the number itself isn't really the sensitive part of the package. Much of the security with credit cards is matching the number (which is easy to determine, they are not random and they only have 6-8 variable digits, plus there is a checksum/hash formula) with the exparation date. Hashing the Exp Date doesn't buy you anything since there are really only 36-48 possible values (cards only last 3-4 years). Hashing the numbers together does work, but knowing the customers exp date is sometimes important for business reasons (i.e. for subscriptions you don't want to keep charging an expired card).
So... I'd go with encrypting the whole smash and auditing who can get in and out of the encryption.
Re:Lockbox, & let the customer decide... (Score:2)
Internal Controls (Score:5, Insightful)
Most technologists spend a lot of time securing their data from external attack (i.e. a cracker). This is important but it is not the most likely threat.
Well over half of all thefts of financial data are committed by employees/trusted users of the company. Sometimes by the people who maintain the system and sometimes by others.
You combat this two ways. First with technology, the system (in this case probably a database) that contains the data should be access controled. It is also a good idea (and required by visa/MC) to encrypt the data. Another thing to watch out for is that you are not putting the credit card data into any other places, i.e. log files. you need to physically control access to the hardware running the system. Finally watch out for your backup tapes/media, especially if they are stored offsite.
On the soft side you want to have good audit controls on the data. Whatever method is used to access the data should leave a record of it doing so in a manner that is hard to compromise. People who don't need access to that data should not be allowed near it. Finally you need to be able to trust the people with access to the sensitive data, depending on the level of sensitivity this could involve cursory or invasive background checks. Banks background check their employees rather carefully, and for a reason.
lots of one-way gateways (Score:2)
I would probably choose an architecture that has a dedicated machine for just the periodic billing to the credit card processor. The machine would sit behind its own hardware firewall (real cheap now) and only be permitted to make outgoing connections (no open ports on the firewall). The web servers would gather updates to user information and make them available for pick-up by the dedicated machine; once picked up, they should get securely deleted from the web servers (keep the data off the disk, purge the swap partition periodically, worry about transaction logs).
The billing server needs to make backups of the billing information. It can encrypt those and push the encrypted data out. When the machine fails, as it will sooner or later, you can restore from the encrypted information outside the firewall.
You still need to ensure that the web servers themselves aren't compromised because otherwise people can collect data there as it is submitted by users, but you always have that problem. Personally, I like continuous monitoring of system files and network connections, together with automatic periodic reinstalls. You probably also should have independent sanity checks on the update records (check for size limits, etc.).
I'd strongly recommend not writing any of this stuff in C/C++ or Perl. In the former, the probability of pointer bugs or buffer overruns is too high, and in the latter, it's too easy to leave out error checking. I'd probably go with Java--it's not perfect, but it's mainstream and reasonably mature.
Re:lots of one-way gateways (Score:2)
I should add that if you are really worried, you can store the data in encrypted form on the server and use manual intervention (smart card, password) for decrypting it and sending it to the credit card processor. Then, the machine can only be compromised when a human is present, and you could even ensure that multiple employees have to be present for billing, if you wanted to. But that's probably overkill for credit card numbers, which are not that hard to come by and protect consumers fairly well anyway.
Yeah, right.... (Score:2)
A better solution (cost-benefit wise) would be to have an iron-clad server (SELinux, maybe) which only allowed a very limited number of possible users and programs to access the CC info. Use firewalls, and keep a full-time computer-security staff (at least one person) to be responsible for managing the security.
Re:Yeah, right.... (Score:2)
Use firewalls, and keep a full-time computer-security staff (at least one person) to be responsible for managing the security.
Of course. And what I described is one of the approaches such a person could take if security is paramount (no server ports, manual checks before any information is decrypted).
Public key crypto (Score:2)
I would imagine that the good old fashioned command line incarnation of PGP would be quite good at doing the encryption, as your write access traffic is quite likely to be very low.
Keep physical security, and redundant secure backups, and you should be set.
--Mike--
Hire the right experts. (Score:3, Informative)
Bruce S. (I'm not gonna try to spell is last name) of Applied Cryptology fame is where I would start. Read his books, do a formal design of the system, and then hire him/his company to aduit your design BEFORE you start coding.
Don't forget to have a range of secure systems to work with. Run the web server on openBSD, and have the dataBase on trusted solaris. And use a good database and firewall (none come to mind off hand. (Note I'm giving examples, you can mix and match to please, just so long as they have to break several systems to get the data, none of which trust the others)
Take the additude that your web server will be cracked. Do your best to detect that. your firewall should protect the database (unless it is hacked!), and the database doesn't trust the firewall. With good detection you should shut down the front line systems before the cracker gets to the back end.
Remember to have experts aduit your design. Have other experts audit your code. (the later is hard, but it helps a lot)
Information wants to be free (Score:3, Funny)
Ditch Surepay... (Score:3, Informative)
In terms of security/responsibility, it's impossible to create a 100% secure system, but as long as security is a focus in your software (and it isn't rushed), it's destined to be as secure as possible.
I guess I could list a few pointers to help you out, though (in random order):
Check with Visa (Score:2, Informative)
Single sign-on, encryption, restricted access, with (potential) fines for vendors that cause excessive problems. With these, Visa claims a fraud rate of 1% was dropped to 0.06%. If it were me, I'd work with either the CC processor or Visa to work out recurring payments. Make sure you're not legally on the hook for any mistakes or breaches.
My wife uses throw-a-way numbers, I change them at the first hint of a fraud problem -- both are going to cause you headaches.
I hate vendors who back-end credit card information and work very hard to avoid them. You could do us a big favor and alude to the vendor (so we know who to avoid).
Log it. (Score:2)
I'd recommend transferring the card numbers to another machine via a logging-type channel; in other words, send the card number and billing data to a logger on a machine with no other servers running. The fewer open ports, the less chance of the machine being exploited. An application on that machine could then read the log and insert the appropriate information into its database, and perform the billing functions as needed.
NIH? (Score:3, Informative)
Hopefully, there will be some insightful answers posted to
Finally, this seems like a commodity sort of task that involves lots of headaches to get right (like payroll). Perhaps it would be better to buy the solution from a vendor/service beureau that can handle your requirements and so you can concentrate on the things which differentiate you. If,on the other hand, you are in the business of managing this kind of information you should have people on your team with considerable real world experience in this.
Good luck.
Good practices (Score:4, Interesting)
1 - I use OpenBSD for firewalling. You limit connections to your machines by only allowing specific ports to connect to that machine. You can also control which way connections are allowed to connect. For instance you might wish to limit connections to your web server to port 80. For the database server that will hold the credit card data, a good way to do it would be to allow port 22 into the server, and no traffic whatsoever to leave the server.
2 - Use private key encryption. There is no need for anyone but you to have the key so use a good private-key encryption on your data server. Triple-DES is a good choice. It comes free with OpenBSD
So, basically, what you need are two OpenBSD boxen, and the expertise to set up two firewalls, SSH, and Triple-DES. Then, to get your data, a cracker has to 1)Crack two OpenBSD boxes 2) Exploit a hole in OpenSSH 3) brute-force Triple-DES.
In other words, they will be having snowball fights in the ninth layer of hell before someone gets to your data.
Re:Good practices (Score:2)
I don't get it. How will the system encrypt the card numbers if it doesn't have the key?
Careful-- your plan might be illegal (Score:2, Interesting)
If they are going the cheap way (visit their site, buy via link to surepay, return to their site), then the TOS likely says "customers must enter information themselves" (merchants cannot just fill out the 'credit slip' for them).
This comes up even with some online merchant accounts-- that the _customer_ must fill out each charge slip that gets processed, and the merchant can't just fill it out for them.
It's a crucial difference that means implementing your own 'fake the customer re-submitting the info to mimic recurrent billing' could violate the TOS and, in turn, Surepay's own arrangements for their bank.
Of course, if they're using Surepay's premium, it might be do-able-- but that that point, between paying Surepay premium plus hiring you for coding, they're best off just getting their own merchant account and having you code locally-- and securely-- to do what they wanted in the first place.
Merchant banking is not a place for hacks.
A matter of philosophy (Score:2)
up, so I'll share my experiences in implementing such systems.
Something important to remember is that security shouldn't be scaled with
popularity; sites often imagine that their (relative) obscurity insures
that they will not be targeted, that security is something that only
Amazon.com should worry about. This is, of course, far from the truth - in
my experience, thieves (I will not call them 'hackers' or anything like
that) target sites whose security and billing systems they know are small
enough not to take major security steps. The best way to approach it is to
implement a high level of security in every billing-sensitive system, not
because it is truly secure, but because other systems are less secure (the
deterrent effect).
One client I recently assisted was a medium-sized liberal arts university
who accepted online applications and the accompanying credit card info
(for application fees) with absolutely no security - everything was sent
to plain text files on the servers and then forwarded via internal email.
Their attitude was that as a university they wouldn't be targeted. They
were fortunate enough not to have lost any major information (that we
could determine) but they were foolish to put themselves in a situation
where their reputation (let alone their customers' information) could have
been compromised
More of a network design issue (Score:2, Informative)
Certainly you can wrap the calls (client or web) in something like SOAP/XMLRPC/RMI/Corba and then use an encryption package over it. I built something similar to talk to a credit card authorization system using XML over HTTPS with the Java JSSE library extensions. You could certainly do this internally and to the remote authentication system as well.
The problem most sites seem to have is where the data is located and how access is allowed. Provided you are not putting your client info DB out on the net and leave it inside and protected you shouldn't have much of a problem. Do customers need to change their credit card numbers? One assumes they do and will be prompted when the card expires. This means the web server needs to have access to that data. If not, lock it inside your network and only allow writes to the database and reads only to the monthly revalidation program. In an ideal world, the internal program would have a direct link to the payment system and not have to use the net at all. You should really try to build some data abstraction layers into the system so even if the web server is hacked it can't be used as a platform to run SQL statements directly against the customer data DB. Most of the posts here seem to be about encrytion and the like, but in reality if you allow access by the web server and it is hacked you are pretty much SOL if you have a visable API through a server-side scripted language. Just IMHO.
-J
SurePay is being discontinued (Score:5, Informative)
MordernBill and Ubersmith (Score:2, Informative)
If you want to store the info on your own servers the best solution for you would probably be ModernBill [modernbill.com]. It offers an integrated signup process and user management. It can also automatically talk to payment gateways such as AuthorizeNet. Highly reccomended by many. Check out http://www.modernbill.com [modernbill.com].
If you want to keep your customer info offsite you can check out Ubersmith [ubersmith.com], which is provided by voxel.net [voxel.net]. This is also very good and I know many people who use it. The only problem here is price. It's rather expensive to go this way, but if you can afford it it's probably the best way to go.
Hope those all help. ;)
Choose the payment software wisely (Score:3, Informative)
implementing strong security on a system, which is difficult to do right
implementing a lot of customer service tools (to look up credit card numbers, issue refunds, track chargebacks, etc.)
generally spending more time than necessary in order to poorly implement something that another company has already done. Remember, the billing services are the ones who should be figuring out how to store credit cards, be secure, etc.
2) The place to look for payment systems is: here [google.com]
3) Be sure to understand the Customer Service issue. It is quite reasonable to expect that Customer Service will ask to be able to "look at" Credit Card numbers, but consider carefully whether they need to see the Credit Card numbers or just search on the credit card numbers.
In my experience, you may end up spending more time writing the customer service interface than writing the customer interface - they may need to issue refunds to a card, they may need to investigate chargebacks (a BIG issue - especially with recurring charges.)
4) Avoid storing the credit cards if at all possible (but understand how you'll issue refunds and search for credit card numbers). As everyone states here, the security required in order to make this secure is easily weeks worth of effort. Again, picking the right payment service can eliminate this effort.
5) Remember, the client probably doesn't care about security enough to jeopardize payment - this is a clear case where the client probably wants his money more than he cares about preventing "potential attacks".
As the old saying goes... (Score:2, Informative)
Security vs. Convience (Score:2, Flamebait)
I've worked in a number of arenas tha involve handling credit card information.
Here is some of the mistakes I've seen, maybe you can avoid doing them.
I contracted at a known online shopping company. When I sat down at a terminal, my access gave me permissions to the database. My machine had a floppy drive AND a zip drive. none of the CC information was encrypted. I told my manager of that was a security problem? his response? released me for being a threat to their company.
there are at least three lessons in that story.
The only way to gain more security is force pin number use onto consumers. Not perfect, but a lot better. Oh yeah encryot it for goodness sake! good encryption. Also CC numbers that expire every 30 days.
Another idea... (Score:2, Interesting)
2) Keep the db on an internal 10.1.1.X network and only allow the db port to be accessed from the web server. Only allow ssh access from the dba's workstation. All this via firewalling, of course.
3) Use binaries for your web server programs, so that the encryption method can't be easily discovered if somehow your db server is compromised. Then, only allow the "update" priviledge to the db user that the web programs use, and...
4) Do the monthly billing directly from the database server via cron. The db server can be a 10.1.1.X machine and still have interet access via NAT.
5) Monitor your logs daily so that, in the event your web server IS compromised, you can stop them before any damage is incurred.
This crap about loading media and unloading it is not practical, since billing is going to be a daily occurence for most companies. The CC data will always need to be accesible. At least that's how things are where I work.
My solution (Score:4, Interesting)
here's what I did when I implemented the same kind of service:
first, I choose PGP (GPG) to encrypt the user's CC information in a database on a safe Linux system (firewalled and using an IDS).
here's my logic: information can be encrypted anytime using the public key, but the private key must be used for decryption. The public key is then stored on the server, but not the private one.
In case of stealing, you're safe so far.
Only one program access the CC information and need the private key. On startup, it asks for two information: the "real" private key and a "passphrase" of a minimum length. the key is then XORED with the passphrase and the result is hidden in memory. The passphrase is then given to the employees and changed daily (or anytime you wish).
So the CC info can be read if:
1- the server process was started by a thrusted admin knowing the private key, and
2- the person accessing the data know the day's passphrase.
if the passphrase is protected while being sent to the server and the employees are either "thrusted" or "unable to hack a secured unix system and debug the memory to restore an xored key", the system should be safe enough
backups can be made (the key's nowhere nead the hard disks) and the information given to the employees, the passphrase, can't be reused after the end of the day.
and if it's not secure enough for our most paranoid contenders, it's fun to realise anyway
Re:My solution (Score:2)
My methodology (and I have done direct work on this) is if it is not secure from root on the local box, it's not secure.. The software should maintain a level of segregation from that single server.
Let me give you a little bit of insight for your next run at it - variable key/algo encryption. Ensure that soon as it starts, the keys rotate and only a user logging in is able to restore the key hash properly (this can be done a number of different ways) and also ensures that only users looking at it know the key, and if you implement in a certain manner who looked at what, based off key history. It relies on a high degree of entropy, and can be CPU exhaustive but it is well worth it, imo. Being root on a box should not make any app insecure, and I hate seeing stuff like that. Employees are one thing, you can trust them. Maybe I'm missing something in your algorithm.. but it just seems that it's secure in-concept, that no one decides to attack your server. And also, it's not like the evil-ones have to know a whole heck of a lot to dump the memory of the process and work on it later, along with your CC database.
Re:My solution (Score:2)
Of course, if he was pretty smart, he could go to a good random source and sample an hour of random data onto a CD, and xor his key with that (each day could have a different offset) and rotate the disks every couple of months making sure to never repeat the offset. This would basically be a good one-time-pad type solution.
Pan
Not a simple problem (Score:4, Informative)
Credit Card reconciliation - when you bill on a monthly basis, a lot of cards expire, are cancelled, this needs to be detected, the user informed the next time he tries to use the service, etc... There needs to be good adminstrative/financial metrics to track these.
You need very good operational interfaces and a strong underlying architecture so that people get billed when they should, and not when they should not. It's easy in cruise mode, but harder to keep track as financial processors or external connectivity is down, or after an upgrade, or system crash or other usual operational down-time.
Things get also quite complicated quickly if you offer multiple subscription services (monthly, yearly, first month free, etc...)
This stuff is hard to get 100% right (and it needs to be 100% right). I agree with the other post that recommend either a provider that already does that, or buying software that already does this.
recurring monthly payment (Score:2, Informative)
Wash your hands, Cover your Ass. (Score:2, Interesting)
You have basically two options:
- Hire a security consultant
- Let your client know that they need to hire a security consultant.
Either way, you need to let your client know about this issue, and ensure that you're not going to be held responsible in the event of data loss/theft. Try to tackle this one yourself, without enough experience, and you're setting yourself up for a heap of trouble. Be a professional. Know your limitations.reminds me of an old story (Score:2)
Two guys are out camping. In the early morning, just past dawn, they hear noises near the campsite. Peeking out the front flap of the tent, they see a grizzly bear sniffing around the perimeter of the campsite. The first guy takes off running. The second guy yells, "Hey, you can't outrun a bear!" The first guy yells, "I don't have to, I just have to outrun you!"
Of course, if your site isn't perfectly secure, someone might break in and steal a bunch of CC numbers. But they're a lot less likely if your site is mostly secure and the insecure pieces involve a lot of resources (e.g. effort, money, planning, knowledge). Remember, neither the NSA nor the CIA is interested in stealing CC numbers...
Secure it (Score:2, Interesting)
Overview:
1) Put the critical private information on an isolated machine.
2) Permit authorized processes to connect to the isolated machine in WRITE ONLY mode.
3) Permit authorized processes to connect from the isolated machine to the surepay server.
4) Permit no other connections.
The details:
Set up some database server software on your isolated linux box.
Write a custom interface from the main system to the linux box which accepts the data into a chrooted environment while running as a normal user (not root).
Write software which retrieves the data from the chrooted environment (still not root) and stores it in the database.
Write software which connects from the isolated machine out to the surepay server as necessary.
Set up firewall rules (a la ipchains) such that the only connections permitted are from the general-purpose server that the user interfaces with, and to (but not from) the surepay servers.
Problems with this approach:
1) Can't verify billing status e.g. credit cards in real time.
2) Credit card data remains vulnerable during the path between when its entered at the web server and when the web server stores it to the isolated server and discards it.
NO NO NO NO NO NO KNOW! (Score:2)
OK
If you have to ask Slashdot, you aren't qualified !!!!!
The legal liabilities alone make it an extremely bad idea to even try. As others have pointed out, you started with the wrong givens. If the service that they want you to use doesn't offer recurring billing, then they asked you to use the wrong service! If you can't convince them to use one that is suitable
If you do anyway, good luck, because that is all that will save you from yourself!
Cheers!
Zero__Kelvin
Don't even bother trying (Score:2)
Possible Solution (Score:2, Interesting)
1.) Generate a new public/private key pair of significant length using PGP / OpenPGP on a detached (off the network) workstation.
2.) Store the public key on read-only media. Create two copies. One copy should be kept in a fireproof safe. The other will become a mounted filesystem on the web server.
3.) Repeat step 2 for the private key. Except, both copies of the key should be kept in a physically secure (restricted access) location.
4.) Delete the keys from the offline workstation. Delete the swap file. Wipe the free space on the workstation's hard disk. Power off the machine to clear its RAM.
4.) Mount the public key as a read-only filsystem on the webserver. Read-only media maintains integrity. I recommend it for everything critical that doesn't require writes (kernel, system binaries, HTML files). Once there are cached in memory there is no performance hit.
5. Modify your web application. Encrypt client credit card numbers using PGP and your public key.
6. When credit card processing time comes around (every night, once a week), copy the encypted credit card numbers to removable media. Retrieve the CD with your private key. Batch process the credit card numbers from an offline workstation, decrypting the numbers with the pricate key on the CD-ROM. All of this can easily be automated with shell / Perl / Python scripts.
Again, it is critical that you A) have a backup of your key pair, B) maintain the integrity of the keys with read-only media, C) physically restrict access to your keys (most importantly the private key, but it never hurts to be paranoid). Also, your private key should never come near the web server.
Remember, document the process. Define policy to administer the process. Develop contingency scenarios (what is the private key is lost, compromised, the hard disk in the web server fails, etc.). Define how you will recover from breeches in policy. Train your employees to act responsbily.
Proper cc security (Score:2)
More details can be found on my company's page about security, here [trustcommerce.com]. Allow me to boast for a moment and state that we are one of the only payment processors that uses a fully encrypted data storage system: no unencypted card numbers are ever writen to disk. Cool, eh?
As long as I'm evangelizing our service, I will also mention our Billing ID [trustcommerce.com] system. This is probably exactly the sort of thing you should be using for this application: not only does it do automated recurring billing, but it actually stores all the info in an encypted database so that you don't have to be responsible for holding that information locally. You can run transactions on the account either by using the six digit Billing ID returned by the original store transaction, or by scheduling one-time or repeated transactions through either the web interface or the TCLink API. It's a pretty nifty system, you might want to check it out for your app.
Get a better payment processor (Score:2)
I think what you are looking for is a payment processor [trustcommerce.com] which supports recurring billing [trustcommerce.com] as well as open source [trustcommerce.com] client APIs?
</plug>
No Magic Bullet (Score:2, Insightful)
There's no magic bullet for this - you can't say use GNUfoo or Sun iMumble, it'll do all you want and wipe you bum too.
The only one liner I can give you is Security In Depth. Use lots of layers of security and at every layer assume that the one above has been fully compromised. Your DMZ should be well firewalled, permit only ports 80 and 443 (HTTP and HTTPS), deny and log anything else. Your DMZ servers should assume that they can be attacked on any port from any host what so ever. Use the most minimal OS install you can and pick an OS that can be secured and will let you do a minimal install. RedHat has too many features for my taste - you don't want a friendly machine, you want a very unfriendly machine. I would suggest Slackware or Solaris from the general purpose OS pool, or Bastille Linux or OpenBSD from the secured OS pool. Disable or remove inetd completely - it tries to be friendly. Permit no unencrypted traffic. Use tripwire, and be able to reimage the mahines rapidly.
Your inner firewall should be of a different make to the outer one and should assume that all hosts in the DMZ are compromised. Permit only connections from specific hosts on specific ports to specific hosts on specific ports. Anything else should be denied, logged and the warning sirens sounded.
Behind here would be your working net where (relativly) non-secure business functions live. Once again, these hosts should assume the worst and that they have to fend for themselves. Etc. Use your imagination.
One last firewall, preferably a different make again, similar to the last, specific hosts and ports only. You may want to be more cautious about sounding the claxons however, windows likes to chat to things and users occasionally do silly but harmless things - this is not to say drop your guard, just that sleep is sometimes useful.
Next is the secure net. Absolute bare bones here. What this consists of depends on your application, but usually business logic, database and credit card processing live here, each on their own box, set to maximum paranoia security. Log everything, every login, every logout every process run, every request made, when and by whom. You'll need lots of disk space, archive regularly to read-only media, make several copies and store them in multiple secure locations.
IDS - Intrusion Detection Systems. These're useful, use lots - different types, different makes, even write a few of your own.
Incident response. What to do when your firewall is breached. What to do when your web servers are breached. What to do when your working net is breached. What to do when it is an inside job. What to do when your data is stolen. This is where your IDS comes in handy, if your data does walk, you must know where, when, how and who. Access procedures are useful. You will probably never be able to ensure that no one employee can steal your data, but you can ensure that no one employee can steal your data and cover their tracks.
Note that the word "if" was missing from the last paragraph. If lets you cross your fingers and hope it wont happen. Plan for when, not if.
Software. Encryption is good. Make sure and pick the right encryption for the job. Credit card data needs to be decrypted, I would suggest BlowFish, passwords don't - try MD5. Always practice safe key management remember your data is only as safe as your keys. Having said that, if your database encryption is ever tested for real you are this > < far away from a Worst Case Scenario.
Literature. There's lots of literature about, read some of it. Learn to break into computers, try to break into yours. Read some of the OpenBSD stuff, read Bugtraq and the other stuff at SecurityFocus, even if it isn't directly related, the attackers can think laterally, you must too. Try farther afield - failsafe engineering disciplines are a good start (try a google on SAFF for places it really matters.)
On second thought.... (Score:2, Insightful)
I posted a brief overview of a solution using PGP eariler. It was by no means perfect, just intended to point you in the right direction.
Then I began to read what others had posted....
The best advice I can give you is not to trust anything you read here. Some of the solutions suggested are just bad. I am a security professional so I have some experience in this area. As others have said, recognize that you are not equiped to handle this. Find someone who is.
But before you outsource, hire consultants, etc... remember -- technology is only a tool. I've seen technology based solutions that were more vulnerable than the problem.
You have a specific set of risks. Choose a solution that helps to mitigate those risks. Remember to document. Remember people actually have to use the system. Remember a create a well-defined process. Remember to create and enforce policy.
Also, look to the three R's. I could not find a single post that specifically mentioned recognition.
Resistance: how can I protect the integrity and privacy of the card numbers?
Recognition: how do you know if a breech of security has occured?
Recovery: how do we recover from said breech?
I am working on this right now. (Score:2)
Step 1: Lower your expectations. In a perfect world you could do recurring billing, and yet an intruder could not obtain the payment card numbers. In reality, any scheme which allows an automated system to reconstitute the payment card numbers for billing purposes can be used by an intruder (assuming he has root on all your machines) to obtain the list of numbers. Therefore, the realistic goals are:
- Learn a new payment card.
- Charge a payment card.
A webserver cannot request any information about a payment card, including the number. (This necessary for criterion 1).Implementation: When the secure box records a new payment card, it cryptographically splits the card number into two numbers N1 and N2, neither of which yield any information about the card number. (See Applied Cryptography). N1 is returned to the requesting webserver (which sticks N1 into the database as part of the customer record) while N2 is stored in a text file on the secure server, indexed by a sequence number that is also returned to the webserver and stored in the database.
When a webserver wants to charge a card, it provides N1 and the sequence number to the secure box. The secure box internally reconstitutes the card number and charges the card.
Clearly, there are vulnerabilities in this scheme. For example, an attacher could plant a trojan on the webservers which captures the payment card numbers before they are initially sent to the secure box. However we eliminate the ultimate nightmare of having thousands of card numbers copied in one quick attack. Also, of course, anyone who cracks a webserver can throw in bogus charges (accruing to us). This is a nice bit of sabotage, but doesn't make any money for the attacker.
I have heard of more elaborate schemes, but they seem to consist of security through obscurity. You can make the reconstruction of the card number "complicated", but ultimately all the elements must be available to the automatic billing process. And if the box is cracked, you can assume that all the elements stored on that box have been copied.
Therefore I think this scheme is about as secure as one can realistically get.
Not a job for amateurs (Score:2)
That said, I must also point something out from the customer's standpoint. There is no possible way that I, the consumer, will accept any term of purchase of any product, that involves the vendor making a monthly charge on my credit card, writing a monthly check on my behalf, or "automatically" withdrawing money from my bank account.
If a merchant is not capable of sending me a bill each month, the customary method of soliciting payment, he is not worthy of my business. Furthermore, if he demands such an arrangement as a means of automatically making my bill payment on my behalf, he has already made a serious social blunder that cost my business from the first word: it is tantamount to accusing me of being a thief, and at the very least has indicated to me that the merchant already considers me irresponsible before our relationship has even been established.
I will do no business with such a cretin. End of story.
There is a solution... (Score:2, Interesting)
While I can't be specific, I have had the fortune (or misfortune) of working with an e-commerce company. We had a golden rule w/ respect to storing credit card numbers. If you have a system to store credit card numbers in order to be able to reproduce them at a later date which uses a public info system (such as a website, etc.) the credit card numbers are vulnerable to someone stealing them.
Trust me. You'll never find a sure way of keeping that credit card number secure. You can say "I'll use encryption, store them (credit card numbers) on a secure server, blah blah blah". They won't be.
And I probably would trust a full end to end solution either. I just wish I can see the look on the face of a salesman who tries pitching his secure product when it's credit card numbers end up showing up in a Google search results page...
convenience vs. risk (Score:2, Interesting)
learn from Visa best practices (Score:2, Informative)
Internet [firewall] web server [firewall] app server [firewall] database server
...and the database must be encrypted.
Check out a company called Protegrity; they offer drop-in encryption for many vendor's databases.
The experience is the hard part? (Score:2, Informative)
The hard part, the meat of the problem, is securing the data. And it's a problem who's difficult is often underestimated.
I'm assuming that all data is submitted ONLY via 'POST' (i.e. not 'GET'), and via SSL. If this is not the case, see the above comment on working e-commerce.
I had to design a system like this for the e-commerce company I used to work for. Assuming we where hacked and how, the goal was to minimize the impact it would have. E.g. if the hacker got access to our entire source tree, our database, had a network sniffer, etc. how would we stand under various scenarios. Additionally, we made as few assumptions as possible (e.g. the hacker could have access to our source code, the public key, our db, network sniffing, but did not have access to private the key).
If you're past that, some advice:
1) Place all your secure data on a separate server. Minimize the data present on that machine. This will decrease the likelihood of someone needing or asking to get access to data that will additionally expose the secure data. Additionally the server should be as stripped down as possible, as any secure server should be.
2) Setup your network with an additional zone. The server mentioned above should go in this zone. The new zone will be strictly controlled and only used for holding the server upon which the secure data will reside. This zone should be strictly controlled with it's own router. Everything disallowed and only one or two things (ssh and https) should be opened. Ideally, if your main webserver (probably the most likely spot for a penetration) you'll want to know if this part of the network has been breached as well.
3) Do not write the secure data to disk (e.g. in log files or in debugging information dump files). Do not pass the data over the network in any insecure manner. This seems obvious, but a lot of people fail to understand the entire environment, and can inadvertently weak their system's security due to this. For example, many people using a servlet container like Resin configure the session data to replicate to another server. While this is a great thing, and reduces the problems of losing any single server, the secure data can be transmitted across the local network in clear text while being replicated. Not good.
4) The web servers will most likely need to make a secure connection to secure box. This sounds bad at first, but there isn't a better away around it. Ultimately the data has to get from point A to point B. Writing it to disk for batch accumulation is not good (as stated above). Building up a queue and batch submitting jobs to the server doesn't really offer anything over individual submissions. Additionally it increases the detriment of a server crashing before the batch job has been submitted. In some cases this might also be less ideal as the business needs may call for pre-auths to take place as soon as possible, or otherwise sending the order to a distribution center as quickly as possible.
5) It's obvious to state you should encrypt the data before writing to the database. The part most people miss is HOW to encrypt. Just using a public/private key isn?t enough. Even worse, most folks will miss judge the strength of their system by gauging how long it would take to crack the key being used. While cracking the key is most likely what you would want to do to read the secret message from Alice to Bob, it?s not what someone is going to do to get your credit card numbers.
If someone wants to get your list of credit cards, it's easier to brute force the number. The average non-amex card is 16 digits. Assume you've gotten the entire database; you'll have a few hundred thousand numbers easy. Assume you're not a greedy hacker and would be happy with say only a hundred thousand numbers. Then the first four digits really aren't random as they often represent the network and bank. (Ever notice that your buddy?s Visa card also begins with a 4? Or that everyone?s Discover card is 6011?) That reduces the complexity by four orders of magnitude. Often the last four digits are show plain text to the customer. That leaves only 10^8 combinations to try. Additionally a clever hacker would do a quick mod-10 check before a more expensive encrypt-and-check call, so that's really not that long.
So what to do?
Using a one-way method isn't an option. We need to be able to get the original credit card number back. Not just because of the case cited above, but that's just a real-world need. You cannot legally charge the customer until an item has shipped. If you can't ship right away (i.e. Backorders), you're going to have to hang on to that number and use it to charge the card latter. If you have to break the order into multiple shipments, same thing.
What we is an asymmetric encryption algorithm. One that will generate a different ciphertext each time the cleartext in encrypted. There are a lot of ways to do this, some encryption even provide for it. If not, simply append a delimiter and a random number to the cleartext and encrypt it. (E.g. instead of encrypting '4111-1111-1111-1111' encrypt '4111-1111-1111-1111*4873924839432432432'.) If you have the private key, it is easy to discard the random text. If you do not have the private key, this makes it difficult to brute force the number.
6) Backup should be done separately, to separate tapes, on a separate drive connected directly to the machine. The tapes should be treated as access to the machine would be.
7) Tripwire the private key. In case of a breach, you'll need to know if this file has been accessed.
8) Use stored procedures to restrict access to the secure data. I love m(y)?sql, but this where Oracle and SQL Server's stored procedures are really nice. Basically the account through which data is being accessed by the applications should not be able to select, update, delete, or insert. Instead offer a stored procedure API to do what is MINIMALLY needed. Generally it's best to offer a minimal, but complete API. That's not the case here. Offer only what's need (e.g. do not provide an interface for updating a card number if that?s not needed, etc.)
9) Chargebacks and coupon abuse are going to be a pain in the ass. The draw back of the above method is that you cannot easily find an account by credit card number. And, in the real world, sometimes you do have to do it. Often credit card numbers are used to enforce one-per-customer offers. And for good reason -- it's probably the most effective way to do it. However, the cost (insecure data) is too high for the overall business. Slashdot bashing of Marketing be what it may, but if you can explain this to one of the higher ups in the group in an understandable way, as well as work with them to come together with a different solution, they will usually be open to it. Nobody, especially in Marketing, wants to come in one morning, and read on my.yahoo.com that their company?s credit card numbers have been stolen.
Chargebacks have one advantage over credit card abuse: they are not done one the customer?s dime (i.e. nobody is sitting there waiting for a page to load). Most likely it will be possible to queue them together, and use the first and last four digits to limit the sets of rows to be examined, and then simply start decrypting and comparing. None of the intermediate results, obviously, should be shown. This should ONLY allow to get the customer name, etc. from a valid credit card number. That normal caveats of web development apply here as well, despite it being an internal application.
10) Work with your Operations team to test the system. If you breach the zone, are there traces? If you scp off the private key, was that correctly detected as well. Remember the old scare stories of people who never tested their backup system until they needed them, only to find out they didn?t work. Make sure everything here is working as expected.
Anyway, that's all about I can bear to write for now. Hope that helps someone.
-Bill
Here's how I do it. (Score:2)
Then I store the private information in a text file that is linked from the front page of my website. I publish personal information under the GPL so that nobody can modify it.
Information wants to be free. There is no reason to hide information!
Re:Hashing (Score:2)
Re:Hashing - Seperate Retrieval Agent (Score:2, Interesting)
Generate a Public/Private Key Pair on an isolated high-security box. Copy the Public Key to the Web Server where all the data is being received from. Use that key to encrypt the data and store it in a DB (preferrably on a box seperate from the Web Server.)
Once a month, the high security box will connect to the DB and use the Private Key to decrypt the information and transfer it to the pay agent. Configure this box very carefully and only allow it to talk to the DB box and the Pay Agent's server. Also, if you want to be extra careful keep the private key in a smart card and lock that up in a safe during the rest of the month.
Using public key... (Score:2)
The way the good payment gateways work is they give the merchant a client that encrypts the CC# under their public key at the merchant server so only they can decrypt it on the other end. Decryption is done in a specially partitioned area, usually with substantial physical security etc.
The reason you are using a payment gateway is (in part) because they provide that physical security for you so you want to avoid anything that requires you to effectively set up a secure area yourself. Simple though this may seem to the average slashdotter it is quite hard if you are using a co-location center. And no a firewall is not sufficient.
What you need to do is to see if your merchant gateway provides an API to the payment module. I beleive that surepay is moving over to use the VeriSign payment system. If so the module that encrypts the CC# in the payload did at one stage allow for offline preparation similar to that you suggest. Whether that is currently supported is another matter that would require a little reasearch.
Re:Using public key... (Score:2)
The second, more general point, is that an e-commerce company must have the fleixibility to change clearing back-ends without impacting the customer. Using the gateway/bank's public key to encrypt card numbers prior to storage would lock us in to this one provider. That would be harmful to my company's interests in the long term. I cannot use any special features of the current clearing provider (which happens to be a bank) because my company needs to be able to switch to whichever provider is most advantageous.
Re:Using public key... (Score:2)
Who said anything about choosing the bank? The whole point of the Signio Payflow scheme (now VeriSign payment gateway) is you can connect up to any acquirer bank in north america. Most customers then use the fact to negotiate lower rates because lowering the switching costs to close to zero means that they now have pricing power.
Under the old frame relay schemes you soon became captive to a particular bank or acquirer because none of them used the same implementation of the alleged standard.
If you can't choose your gateway you should perhaps tell your management that you don't have the necessary control to fulfill your job. We are talking about the region of $400/yr flat fee here for the basic connect.
The situation you describe suggests that you are already largely locked in to a particular back end.
Re:Using public key... (Score:2)
Thanks. I didn't know that. I can see how this could help get a better rate. However, it still seems to leave the e-commerce business vulnerable to an outside party unless they internally abstract the interface (which I do).
I haven't worked on one of those, but I have implemented a few interfaces to clearing providers over the internet. In each case, I abstract the back end so that none of the terminology and field names of the particular provider leak into our systems, and so there is a clean and minimal interface to hook up a second provider. I've never actually had to hook up the second provider within a given framework, but it should be easy. So if you're using the internet for transit and properly abstracting the interface, there shouldn't be much feeling of lockin. Of course I take your point that Payflow communicates the customer's freedom of choice more effectively.
Only in the sense that the relevant decision-makers have so decided. If they decide differently in the future, I will not have much difficulty switching back ends.
Re:Yes! (Score:2)
In my years as a system admin, I've seen some of the most backwards, stupid, and insane bullshit on the planet. This includes the bounced postmaster email containing several hundred (possibly thousands) of CC numbers from a "secure web site"; that "https" form to which the user's input was sent put all the information -- plain english, ASCII -- in a file and then e-mailed it to someone at the end of the day. (I bet I have a backup tape with hundreds of decade old CC numbers.)
Re:Hashing (Score:5, Informative)
Re:Hashing (Score:2, Insightful)
First define your goals from the customer side. Do you want to allow your customers to decide what day of the month their CC will be billed? Do you want the customer to be able to change their CC#? Do you want the customer to be able to pay for 2/3/6/9/12 months in advance? Do you want to allow you customer to select an option to only 'bill once'? The goal of your application will determine how you store you sensitive data. Someone who wants a 12-month subscription and would like to use the 'bill once' option tends to be okay with updating his/her records every billing cycle. While the month to month guy doesn't want tge hassle from a reputable company.
Also consider (in the case of removable media) that if a customer wants to cancel their account, you as a company want to get rid of their data like a hot potato. If you have to wait for the next tape to be inserted to remove that account, you are still liable for their data. And that is an expense that no company wants or needs. Client request queue's are cumbersome to manage, usually rely on unstable environments, and are certainly not ideal for security. If you had to wait on a tape to mount to add a new account, where are you going to store that account's information until the tape gets inserted? I would think that in any case no matter what the requirements are, a removable media solution is out of the question.
While I'm on the subject, let me point out that nobody is going to do this for you out of the box. The commercial says that 95% of top 60 E-businesses run Oracle, and yet every regular
"We haven't been attacked, so we probably never will be.", "they don't know we are here.", and "My machine isn't really connected to the internet." may be statements that is true enough, but that doeesn't allow you to rest on your laurels. Security though Obscurity doesn't work. Trust me, if they want to, they can come though your firewall (usually a Trojan), around/into your NAT tables, and into that box that isn't really on the internet. I don't know of a security tool that can't be fooled (except a person that can make on the fly decisions).
So we come back to 'out of the box security tools'. The correct way to modify them is with education about them. The more you get to know about your firewall(s), and your router(s), or your web server(s), and your [insert long list of hardware/software widgets here], the easier it will be to understand how to protect yourself. It wouldn't hurt to pay for a class on how to make modifications, as this would give you the voice of someone with a broad experience in dealing with your tools.
So, My answer to your question, as long and rambling as it may be, is pretty simple. Stay away from Microsoft OS's as their security holes are much more publicized to the general public than that of the UNIX/Linux world. Use a peer system with ALLOW/DENY rules setup in your boxes. Have your content server(s) connected to a broker server that can then connect to your database. Never access your data on the database from any other machine (no remote ODBC, TNS, etc...). Have the database do it's own lookups and queries. Then use some form of encrypted communications to relay information from the database to the broker. The broker should make an intelligent decision as how and where that data gets sent. If you connect to the clearinghouse via TCP/IP, then have the Broker hand off the data, and not the content server. As far as a customer is concerned all of this is transparent. To the cracker there are layers of walls to break in order to get to the data.
I would love to promote the software that you should run on the Broker machine, but contractually I cannot. Remember as you look for, or develop your broker machine that THAT machine is your security backbone, and should be treated if it was your daughter. I hope this helps, and I wish you the best of luck with your endeavor
Re:Nothing is 100% secure (Score:2)
But the better solution is to get together with your bank (you are a normal business wuth a commerical account, of course) and get their solution on board.
Re:Questing about hashing (Score:2)
Hashing it is pointless; you NEED to be able to decrypt it.. otherwise you can't process further credit card transactions...
Re:database security (Score:2)