Hello All: == Some Background == LinkPoint is the name of the API that Card Service International (one of the biggest online merchant account providers) uses for communication between a merchant's servers and their credit-card gateway. The LinkPoint client API communicates with the credit-card gateway using an SSL-based protocol. Authentication and encryption is facilitated with x509 digital certificates (the same ones that https uses). You must provide the client with two pieces of information for it to authenticate to the gateway server. The first is what CSI calls "Store Name" -- it's actually a six digit number. The second is the path to the certificate file they send you. == The Problem == Although I have not discovered a technical (code) security problem, I believe there is a serious procedural security problem in they way CSI initially sets up accounts. When you are approved for a CSI merchant account (or even when you are approved for a test account), CSI sends you two emails. One of the emails has the subject "Welcome to LinkPoint API" (the other is unimportant). This email contains two pieces of information: The gateway server's hostname Your "Store Name" (the six digit number) Plus, they attach your certificate AND _private key_ to the bottom of the message. The idea is that you copy and paste the cert + private key into a file for the client API to use when it connects. I don't think I need to spell out the problem any further for everyone on this list. Basically, they are sending all of the information you need authenticate as a merchant through plain, unencrypted, email. You would need a few more things to exploit this potential security hole. Namely, you would need the CSI API and some knowledge of how to use it. This appears to be an attempt at security through obscurity. Also, you would obviously need a way to get the plain email (sniffing, etc) Notes: * The digital certificates do not have a passphrase. * The LinkPoint API documentation is publicly available at: http://www.cardservice.com/inetserv/lpapi.pdf == Card Service's Response == My attempt to contact CSI lead to a phone call from the "Lead Senior Tech" in the "API Support" department of CSI. Since I did not type this email while I was on the phone, all of the quoted comments bellow are from memory and probably aren't exact. They are, however, pretty close to what was said. I spoke with this person for about ten minutes and was not satisfied with his response. This person's basic theme was "It's never happened before and there are security precautions on the back-end". I explained to him that using the information in their email, I could pose as the merchant -- and after a while, he reluctantly agreed. I then asked him to clarify how that isn't a serious security problem, and he quickly responded with something along the lines of "lets say you can pose as the merchant, what are you going to do?". I responded by saying "I'd start posting refunds to my card" and he said "the refund option has to be enabled per merchant". Next, I told him I could charge cards. His response to this was that "well, then you would be giving money to the merchant". I suggested to him that if I was a malicious user, I could charge random cards with random amounts to the merchant's account. His response: "our backend would detect that". I asked for clarification and realized that the security he is talking about is their "Fraud Protection" system. From my knowledge (and I've used the CSI API in several projects) and according the the API documentation available online, this system just blocks an end-user from attempting to charge credit cards if they've had repeated failures. The key here is that it uses the _end user's_ (the person submitting a credit card to the merchants site -- the web browser) IP. This IP is sent to the gateway server from the client API. It's very simple to write a program which charges a whole bunch of cards and makes the API think each one came from a different IP (especially since the IP is just one of the items in the struct you pass to the client API). Obviously, the Fraud Protection provided by the gateway server is not meant to prevent a fraudulent merchant -- it is made to prevent fraudulent customers from fooling legitimate merchants. In this scenario, you _would be_ the merchant and therefore not subject to fraud checks. At this point, I had given up. I have a hard time understanding how it's "not a security problem" for me to be able to pose as the merchant. Even if I can't refund my card, I can cause a lot of unwanted trouble by charging cards, etc. == Summary == Unprotected Digital Certificates (no passphrase) that establish the identity of a merchant are sent via unencrypted email, along with the merchants "Store Name". Someone with access to the LinkPoint API could use this information to pose as the merchant and have access to all of the same functions and information as the merchant (charge a card, etc). -- Tolga