Credit card payments (card-present, swiped) with ASP.NET MVC

Question

I need to take credit card payments with physical cards swiped in an ASP.NET MVC app.

The easiest approach would likely be to have a simple "keyboard-wedge" swipe (USB now days), so that the track data gets sent as keyboard input to a password-type input field.

I have some security concerns with this method, though:

• If they swipe the card when the cursor is in the wrong field, full track data is displayed in clear text.
• No end-to-end encryption (=card data sitting in clear text in memory / browser cache), and could be grabbed by keyboard sniffer.
• Full track data has to be sent to server, from where it will be sent to whatever payment gateway. Of course over SSL in both cases, but this adds the Web server to the attack surface. Interaction directly with payment processor from client would avoid this (if feasible), so that only the masked card # + authorization number or token, etc. would have to go to the server.

I have some ideas of possibly better options, but I am not sure if they are feasible:

• A stand-alone credit card device that talks directly to payment processor and integrates somehow with the PC with the ASP.NET app. Perhaps a credit card device that listen on a TCP port through which the ASP.NET app could communicate to it client-side. Or attached via USB and interacted with via a browser plugin or similar.
• an small iframe or similar to use a payment processor's "payment widget" directly
• use a USB swipe (despite sniffability) + some client-side library to interact with payment processor directly.

I am looking for some feedback and ideas on good ways (reliable and secure) to accomplish this (I plan to also contact some payment processors to see what I can find out from them).

Thanks.

Answer 1

I have contacted several payment gateways and credit card swipe companies and here is a fairly simple way to accomplish end-to-end encryption with credit card swipes in an ASP.NET app:

1) Use an swipe like an IDTech IDRS series swipe (keyboard wedge type - not HID): http://www.idtechproducts.com/download/swipe-readers/doc_download/166-user-manual.html

2) Send the swipe the the processor / gateway, who will inject their encryption key into the device.

3) After configuring the swipe properly, it will send the swipe data strongly encrypted as keyboard input, which you can then pass from the client-side javascript over to the server, which in turn sends it to the payment gateway, which decrypts and processes the data. The swipe will also send certain portions of the data unencrypted (such as the first and the last 4 digits of the card number).

Answer 2

your concerns are valid since the magnetic stripe is practically obsolete. In the United States it is common but in other countries credit cards use a Smart Chip which offers enhanced security preventing cloning the magnetic card.

But there are magnetic card readers that are PCI-DSS compliant, that will encrypt the data using 3DES and will also offer device/host authentication. This devices will allow you to bypass sniffing, using HID mode instead of Keyboard emulation, which allow for direct communication with the device.

When a card is swiped through the Reader, the track data will be TDEA (Triple Data Encryption Algorithm, aka, Triple DES) encrypted using DUKPT (Derived Unique Key Per Transaction) key management. This method of key management uses a base derivation key to encrypt a key serial number that produces an initial encryption key which is injected into the Reader prior to deployment. After each transaction, the encryption key is modified per the DUKPT algorithm so that each transaction uses a unique key. Thus, the data will be encrypted with a different encryption key for each transaction.

Other alternative that I really love is the ones that attach to the SmartPhones on the audio jack. Like the Square device you surely have seen or heard. They have the same principles of TDAE and DUKPT but modulate the data into sounds which are demodulated by the App.

This security steps are needed if you plan to accept credit cards as "Card Present". If you are Ok with "Card Not Present" you can just capture the track data and send it for approval to a Payment Gateway. The Payment Gateway will not know if the card was really present or if you manually typed the info. If you want to have "Card Present" capabilities the payment gateway will require you to use PCI certified equipment.

And about ASP.NET MVC, it is not possible, this must be a client app or software in order to have end to end encryption.