Related
I have a (university) project where I basically write and read text out of an NFC tag with Android devices in order to store one's balance in the card (which can be used on the cafeteria, for example).
Right now, I'm using NTAG213 doing the below code:
ndef.connect();
NdefRecord mimeRecord = NdefRecord.createMime("text/plain", messageEncrypted.getBytes(Charset.forName("US-ASCII")));
ndef.writeNdefMessage(new NdefMessage(mimeRecord));
ndef.close();
As you can notice, I'm using application level encryption to encrypt the message (messageEncrypted) before writing it to the tag (AES-256 encrypt with 'com.scottyab:aescrypt:0.0.1' library - with a very big password key that uses also the tag UID as part of it).
So far so good - only I can understand the data on the tag.
On my research, I've found that when it comes to security Ultralight C > NTAG213.
Question 1) When using application level encryption, why (is it?) is MIFARE Ultralight C safer then NTAG213?
Question 2) I'm pretty sure I can guarantee security using AES encryption, but I don't want people (besides me) messing with the stored data (formatting tag or writing info there). I see that the only way of preventing that (please, correct me if I'm wrong) is to set a password for the tag. However, both NTAG213 and Ultralight C have only an 32-bit password. Is it good enough? Is there another way of preventing someone (besides me) writing data?
Question 3) Which other security measures can I use on such tags to enforce security (tag and application layer)?
Question 4) When you compare tag security (MIFARE DESFire > Ultralight > NTAG213 > MIFARE Classic), what is really being compared? The ease of one cracking the (native tag's) encryption or the ease of one store (anything) on the tag without permission?
Question 5) I see a bunch of other techs (MIFARE DESFire, ICODE SLIX, Infineon Cipurse) that are more secure, which makes me wonder if the tech I'm using (NTAG213 or Ultralight C) is good enough for storing someones balance. Would you (and that's a personal opinion) say that NTAG213 with application level encryption and 32-bit password good enough for this type of application? And how long would it take someone to actually break its security?
When using application level encryption, why is Ultralight C safer then NTAG213? Is that even true?
First of all, "safer" depends on what your actual protection goals are. Since you want to store a balance (cash money!) on the card, you would probably want to (at least) protect towards the following goals:
Users must not be able to print their own money by setting an arbitrary balance on their card.
Users must not be able to duplicate their card and, consequently, their money balance.
Users must not be able to print their own money by restoring (roll-back) their card to a previous balance after payment.
Users must not be able to print their own money by replaying a top-up procedure.
Users must not be able to evade payment by tearing their card during a payment transaction.
Users must not be able to generate an arbitrary (and potentially higher) balance on their card by tearing their card during a top-up procedure.
In addition, you might not want to trust operators (the persons accepting payments and performing top-up) as well. In a system where one group of operators performs only top-up and the other performs only payment transactions, the latter group should probably not be allowed to ever "create" money. Particularly, you have to make yourself very clear about whether you fully trust the (Android) devices that you use in the field to perform these operations and whether you trust operators (e.g. that they don't perform any attacks against these devices).
Moreover, there might be privacy aspects that you need to consider (e.g. if the balance is freely readable, if users are identifiable, etc.)
So let's look into what you "application level encryption" adds in terms of security:
Since users do not know the encryption key, they are probably not able to generate an arbitrary balance on their card. However, this heavily depends on the format of your balance (in unencrypted form). Users can make arbitrary modifications to the cipher text with result in "random" modifications of the plain text. Consequently, users may be able to modify the balance value despite encryption. Digital signature/message authentication codes are they path that you would probably want to take to overcome this.
Since the encryption key (assuming encryption would be sufficient, which it probably is not) depends on the UID of the tag, you may be safe against cloning of cards (+ balance). However, be aware that the UID is just a freely readable identifier. It is by no means authenticated itself and may be clonable as well. See Serials on NFC Tags - truly unique? cloneable?.
The encrypted value does not protect you from users restoring their balance to a previously recorded value after payment. This type of vulnerability has been found before (particularly in MIFARE Ultralight based systems), see, for instance, Benninger, C., Sobell, M. (2012): NFC for free rides and rooms (on your phone). In: Presentation at EUSecWest 2012.
Since you write the complete value during a top-up procedure (i.e. there is no specific "increment balance" command), you are probably safe against users replaying a top-up (except for the roll-back aspect of this).
Effects of tearing are probably rather limited if your system only allows for attended payment/top-up.
So let's see what additional features NTAG213 would have that you could use to secure your system:
UID is unique on genuine tags. This does not help much, see Serials on NFC Tags - truly unique? cloneable?.
Originality signature: same as above, the originality signature is also just a static, freely readable value. Consequently, it's just as well susceptible to cloning.
The one-way counter might be a tool to help you in protecting against roll-back (by including the counter value into the signature). This still would not prevent cloning onto a tag platform that allows to generate arbitrary counter values. Moreover, the counter is not easily controllable and will change its value if the user tries to read the tag. Consequently, it's questionable if an implementation based on that value would be reliable.
Unlike MIFARE Ultralight, NTAG213 does not have a usable one-time programmable area (since that's already used by the capability container). Consequently, you can't implement a one-time deductible balance based on that.
The password protection feature could help you in authenticating tags (by performing password verification) and in protecting the value stored on the tag (by making the value only readable/writable after password verification). However, the password is transmitted in clear text (may be subject to sniffing, particularly in (but not limited to) unattended scenarios) and there is no cryptographic binding between the password and the actual read/write.
MIFARE Ultralight C would add the following:
The OTP bytes can be used. If it's an option to make the tags one-time usable (i.e. they start with a specific balance that can only be deducted from and not topped-up), then using the OTP bytes to represent the balance would be an option. Note that there's still lots of things that you could do wrong with that, e.g. Beccaro, M., Collura, M. (2013): OTP circumventing in MIFARE ULTRALIGHT: Who says free rides?. In: Presentation at DEFCON 21
The authentication is much improved. The 3DES authentication scheme seems to be sufficiently secure to prevent sniffing the key. However, read/write commands are also not cryptographically bound to the authentication step. Consequently, an attacker might be able to let a genuine payment terminal + genuine tag perform authentication, but redirect read/write to somewhere else. This might (particularly) be a problem in an unattended scenario.
I'm pretty sure I can guarantee security using AES encryption.
See above. This is probably not true.
I don't want people messing with the stored data. I see that the only way of preventing that is to set a password for the tag.
A password/authentication key may help, but be aware of the limitations due to authentication being decoupled from read/write on these tag platforms.
Both NTAG213 and Ultralight C have only a 32-bit password.
This is not true. NTAG213 has a 32-bit password. MIFARE Ultralight C uses a more sophisticated mutual 2K-3DES authentication mechanism with a 112-bit key.
When you compare tag security, what is really being compared?
Authentication mechanisms (algorithms, key sizes)
Communication security (e.g. is the communication itself encrypted/authenticated using a session key derived from the authentication step?)
Access control (e.g. are there separate keys for top-up and payment?)
Are there dedicated mechanisms for balance management (e.g. value fields, dedicated increment/decrement operations)? And, consequently, are ther mechanisms to protect agains tearing attacks?
And probably more ...
I see a bunch of other techs that are more secure, which makes me wonder if the tech I'm using is good enough for storing someones balance.
You specific system is flawed in many ways. In my opinion MIFARE Ultralight/NTAG203/NTAG21x are definitely not a good choice for a an offline system storing cash money on the cards.
MIFARE Ultralight C may be suitable with some precautions. I would definitely refrain from using that in unattended scenarios, and I would probably use an online system tracking the balance and monitoring for inconsistencies.
Anything that uses symmetric cryptography and storing the cryptographic keys in a terminal would certainly require precautions against malicious operators. It's probably fairly easy for an operator (with some knowledge) to extract keys from an app and generate their own money.
I guess your question is too broad and not for all subquestions this section of SO is the most appropriate one.
By focusing on cryptographic strength you miss something: if the low level security of the token can be easily attacked, nobody needs to crack your key.
A simple dump and later restore (after some payments) corresponds to printing money
If the token contains the money directly (instead of only identifying the wallet, which is stored on a background system), you need a far more secure system to avoid financial damage. This involves dynamically encrypted communication but continues with substantial further topics.
We have a business requirement to keep credit card data. What is today's (Nov 2013) state of the art algorithm to encrypt credit card data that will be saved on disk?
Additionally, I'd appreciate pointers to Java libraries that implement these algorithms
Note that we are PCI compliant and we already store credit card data. I am doing a review to make sure that our encryption method remains state-of-the-art
I recently just left the credit card industry as a developer to work in security in non PCI compliant field. BCrypt is a great choice. It allows a one way hash as well as a work parameter that forces time per attempt. This allows you to stop brut force attacks.
I would use one of the block ciphers approved by ISO/IEC 18033: AES, Camellia, and SEED.
It's hard to go wrong with AES256.
Just go ahead with AES 256 but make sure you choose right mode. I don't agree with comment "It's hard to go wrong with AES256." Check out - https://pthree.org/2012/02/17/ecb-vs-cbc-encryption/
Needless to say, you need to take care of key management and avoid any issues with IV- a message "hello world" encrypted with a key1+IV1 combination will look exactly the same in ciphertext every time you run your encryption. So make sure you are choosing your IVs randomly from a large entropy pool
From Java implementation perspective, Java has native support for AES encryption. Just make sure if you are using 256 bit encryption, you have the right unlimited strength JCE files - without these JCE files which provide crypto methods, you will be limited to 128 bit encryption.
Checkout this if you don't want to reply upon these JCE files available on server running your application.
As #gauravphoenix points out, it is actually quite easy to go wrong with AES. The AES algorithm itself can only securely encrypt exactly 16 bytes of data if you give it a totally random key. If your problem is anything other than that (and almost everyone's problem is something different than that), you need to add more pieces to it. Specifically you need to choose an appropriate mode, configure that mode correctly, properly generate a key, and protect against modification. AES does none of this for you automatically, and unfortunately, most example code on the internet does it incorrectly.
There are a few libraries that attempt to bundle all of these details for you so that you can just make the silly "please encrypt this data" call that most people would like to make. I maintain one for iOS called RNCryptor. There are a bunch of ports of the format to other languages, including a Java implementation called JNCryptor.
Another good "whole solution" AES implementation is aescrypt, which includes a Java implementation.
Note that the most important technical(*) step of securing the data is not your selection of algorithm or format. It's how you manage the keys. If you store the key on the same disk as the credit card numbers, or hard-code it into your software, then it doesn't really matter how strong your encryption is. The state of the art in key management is called an HSM (Hardware Security Module). Companies like SafeNet make them. They can be rack-mounted, plug-in cards, or even USB dongles. I've worked with the Luna, and was generally pleased with it, but there are several options on the market.
(*) While key management is IMO the most important technical step, it is by far not the most important step in securing credit cards (or anything else). The most important step is having procedures in place that encourage secure design, pre- and post-release security review, and a commitment to remediation of security findings.
I am working in PHP on a Linux server with MySQL.
I have a requirement (that I have attempted to talk them out of) to collect credit card information from users so that our company can use the card numbers to hold hotel rooms for a conference. We will not be charging the cards ourselves at all, but instead just sending them to the hotel. I then need to be able to download a CSV file and each time someone signs up an email to go to the admin with all the information.
I tried to explain that this wasn't secure, but several other developers have done this for them in the past before I was working here.
My question is; is there anyway to make this secure? If not are there any third party options to make this happen?
EDIT:
I appreciate everyone who has posted so far, it has simply made me want to attempt to do this less and less. If you could add to your answers simple explanations, oriented at non-tech people, it would be greatly appreciated, in fact site source and links would help me a great deal. I haven't found any sites that would explain this in a non-tech way.
First of, I am not a lawyer. I have implemented CC-handling code several times previously, but I am only familiar with Danish laws and regulations, so your mileage may vary.
As far as I know, there are restrictions in place (law and regulations from the CC providers) that you need to be aware of. I don't know where you are in the world, but in many countries you need to be PCI certified to handle credit card data and that is an extremely onerous, expensive and on-going process.
Other countries, or states, may have notification rules in play that requires you to pay the cost of notifying the card holder if security is broken - and unless you are very careful, it is not unlikely.
In general, I would recommend against that procedure. You may risk being liable for any costs if it goes wrong.
It's really a bad idea to be storing card details. You're opening yourself up for a world of pain in the form of PCI-DSS audits. It is not as simple as 'use encryption', you need to have processes in place to securely manage the encryption keys, schedule key rotation, securely log access and so on and on... Storing card details is absolutely something you want to avoid.
If you have to have something in place, then the best option may be for you (as a company) to take payments from the credit cards to your own merchant account, then pay the hotels separately (from your bank account/whatever). You act as a proxy for the client making the payment to the hotel.
Most payment gateways allow you to store the card details securely, and charge at a later date (using a token id returned by the gateway), which will likely be useful here. But you wont be able to retrieve the card details to pass them through to the hotel in any way, which is why you would need to take payment, then organise a separate payment to the hotel.
Its still quite an undertaking though because a lot of areas of PCI-DSS will come into play even with this simplified solution.
You asked, so here is more information:
PCI-DSS is the Payment Card Industry Data Security Standard. It's a set of guidelines which basically apply to any company that 'touches' cardholder data, in particular the card number. Touching it literally means any handling of the data, even just having it pass through your network without it ever being persisted to disk is enough to mandate that you must comply, (though it is significantly easier if you don't persist the details to disk)
You didn't yet state which part of the world you're in, or how these card details are captured (internet/telephone/in person). These details are significant to how you can achieve compliance.
Start by taking a look at the PCI-DSS SAQ (Self Assessment Questionnaires). These SAQ's are the minimum requirements for companies that do not store cardholder details to disk, and should give a good impression of the security that needs to be in place across the network and policies that should be applied across the company.
As I said, if you're thinking of storing card details then things get more complicated, because as a general rule the SAQ is no longer good enough. You need to enrol the assistance of a QSA (Qualified Security Assessor) who will visit and advise on best practice for data storage and the various other points that come into play. For this level of compliance you're looking at yearly audits (carried out by the QSA), and quarterly network scans. Take a look at the audit procedures to get a detailed look at what is involved. In particular take a look at section 3 and do not underestimate the difficulty of implementing proper key management.
In summary, full PCI compliance will be very costly. Even for a company which already has pretty strong security policies the cost of bringing in a QSA and running quarterly scans and yearly audits alone will likely cost $thousands.
This is very insecure and I think you're correct for opposing it. That said...
Some ideas:
Can the hotel give you a rate/group code that you can disseminate to your users directly? Perhaps you could even give them a link that goes right to the hotel's reservation page, with the code already filled in.
Don't even think about implementing this unless you can do it on an SSL-enabled site.
Don't save the CC number anywhere,
just generate the email and toss the
number out. This alleviates you from having to worry about a ton of very difficult application / server security issues.
Encrypt the email with GPG or
equivalent so that it's protected in
transit and can only be read by the intended recipient.
I suggest you follow the Card Industry PCI compliance closely at least. Here is a PDF document.
As someone who has worked on a system like this, it is 100% illegal to store any credit card information in plain text. You must encrypt all of the data and you are not allowed to know any piece of the keys. It is quite the catch 22, the only way to validate data is to guess as sad as that sounds. This is the exact reason why accidental charges occur.
As others have said here, it's a fact that storing credit card information requires you to be certified. You can ask for information to process the transaction but keeping it on storage of any kind is a big no-no.
Fortunately sites like authorize.net, braintree.com, paypal.com, etc will let you interact with their APIs in such a way that you get a "Customer Vault ID" for each entity you'd like to make transactions for.
These 3rd parties store all the sensitive information in a 100% legit way. And whenever you would like to make a transaction using their saved information, you interact with the service using their "Vault ID".
I've used authorize.net, BrainTree and PayPal. Most recently it was BrainTree and had some good success with them. I would not recommend PayPal unless you need the brand recognition or you just want to do a direct transfer whereby you bypass asking them for account information of any kind (because they already entered it in PayPal).
Make sure your server is as secure as possible and prove that it isn't already compromised. None of this will really work well if you have a compromised server.
Use SSL to protect this information during transit.
Encrypt these details immediately upon receipt. This will help protect it at rest. If possible, encrypt it with a public key for a key pair where the private key (used for decryption) is not on your server. This could easily be that you place this information into the body of the email that you're required to send, then encrypt the body with public-key encryption where your client has the private key. (You could use PGP here). In this way, the data is help on your server as briefly as possible, then once off your server, is accessible only by your client. If you use a symmetric encryption algorithm, then your key will necessarily also be on your server somewhere (on disk, in memory, etc.), which could be obtained and used by an attacker to regain access to the details.
This isn't an endorsement, per se, but I have used this before in similar situations with good results: http://www.pgp.com/products/commandline/
Remember that there are always security holes, but you'll be raising a large barrier against attacks with these steps. I might also add that you look into a system integrity solution like Trip Wire from the immediate build of your server. And of course, ensure that all of your passwords are strong.
If you send the file via email, be sure to use secured connexions (HTTPS / IMAP or POP3 over SSL, SMTP over SSL) on both sending and receiving computers and have the file encrypted prior sending. You can encrypt your mail and attachment via OpenPGP, too. Also, ensure the security between the two mail servers (sending and receiving), or simply use the same domain for sending and receiving email addresses. Do not use the password-feature of a ZIP file or related comrpessing container, since they are usually cryptographically weak.
If you send it on a filesystem (ie. USB pendrive), be sure to use a crypted one (ie. TrueCrypt).
Be sure to have a secured computer where the download and upload takes part (encrypted partition where the download/upload takes place, no spywares on the system, passworded system, firewalled).
Does anyone know of an algorithm for computing how much you 'trust' another user (their reputation) in a decentralised system.
Sites like this one use a centralised authority to track reputation points, but when you can't trust an authority to maintain this list impartially, or the infrastructure doesn't exist, how can you rank your peers' reputation?
I'm imagining something akin to PageRank - I trust my friend Alice, she trusts her friend Bob, therefore I have some transitive trust for Bob. If my other friend Carol also trusts Bob, then my trust for Bob increases.
Is there some way of computing this globally, or does each user have to track their own network?
I was thinking you could just 'declare' who you trust, which would give each person a corresponding set of incoming trust links, but I feel this would be easy to game by creating many zombie users who just create reputation points, like link farms in search results. And that may be the kernel of the problem: if Google still has problems with people generating bogus PageRank scores, it might not be a problem easily solved :)
Take a look at the EigenTrust algorithm:
The EigenTrust Algorithm for Reputation Management in P2P Networks - S. D. Kamvar, M. T. Schlosser, and H. Garcia-Molina
This algorithm assigns each peer in the network a global trust value.
The web site Advogato implements a distributed trust metric. The source code is available. Here is the FAQ, and a description of the trust metric.
it might not be a problem easily solved
You got that right. This is a very actively researched area, especially in a P2P environment. A quick google search for trust p2p network turns out quite a few papers on it.
This one in particular brings up a good list of things to consider, (and provides an algorithm of sorts).
Overcoming Reentry and Entry Barrier - How do you prevent bad people from making a new nickname and rejoining a network?
Creating incentives to rate - What is the incentive for a large P2P network to rate other users for trust?
It is often much simpler for a single authorized server to manage trust/reputation between users. You will have to come up with a good reason why you would want it to be decentralized.
I think possibly a system by which each user tracks and serves their own trust uplinks could work in a situation like this. For example; say user A trusts user B and rates them a 5 in trust (out of 10). Let's say I don't know whether or not to trust user A or user B; if user A does something that causes me to trust them, I can mark them as trusted, and they can tell me who THEY trust; then I would get User A's ranking of User B, and I can adjust the trust as I see fit; if I have high trust in User A, I might give user B a rating of 5 (based entirely upon user A's rating of them); if I trust user A just a little, I might give user B a rating of 1 (better than no trust, but not as trusted as User A finds them to be). In that way, users determine the first order of trust by trustworthy things (upvoting their posts, or the like) and then can have "associated" trust from those users they explicitly trust come through; there's a "second order" network effect going on. I'd specifically say that when a user gets trust information for other users from someone, they should only grant "implicit trust" to those users who were granted "explicit trust" by that user they're getting the trust information from.
Perhaps "An Algebra for Assessing Trust in Certification Chains."
However, trust is a hard human problem that can be at best approximated with an algorithm like the one mentioned in the paper.
Further recommended reading:
Web of Trust (e.g. CAcert.org)
Key Signing Party
Reflections on Trusting Trust
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
This question talks about different payment processors and what they cost, but I'm looking for the answer to what do I need to do if I want to accept credit card payments?
Assume I need to store credit card numbers for customers, so that the obvious solution of relying on the credit card processor to do the heavy lifting is not available.
PCI Data Security, which is apparently the standard for storing credit card info, has a bunch of general requirements, but how does one implement them?
And what about the vendors, like Visa, who have their own best practices?
Do I need to have keyfob access to the machine? What about physically protecting it from hackers in the building? Or even what if someone got their hands on the backup files with the sql server data files on it?
What about backups? Are there other physical copies of that data around?
Tip: If you get a merchant account, you should negotiate that they charge you "interchange-plus" instead of tiered pricing. With tiered pricing, they will charge you different rates based on what type of Visa/MC is used -- ie. they charge you more for cards with big rewards attached to them. Interchange plus billing means you only pay the processor what Visa/MC charges them, plus a flat fee. (Amex and Discover charge their own rates directly to merchants, so this doesn't apply to those cards. You'll find Amex rates to be in the 3% range and Discover could be as low as 1%. Visa/MC is in the 2% range). This service is supposed to do the negotiation for you (I haven't used it, this is not an ad, and I'm not affiliated with the website, but this service is greatly needed.)
This blog post gives a complete rundown of handling credit cards (specifically for the UK).
Perhaps I phrased the question wrong, but I'm looking for tips like these:
Use SecurID or eToken to add an additional password layer to the physical box.
Make sure the box is in a room with a physical lock or keycode combination.
I went through this process not to long ago with a company I worked for and I plan on going through it again soon with my own business. If you have some network technical knowledge, it really isn't that bad. Otherwise you will be better off using Paypal or another type of service.
The process starts by getting a merchant account setup and tied to your bank account. You may want to check with your bank, because a lot of major banks provide merchant services. You may be able to get deals, because you are already a customer of theirs, but if not, then you can shop around. If you plan on accepting Discover or American Express, those will be separate, because they provide the merchant services for their cards, no getting around this. There are other special cases also. This is an application process, be prepared.
Next you will want to purchase an SSL certificate that you can use for securing your communications for when the credit card info is transmitted over public networks. There are plenty of vendors, but my rule of thumb is to pick one that is a brand name in a way. The better they are known, the better your customer has probably heard of them.
Next you will want to find a payment gateway to use with your site. Although this can be optional depending on how big you are, but majority of the time it won't be. You will need one. The payment gateway vendors provide a way to talk to the Internet Gateway API that you will communicate with. Most vendors provide HTTP or TCP/IP communication with their API. They will process the credit card information on your behalf. Two vendors are Authorize.Net and PayFlow Pro. The link I provide below has some more information on other vendors.
Now what? For starters there are guidelines on what your application has to adhere to for transmitting the transactions. During the process of getting everything setup, someone will look at your site or application and make sure you are adhering to the guidelines, like using SSL and that you have terms of use and policy documentation on what the information the user is giving you is used for. Don't steal this from another site. Come up with your own, hire a lawyer if you need to. Most of these things fall under the PCI Data Security link Michael provided in his question.
If you plan on storing the credit card numbers, then you better be prepared to put some security measures in place internally to protect the info. Make sure the server the information is stored on is only accessible to members who need to have access. Like any good security, you do things in layers. The more layers you put in place the better. If you want you can use key fob type security, like SecureID or eToken to protect the room the server is in. If you can't afford the key fob route, then use the two key method. Allow a person who has access to the room to sign out a key, which goes along with a key they already carry. They will need both keys to access the room. Next you protect the communication to the server with policies. My policy is that the only thing communicating to it over the network is the application and that information is encrypted. The server should not be accessible in any other form. For backups, I use truecrypt to encrypt the volumes the backups will be saved to. Anytime the data is removed or stored somewhere else, then again you use truecrypt to encrypt the volume the data is on. Basically where ever the data is, it needs to be encrypted. Make sure all processes for getting at the data carries auditing trails. use logs for access to the server room, use cameras if you can, etc... Another measure is to encrypt the credit card information in the database. This makes sure that the data can only be viewed in your application where you can enforce who sees the information.
I use pfsense for my firewall. I run it off a compact flash card and have two servers setup. One is for fail over for redundancy.
I found this blog post by Rick Strahl which helped tremendously to understand doing e-commerce and what it takes to accept credit cards through a web application.
Well, this turned out to be a long answer. I hope these tips help.
Ask yourself the following question: why do you want to store credit card numbers in the first place? Chances are that you don't. In fact, if you do store them and manage to have one stolen, you could be looking at some serious liability.
I've written an app that does store credit card numbers (since the transactions were processed offline). Here's a good way to do it:
Get an SSL certificate!
Create a form to get CC# from the user.
Encrypt part (not all!) of the CC# and store it in your database. (I'd suggest the middle 8 digits.) Use a strong encryption method and a secret key.
Mail the remainder of the CC# to whoever processes your transactions (probably yourself) with the ID of the person to process.
When you log in later, you will type in the ID and the mailed-out portion of the CC#. Your system can decrypt the other portion and recombine to get the full number so you can process the transaction.
Finally, delete the online record. My paranoid solution was to overwrite the record with random data before deletion, to remove the possibility of an undelete.
This sounds like a lot of work, but by never recording a complete CC# anywhere, you make it extremely hard for a hacker to find anything of value on your webserver. Trust me, it's worth the peace of mind.
The PCI 1.2 document just came out. It gives a process for how to implement PCI compliance along with the requirements. You can find the full doc here:
https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
Long story short, create a separate network segment for whichever servers will be dedicated to storing CC info (usually DB server(s)). Isolate the data as much as possible, and ensure only the minimum access necessary to access the data is present. Encrypt it when you store it. Never store PAN's. Purge old data and rotate your encryption keys.
Example Don'ts :
Don't let the same account that can lookup general info in the database look up CC info.
Don't keep your CC database on the same physical server as your web server.
Don't allow external (Internet) traffic into your CC database network segment.
Example Dos:
Use a separate Database account to query CC info.
Disallow all but required traffic to CC database server via firewall/access-lists
Restrict access to CC server to a limited set of authorized users.
I'd like to add a non-technical comment that you may wish to think about
Several of my clients run e-commerce sites, including a couple who have moderately large stores. Both of those, whilst they certainly could implement a payment gateway choose not too, they take the cc number, store it temporarily encrypted online and process it manually.
They do this because of the high incidence of fraud and manual processing allows them to take additional checks before filling an order. I'm told that they reject a little over 20% of all their transactions - processing manually certainly takes extra time and in one case they have an employee who does nothing but process transactions, but the cost of paying his salary is apparently less than their exposure if they just passed cc numbers though an online gateway.
Both of these clients are delivering physical goods with resale value, so are particularly exposed and for items like software where a fraudulent sale wouldn't result in any actual loss your mileage would vary, but it's worth considering above the technical aspects of an online gateway if implementing such is really what you want.
EDIT: And since creating this answer I'd like to add a cautionary tale and say that the time is past when this was a good idea.
Why? Because I know of another contact who was taking a similar approach. The card details were stored encrypted, the website was accessed by SSL, and the numbers were deleted immediately after processing. Secure you think?
No - one machine on their network got infected by a key logging Trojan. As a result they were identified as being the source for several score credit card forgeries - and were consequently hit by a large fine.
As a result of this I now never advise anyone to handle credit cards themselves. Payment gateways have since become much more competitive and cost effective, and fraud measures have improved. The risk is now no longer worth it.
I could delete this answer, but I think best to leave up edited as a cautionary tale.
Keep in mind that using SSL to send a card number from a browser to a server is like covering your credit card number with your thumb when you hand your card to a cashier in a restaurant: your thumb (SSL) prevents other customers in the restaurant (the Net) from seeing the card, but once the card is in the hands of the cashier (a web server) the card is no longer protected by the SSL exchange, and the cashier could be doing anything with that card. Access to a saved card number can only be stopped by the security on the web server. Ie, most card thefts on the net aren't done during transmission, they're done by breaking through poor server security and stealing databases.
Why bother with PCI compliance?? At best you'll shave a fraction of a percent off your processing fees. This is one of those cases where you gotta be sure this is what you want to be doing with your time both upfront in development and over time in keeping up with the latest requirements.
In our case, it made the most sense to use a subscription-savy gateway and pair that with a merchant account. The subscription-savy gateway allows you to skip all the PCI compliance and do nothing more than process the transaction proper.
We use TrustCommerce as our gateway and are happy with their service/pricing. They have code for a bunch of languages that makes integration pretty easy.
Be sure to get a handle on the extra work and budget required for PCI. PCI may require huge external audit fees and internal effort/support. Also be aware of the fines/penalties that can be unilaterally levied on you, often hugely disproportionate to the scale of the 'ofense'.
There's a lot to the whole process. The single easiest way to do it is to use services similar to paypal, so that you never actually handle any credit card data. Apart from that, there's a quite a bit of stuff to go through to get approved to offer credit card services on your website. You should probably talk with your bank, and the people who issue your merchant ID to help you in setting up the process.
As others have mentioned the easiest way into this area is with the use of Paypal, Google checkout or Nochex. However if you intend to to a significant amount of business you may wish to look up "upgrading" to higher level site integrations services such as WorldPay, NetBanx (UK) or Neteller (US). All of these services are reasonably easy to set up. And I know that Netbanx offers convenient integration into some of the off the shelf shopping cart solutions such as Intershop (because I wrote some of them). Beyond that you are looking at direct integration with the banking systems (and their APAX systems) but thats hard and at that point you also need to prove to the Credit card companies that you are handling the credit card numbers securely (probably not worth considering if you are not taking $100k's worth per month).
Working from 1st to last the cost/benefits are that the early options are much easier (quicker/cheaper) to set up put you pay quite high handling charges for each transaction. the later ones are much more costly to set up but you pay less in the long run.
The other advantage of the most of the non dedicated solutions is that you don't need to keep encrypted credit card numbers secure. Thats someone else's problem :-)