Slashdot Mirror
Responsible Handling of Billing Information?
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?
want to hire me ? ;-)
As long as you send all your customer data to one way crypto heaven (MD5, SHA1), whats the big deal? If attackers easily snark in through the latest IIS sploit, and on into your SQL Server, your data is protected.
Strong encryption and only connect the machine to any network (internal and external) when the bills have to go out. Filter all replies that don't come from the credit card responder.
Why not use a billing service that supports the subscription model you want, rather than trying to find some minefield-laden path toward storing credit card info?
When I was a kid, we only had one Darth.
Just fork over money to Microsoft, and they will provide you will access to an ultra-secure passport server, so your clients will have nothing to fear.
I remember hearing that Amazon.com originally used a Slackware box with extremely limited connectivity as a 'store' for the credit card info. Set it up with extremely limited connectivity, i.e. on a subnet unreachable by the world. Put only extremely limited services on it, i.e. set it up so there's a pipe for credit card info to get onto the box but nothing on the box is shared out and there's just one data path out from the box that sends an 'okay' signal that info verifies correctly. The machine should be set up so a zip drive is the only way to get info off of it, and you have to sit at the keyboard to do so.
Just one question: how on earth did you get hired without a clue what to do? What you ask i a standard Q, you ought to know it without us..
All sort of dummies got jobs in the recent years... ;(
<^>_<(ô ô)>_<^>
I always thought that this article described a way thats pretty simple, and easy to use / develop.
Cheers.
Store half the credit card number and half the expiration date in a cookie on the user's computer. Store the other half in the database, encrypted.
Even if someone cracks the server, the database itself will not yield valid CC's.
So what do they do now? Why did they cease using the security through lack of functionality?
If the question is how to store data in a responsible way, why not ask Surepay, who you are sharing the sensitive data with? Surely they will have some insight into this, and because you are a client, may be more apt to share it.
Maybe your question could be asked how to safely transfer it?
-- Dan
Okey, this is redundant, but you have to draw a line somewhere.
One thing I would suggests (and you won't like) it that you keep all CC data on a removible media, that only gets inserted (manualy or otherwise) when you have to send it to the billing company. I suggest that you make this process manual, so you can keep an eye on things why doing the delivery.
Okey, this is arcaic, but it's a good security measure. Just be sure all data goes encrypted, and that the media where you stored it is well protected.
morcego
I was thinking about this the other day (since we're trying to do the same thing on our site) and I think it would take some sort of a special arrangement or a special package (if they didn't offer it before).
The details are something like this:
set up a database on your site to hold this type of information:
cc_hash,
payment_expiry,
userid,
etc.
Then, when the user vists your store (unless you are paying for the SSL license chances are you're redirecting to surepay, correct?) have it embed a userid (or whever you keep track of on your end) form field. After the user pays, have the surepay place either post a SSL form, send you an encrypted e-mail, etc. with the CC number (or some other form of identification) MD5'ed back to you. You can store that hash (hashed with maybe a secret 'salt' that only you and sureplay know) along with the userid in some table. Then, when the payment_expiry date rolls around, you can poke surepay with the userid and cc_hash so they know you still have their CC number (surepay would keep the unencrypted version and could generate your MD5 hash). Obviously if someone was evil they could break in and 'steal' your table but all that allows them to do is re-signup your current members (and that wouldn't be too difficult to un-do either).
Thanks,
--
Matt
Perhaps it's not possible, but it seems to me both your and your customer's lives would be made a lot easier if you'd go with a credit card processor who does support recurring billing.
It hurts when I pee.
Just don't. Credit card databases are too tempting a target for crackers. I've seen an ISPs card database hacked when they thought it was safe. It was a Netware server connected to the network, but with no direct internet connectivity. The cracker rooted the linux servers, then built the loadable IPX and netware kernel modules, mounted the netware server from the linux box (which the ISP people didnt realise was possible), and got full details of over 7000 user accounts. btw, in my experience ISPs *never* reveal stuff like this to their customers.
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.
hmm, getting a credit card billed monthly sure sounds like most porn sites I've been a member at, err, it sounds like most porn sites I've read about on /.
Just use a flat file plain text database on your webserver. Then your billing application can easily read and supply the necessary information to surepay. A simple robots.txt file will prevent it from being indexed and it will be 100% secure because it will be hidden!!! Simple, elegant, and secure!
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.
Every article roasted the company over that specific problem the most. I think the reason why is its more excusable to to have a whole somewhere in your network, but there is just no excuse for not encrypting the files.
This is just an idea, so shoot it down if you like.
Why not just have Surepay provide a really high bit crytpo key? Then you can encrypt the data once using this key, send it to them encrypted, and they can decrypt it. Since the data would be stored in an encrypted state, and THEY supplied the key, what would be the problem?
-- Dan
Why not copy the data to floppy, lock it up and when the time comes mail it to your vendor?
Hire people to do it all manually. May be more expensive, but paper in a locked filing cabinet can't be hacked. Automation is not always the answer.
yes it is possible that slashdot is stupid. In fact, it's guaranteed.
The goal, then, becomes motivating your colleagues and/or marketing-and-management-types to use this data responsibly. My suggestion would be to insist that the customer be given unconditional recourse in the event their data is mishandled as a term of the (recurring) sale. I can't say I know of any company that actually does this, though. The ubiquitous "terms of service" and/or "privacy policy" often give a company wide latitude with your data.
You could compare this problem to convincing the management that spamming is a Bad Idea; often they just Don't Get It.
--
There is no hatred more pure and true than that expressed by children.
PayPal also is a fee based subscription service... i'm not too familiar with Surepay... but PayPal is one of the most reliable billing vendors out there
"The ones who dont do anything are always the ones who try to pull you down" -- Henry Rollins
Boy, this advise is simple, cuts down to the bone and unfortunately wont solve his problem.
Why the fuck specify companies requirements, which are not directly relevant for the business, but make life a helluva lot harder?
sigh...
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
I've thought about this problem a bit, but never really had to implement anything, so anything I am about to say, should perhaps be taken with a grain of salt.
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.
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.
The ol' Public Key Private Key encryption is the answer.
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.
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
Absolutely key to securing financial data (or really any data) is the use of good internal controls.
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.
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.
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
---"What did I say that sounded like 'Tell me about your day?'"---
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--
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)
As you consider ways in which to provide safe escrow for the customer's personal information, you might consider consulting your corporate attorney to get an appropriate waiver of liability in place. By storing the credit information beyond the life of the immediate transaction with your payment service, you're opening yourself up to additional exposure to yourself that I'd imagine isn't covered by the contract with the credit card processor. It looks like you're stuck in the realm of symmetric encryption techniques for the information, and there are steps you can take to protect your encryption keys. But even with good physical and software security (hardcopy keys in bank vaults, regular key rotation) it would be prudent to limit your liability. Something else to to check into is any additional privacy regulations that may apply if you end up being a financial "intermediary". One of particular note is Graham-Leach-Bliley which requires certain disclosures when you have certain roles in financial transactions. Again, a real legal opinion is probably your best bet here.
Why encrypt it? Kinda parasitic to keep information from people, isn't it? And they're not thiefs. They're information liberators.
Je ne parle pas francais.
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):
Zodiac Survey
Visa has some pretty clear rules about what online sites should, and shouldn't do, with credit card data.
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).
You need to make a write-only link from the site to a machine that is only connected to the net when needed (during processing). Write the CC info over this link as it comes in. To be really secure, then move this info off the machine to a machine that is not connected to the internet at all (via sneakernet). In any event, that is _all_ this machine will do is process the monthly cc charges.
Then, you can process the cc transactions in bulk as needed. Since the only time the machine is connected to the internet is when it's processing, it's fairly secure. Still, take all the standard precautions (firewall, etc). Since you can block all incoming ports and only open a few outgoing ports and no servers will be running on the box, it will be secure (esp if you use something like OpenBSD).
If you want to be really paranoid, you can do some data rate checking on your internet interface (eth0, dialup, whatever). You know all the data that you will write out and can make a good guess how much data will come back. If this changes by too wide a margin, something is wrong and you should take a look. If you do that, the box will be unhackable remotely (at least all attempts will be detected, and stopped before data is snagged). Someone would have to break in and know to disabled the byte counter before the alarm goes and the connection is dropped, and it's doubtfull they could do so w/o tripping the meter in the first place.
If you can't have a write-only link to a machine you have access to, you'll have to encrypt the cc info as it comes in (make sure it never hits disk unencrypted). Do not store the decryption key anywhere on the server! Then move this file offline to your cc transaction machine.
Having credit card data available on your system is a huge potential problem; any security hole might be exploited, and even if none of the card #s are misused, it would make your customers very unhappy.
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.
I pretty sure there are Visa and MasterCard rules that say you are not to store customer credit card numbers in any kind of database. Yes I know everyone does it.
My idea is to have the box that does the monthly processing that has an interface that lets card numbers in but not out. And beyond that no other connetions.
There's lots of issues with storing credit cards, not the least is showing that individuals working for you can't misuse the data and would have difficulty even colluding to misuse the data. I know, I was a IT director in the pre-dotcom days when people took these issues seriously.
/., but I think there are some other parties you may wish to ask. If you have a good CPA, they will know how this issue is handled in related businesses. Also, don't forget the credit card companies themselves, who should be willing to share their ideas for "best practices" when using their products. Remember, they have a vested interest in making their products convenient and safe for vendors to use.
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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.
No, Thursday's out. How about never - is never good for you?
and steal the new card entries.
What does it matter if you lose 1 credit card to a hacker or all of them, you're website's credibility is completely devastated either way..
I said it before, I'll say it again... hire Al Gore to protect the data, he will put it a real lockbox where no one can touch it!
In case of fire, do not use elevator. Use water!
I would setup a single sytem without any open ports whatsoever. I would then use something like gpg to store encrypted data submited by the user of the website in a predefined dir on the server in question. So you get the cc info and imidiatly put it in a gpg file where only the server has the key. Then run an hourly job to grab files from the webserver via sftp. And decrypt them and store them to a data base on your server. This would be simple enough to setup and impossible to do anything except grab cc numbers from the webserver.
Be careful. I read the surepay site and couldn't find the specific terms of service (TOS), but based on experience with other sites (paypal, propay, instabill, etc), your plan may be illegal.
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.
I'm sure others here will offer concrete advice on setting such a system
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
If someone cracks the web server, then they also have access to the web server code which decrypts the database info.
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.
Infuriate left and right
But what happens if a fire torches your filing cabinet? Would you have backups of the data (presumably Xerox copies)? And if so, where would they be stored? Also, what happens if someone were to break into the premesis (probably a disgruntled employee)?
Sounds silly, but all this can and does happen! In this case, the other posters have it right, hire the experts, but more importantly, *LISTEN* to them as well.
In case of fire, do not use elevator. Use water!
It is possible to do this with reasonable security, but it requires continual effort and more detail that one will get off /.
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).
LedgerSMB: Open source Accounting/ERP
The very way this question is worded indicates the person asking it is thinking the wrong way. The billing system has NOTHING to do with the web site, they should be seperate, if the CC information is not held on the web site then no haxor no matter how good he is can steal it from the website.
Website should be for providing info, billing systems should be for billing people. The website should be able to send info to the billing system but not vice versa. There is no need for a billing system to face externally. Just remeber not to store web transaction logs on your website in plain view and you have the problem sorted.
Here's an idea.
Put the subscription information on a removable hard drive...
Upadate it daily, and pull it out daily. Wipe out new information on web. Lock up drive. Back it up. Client communications about their account should occur over telephone. And be altered in the closed system.
Also, a good security system if the client wants to see account information is to use what my bank does... give them a new account identity number(with letters too) that has nothing to do with the credit numbers. So when the thieves steal the information, it is only useful to your company and not the rest of the world.
After that point, they would have to physically get into your company and system to pull off any information.
Obviously, you'll need to store the actual billing information in a database, in cleartext
Uhhh, Why?
I've had enough abrasive sigs. Kittens are cute and fuzzy.
I do routinely transfer all of my funds to my bank account because of some of the complaints I've read.
Why aren't we told when editors moderate our posts?
One would assume that you don't allow all sorts of evil things past your firewall. Lets expand on the intent of what you are trying to do and also assume that there needs to be internal access to the data as well--customer support, phone registration, etc. What would you do in that case?
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
There is a documented approach to storing of sensitive customer information that I think makes a lot of sense. It is brought to you by Cybersource and the SIIA and is available here
In Soviet Russia you dant have to put up with these crappy jokes
I'd just slap the CC information on a box that's not accessible to the outside world. Turn off everything you can on it, etc.
SurePay is on the way out. They've made a deal with Verisign to migrate users to the Verisign Managed Payment Gateway. The SurePay gateway is only being maintained for existing customers. It should not be used for new development.
Is this for a Porn site?
Hehe
Sure it's possible, but why should I tell you.
Man, I wish I could get a job like you. If I don't know how to do my job, I'll just ask on slashdot. After all, that's what open source is all about, right? Using other people's donated knowledge to make yourself look smart for the boss, while at the same time earning loads of $$$ for your company and their clients.
Get a life, and an education.
"A terrorist is someone who has a bomb but doesn't have an air force." -William Blum
Store all this sensitive data on a zip or jazz disk. Something removable and recordable. Put the disk in a computer once a month for billing. Other non-sensitive info can remain on your machines.
No hacker in the world can get to a disk that's not present.
I would consider placing the data on an isolated machine encrypted via a 2 way algorithm (AES, DES, etc). All access to/from this machine would be via an intermediary machine which only is allowed to do the following:
,etc)
* submit a cc to the holding server, along with some identifying information (e.g. account#
* ask if a cc # is valid
* submit a request for a cc transaction
* retrieve a _portion_ of the CC number(s) associated with an account(look at most popular sites that reveal cc info, you'll note that they x out all but a teensy bit)
I would recommend that the connection between the machine holding the full cc info and the machine running the intermediary app be either serial, or an ethernet cross cable. this will prevent the data from inadvertantly being placed on a network. There shouldn't be _any_ other connection, save the console, to the machine containing the full CC information.
Some CC do not want you storing their #'s on your servers either. You should also talk to your bank, as they may object on grounds of increased financial risk (of fraudulant activity).
There are already too many Pr0n sites. Why do you need to set up another?
... you have a front box connected somehow to the internet where your client interactions take place. The data is stored in a database (or whatever) on a second box. This second box is directly connected to the first box via a cable so it has no other network connection. Encrypt the CC data at every step (incoming, between the boxes, in the database, transmission to the paymeny processor, etc.). Harden box boxes as much as possible (maybe use OpenBSD for the OS). Don't store the encryption keys on the systems. Change them regularly. Use SecurID or something validate logging into into the servers. Basically assume that the hacker can get on your network and on your boxes as root. Using this model it is very difficult to get a CC number, even if you are root. One would have to start sifting through the kernel and other icky things.
If you want to store the info on your own servers the best solution for you would probably be ModernBill. 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.
If you want to keep your customer info offsite you can check out Ubersmith, which is provided by 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. ;)
[Got Hosting?]
Convert the credit card numbers into a series of letters. 0=A, 1=B, 2=C, etc. Then if someone breaks into your Microsoft SQL Server, all they'll get is a random string of letters, not your customers' credit card information.
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
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".
Limit the access that the web server has to you database, and then use views/encryption to hide/protect your data from the web servers prospective.
If your using a good database you should be able to configure it based on ip's or mac addresses for specific accounts. So setup your super user accounts with tight IP restriction. Then setup an account for the web server and restrict it to only the web server. That way if someone takes over your web server they will not be able to authenicate to the database using the super user account. Providing that the database does not have any security flaws.
At this point restrict select access to the CC table to only the super user account. Then create a view that returns the last four digits of the credit card number, the rest *'s. Something like ************8721. When someone issues a select statement on the CC table this is the only info they will be able to get back. If you name the main CC table something weird, the view something simple like Credit_cards, and then restrict your system tables the hacker may get fooled. Of course they would have not know anything about db's to figure out it was a view.
There may be cases when your admins or certain users need to access the full number to verify it or for other reasons. Since they will probably be using the web server to do this you can create a stored proc that has access to the info, but will only return one number at a time. Of course you will need to implement the stored proc in such as way that some security token needs to be passed to get the info. If the proc fails track it.
Another approach might be to link your two database servers together in some manner and store your CC in another database. Only store the last 4 digits and a pointer ( foriegn key ) to the other db record in your local database. Of course a hacker could leap frog onto that database, but if you do a good job of hiding it's existance it could be a road block if the hacker does not have inside information. If you log communication between the two servers, and setup some type of application level authenication between the two you might be able to catch the hacker trying to figure it out.
Bottom line is if someone takes over your web server, and it has access to the CC's in anyway your never going to be totally safe. Ask yourself if you could get in with all the knowledge of the system you have.
And also, don't be to proud to ask for help. Get a security consultant and have them try and hack in before you go live. In fact get several companies to try, it might cost a pretty penny, but you can put it in your privacy statement to your customers.
zzzzzzzzzzzzz.................. uh... huh?
*shrug*
AY-YI-YI-YI-YI-YI-YI
I just had a thought. I know that with Cybercash at least, they store the CC numbers on THEIR servers once you have done a transaction. You can query their database (using the original order number) and get the credit card numbers, manually enter a PO and charge the credit card. I also know that you can script all this so it you can automate it.
This is all done through SSL, and you never have the CC numbers on your system. The responsability is out of your hands.
If you have to ask this question on Slashdot, then you shouldn't be doing it. Read "Secrets and Lies," and then think about the question some more.
Like most security question, ultimatly this boils down to Security vs. Convience.
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.
The Kruger Dunning explains most post on
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.
This is necessary...life, feeds on life...
Howdy,
:)
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
I've build similar systems in the past. It's not a simple problem. In addition to a very robust and well thought network architecture and a very robust encryption architecture for the Credit Cards as mentionned in the previous posts you have to deal with:
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.
I really hope the author of the original question read that post.
...and everyone who suggested "Trust the billing service" or "Use a firewall" - please tell me where you work so I'll know not to buy anything from them.
Security through obscurity doesn't work. Use the right tools.
I have used IBill for two years for recurrent monthly billing, and I am delighted with the service. They have great customer service. http://www.ibill.com
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.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Why not have the billing services provide their public key on their own web site. Then you can just encrypt the users billing info using the billers public key.
The biggest problem is that if you change billers then you won't be able to access your customers billling data.
The solution to that is to encrypt the data with _your_ public key as well, and have your private key on a unix box that runs no services and only allows access from the console. And you will need a password to access the public key.
Then if you change billers you can pull the records out one at a time to the secure box, decrypt them, then reencrypt them with the new billers public key.
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.While everyone is posting about how to make a super-secure infrastructure, I'm reminded of an old story:
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...
The Daily Build
We store the credit card information in MySQL encrypted using the PHP OpenSSL routines. Only the public key is stored on the server, the private key is offsite and can be pasted into a form when you need to retrieve the information and have the PHP script decrypt it for display purposes only (all over HTTPS ofcourse).
Here's how:
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.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
1200 baud? Me thinks my Apple //e had a faster modem! Maybe there is a better solution... first go to the users house, get the credit card, charge it with a portable credit card swiper (the 1970's version) and then bill from the carbon copies. It would be at least 2400 baud.
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
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
I run an online store that has credit card processing via Cardservice with Linkpoint. I'm currently rewriting the real time authorization software for it because the system they use writes all the info to a plain text file, and shells out from within PHP to execute a binary which reads the temp file with the CC info. (FYI: I was thinking of doing an SSL PHP module hack)
I think a more important question is "Does the credit card processor have enough security?" Here is the reply from Linkpoint's coding team when I said that writing plain text to a temp file is unacceptable for me and my customers:
"Writing to a temp file is how the PHP wrapper works. It is only insecure if your server is an environment where a hacker can get in and grab that temp file. Don't you have a firewall up?? If you are running a secure server then writing the info to a temp file to pass to the LBIN object should not be a problem. We have thousands of people using this product currently. This is not a security risk."
The suggestions about using public/private key encryption is excellent...it's the system I use. But how is Surepay handling the cards? Are the other major gateways giving their clients the same kind of software? Do processors such as Paypal, Surepay, et al use this kind of software? All the security of your CC database won't mean a thing if that's not the method a cracker uses to grab the info...
Should send them a link to this Ask Slashdot...
Pull a Kobyashi Maru, and change the parameters. Don't charge monthly, charge yearly. Store the date of subscription, and send an email out, once a week, starting two months before a subscription will expire, telling the user to come re-subscribe. That removes the entire requirement to store things.
Vintage computer games and RPG books available. Email me if you're interested.
OK. How do you charge the credit card, in this case? Certainly not in real-time.
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.
LedgerSMB: Open source Accounting/ERP
It looks like SurePay is just verisign's stuff with a different name. I've been using ibill.com for some time now with no major problems. They do recurring billing, and offer a rev share program (they will do all the paperwork). They are kinda expensive though, 10-15% of sales. There is also ccbill.com which is the same as ibill but they offer a revshare and CPC program.
If he's stuck with SurePay then he may be stuck with just one box or God forbid virtual hosting. Which means forget storing CC's and forget adding a secure box.
Here is a solution using PGP:
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 billing information security involves two steps: first, the ordinary system security that we all know about - protecting your system from breakins, physical security of the machines, etc. This is a big job in and of itself. On top of that, you then need to worry about encryption of the account information, so that if there is a break-in (either virtual or physical), you are not in a position to be blackmailed by the crackers.
More details can be found on my company's page about security, here. 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 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.
I think what you are looking for is a payment processor which supports recurring billing as well as open source client APIs?
</plug>
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.)
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?
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.
It would be a good idea to build a few identical machines to act as honeypots. The nice thing about a honeypot (if they machines are identical (same case, drives, etc.)) is that it can deter both physical and net attacks.
Everytime you look at porn a devil gets their horns.
The credit card paradigm is whats causing the problem, not securing the cc numbers!
... suggest it!!!
No matter what you do, or how you do it, there is always the potential for loosing the information...either by theft, fire, fraud, etc.
The only sensible way to "charge" things are, IMHO, by changing the way credit cards work.
Before anyone mods this as off topic, consider aquiring the ability to accept a credit card that does one time transaction numbers and when you enter into a selling relationship with a customer who does not utilize this kind of credit card
This not only ensures your customer that you care about the security of thier transactions it also serves as an opporitunity to explain that there is always a chance, even if it's a remote one, that thier current credit card numbers can be comprimised.
I do not know the answer to your original question. I personally think using the above suggestions with the system you currently are working to secure would be an option to consider.
Even if the customer does not want, or can not get a credit card that utilizes "one time transaction numbers" the fact you take the time to explain it to them should be a little reassuring to them..I know it would for me!
Here are a few more links to info on one time cc numbers:
American Express offers disposable credit card numbers for online shopping
Frequently asked questions about American Express Private Payments System
The O-Card
Integrity is what you are when nobody is looking.
to do this then you're not qualified for the job. Sorry, but that's the truth.
I recommend hawk-i (www.hawk-i.com) for this sort of project. It is internet billing software for small to mid-sized Internet service providers. It has a great web admin service and customers can view account history, pay bills, and manage their accounts via the web interface...
I am sure that you are looking for something similar to this product...
We have been using it almost 4 years now and we couldn't ask for better support and service...
Just my opinion though.
... is to steal as many CC #'s as possible, advance all the cash you can, and make a run for the happiest place on earth ...
TIJUANA!!!!!!!
That goes for your boss as well, and anyone else up the corporate chain who has allowed this situation to develop. Amateurs, however well-intentioned, should not be given the responsibility of developing financial and accounting systems or policies.
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.
-fb Everything not expressly forbidden is now mandatory.
Use something else than Surepay. If it can't do what you need it to do, don't think you can easily throw a band-aid on to fix the whole thing.
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...
Buy.com, Ebay and (I think) Amazon let you recall card numbers you used before and use them on new orders. So they keep your old card around. I suggest heavy 2-way encryption with the key very well protected. The question is whether the card numbers are exposed, that is, if one of their employees or business partners can get to the data, is it readable or easily decryptable. If not, I say, you've done your job. I used to like knowing that companies that collect my credit card for payment don't keep it around. So the inconvenience of having to enter it again was OK given the security of their back end. However, having designed e-commerce systems myself, I realized that the lack of the recall feature has absolutely no bearing on the security of my credit card info. So I decided, screw it. Once you've used your card on a site to pay for something, you're vulnerable, at least to the dishonest employees of the vendor or his ISP. Now that I've settled, I really enjoy the convenience of being able to recall my card without having to type it in again. I would design every e-commerce system to have this feature if my clients decided it was right for their business. Norm
Collaborative Software Design
Here's what Visa recommends to merchants:
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.
It's supposed to be completely automatic, but actually you have to press this button.
Really, you don't want to store credit card numbers. There are a number of services which will handle recurring transactions. Use one of those. They spend all day long dealing with credit card control issues. Let them worry about it. If your client thinks their decision about payment processor is locked in stone asked them how they expect to cover the liability of haveing all of their cusomter's cc numbers on hand. (Ask yourself about the liablility of creating such a system.)
Really, let the people whose job (and liability) it is to worry about the security. Your client's expertise is not this sort of security (and even if yours is) how can they expect to maintain this systems security when you've moved on?
Giving customer's the service they expect isn't the hard part. Any software engineer who knows Perl, Java, or C++ should be able to implement it without much difficulty. If you think that is the hard part please do not work in e-commerce.
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
SlashSig Karma: Excellent (mostly affected by moderatio
Store all of the credit info on a stand-alone PC with a CD burner, and sneeker-net the info to a networked PC once a month. Write an app that will not store the info anywhere off of the CD, and will encrypt the info as soon as it reads it. Remove the CD as soon as the billing procedure is finished, and make sure it is destroyed by the Controller.
This will work fine as long as you are taking credit numbers over the phone. If you need to have the information available online, God help you.
First you have to get OpenBSD, since Theo and Slashdot says it is the most secure.
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!
Conformity is the jailer of freedom and enemy of growth. -JFK
I have heard some great suggestions for those that can host their own site/app/db on multiple firewalled boxes. What about when you are in charge of everthing, including security, for a small site that can't afford to hire a consultant, let alone additional staff?
The owner thinks everything is fine because he pays for a security certificate and everyone sees a lock at the bottom of the screen. But that just fools consumers into an unmerited sense of security because at the back-end, plaintext cc #s are sent by a form-to-email CGI.
Is it the admin's responsibility to fix what the boss is unwilling to pay for? Or should you do the best you can with the resources available to you on your own time?
I know this is not an ideal work situation, but it's one that exists in the real world. If you're an amateur, but you're the only amateur they've got, shouldn't you at least try your best to do things right?
Everything must be encrypted. That's the first step. From SSL, to the connection between your Web and DB Server.
Once it's on there, make sure the data is encrypted inside the DB as well. Make the keys available to the CC processing program, and define security so that the only interface that has read access to the credit card data is the CC processing program.
That way the keys are not on the web server and if you do it right, compiled and hashed up inside your processing program.
For the very paranoid, part of the key should be entered in at runtime along with a password.
Passwords should only be given out to the most trusted people in the company.
Provide NO credit-card reading functions outside of the actual processing program. You can provide a search, update and delete, but no ability to read.
Encrypt everything between you and the CC processor, (cybercash, etc...).
Don't leave a trace log with all the info sitting in the root of the drive.
Block as much from the Internet as you can. Add IP restrictions, extra passwords, etc..
Basically, be paranoid.
If you have to ask if such a thing is possible then I seriously doubt that you should be designing and building it.
Funny. I laughed on that one. You deserve some points for that, unfortunately, I have no points.