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.
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.
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).
Related
I found this Does my application "contain encryption"? which provides very useful information but I'm not sure if my case falls under this export compliance where my App only displays encrypted messages ( let say AES 256 encrypted messages ).
For more details, let's say App sends clear message (with base64 encode) to a Server using HTTP ( not even HTTPS) to encrypt using AES, and then display the received result on the App. App also sends encrypted messages, which user to key in, to Server to fetch the clear messages back and display. So, should this App be considered 'No contain encryption' ?
Thank you
According to the Apple documentation:
"If your app uses, accesses, contains, implements, or incorporates encryption, this is considered an export of encryption software, and is therefore subject to U.S. export and other country or region import compliance requirements.
Use of encryption includes, but is not limited to:
Making calls over secure channels (i.e. HTTPS, SSL, and so on).
Using standard encryption algorithms.
Using crypto functionality from other sources such as iOS or macOS.
There are, however, exemptions to this, and you are exempt if (and only if) all of the encryption used in your app falls into at least one of the following categories:
(a) Specially designed for medical end-use
(b) Limited to intellectual property and copyright protection
(c) Limited to authentication, digital signature, or the decryption of data or files
(d) Specially designed and limited for banking use or "money transactions"; or
(e) Limited to "fixed" data compression or coding techniques
So in this specific example (as with most iOS apps), it is likely that your app will require export compliance.
If you require compliance, you will be required to file a year-end self classification report to the US Bureau of Commerce.
We have a requirement where we need to login in to our application using fingerprints. We do understand that apple touch id can be used for authentication purpose and only returns success or failure in the response.
However, in our case one iPhone device will be shared by 5 to 8 users and we need to map an unique userId with each saved fingerprint to identify the user.
Is there any way to map a userid with the saved fingerprint (any unique number returned from an api like Fingerprint1, Fingerprint2 will do)?
Or Is there any alternative solution to login to our iOS application using biometric data?
We dont't want to add an extra fingerprint scanner device.
No, You can't achieve this in iOS. According to Apple about biometric
Touch ID doesn't store any images of your fingerprint. It stores only
a mathematical representation of your fingerprint. It isn't possible
for someone to reverse engineer your actual fingerprint image from
this mathematical representation. The chip in your device also
includes an advanced security architecture called the Secure Enclave
which was developed to protect passcode and fingerprint data.
Fingerprint data is encrypted and protected with a key available only
to the Secure Enclave. Fingerprint data is used only by the Secure
Enclave to verify that your fingerprint matches the enrolled
fingerprint data. The Secure Enclave is walled off from the rest of
the chip and the rest of iOS. Therefore, iOS and other apps never
access your fingerprint data, it's never stored on Apple servers, and
it's never backed up to iCloud or anywhere else. Only Touch ID uses
it, and it can't be used to match against other fingerprint databases.
Now come to main point.
Now days iPhone X series is more popular than other, and they don't support Touch ID, also you can store only one Face ID per device. not like the Touch ID (with multiple finger).
Or after certain wrong try of finger print the device will locked and you have provided Passcode, This is also one per device.
No, there's no way for you to know how many and which finger was used for biometrics, the secure enclave only lets you know if the biometric check has passed or not.
Some apps like Sideline, Hushed, can be used in USA and Canada as a second phone number, what's the technical principle?
Our app NumberBay, does this for 60+ countries, including USA and Canada. So I know what I'm talking about:
Calls are received on a virtual phone number (called a DID).
DIDs are often purchased from 3rd party companies (like top-quality Voxbone and our supplier). This is because deals must be made with government organisations and/or large telephony companies in every supported country. Also often infrastructure must be configured/rented/bought to support the connections. This is massive amount of work and very specialized.
When someone calls the DID, this call is received by this 3rd party and is forwarded (using SIP) to the NumberBay/Hushed/Sideline server.
(VoIP (Voice over Internet Protocol) is the general terms for telephony using internet. SIP is a possible implementation/example of VoIP.)
This NumberBay/Hushed/Sideline server knows to which user account the called DID belongs and forwards the call to the user's device or phone number.
This forwarding can be done in two ways:
SIP: The company's app will receive the call. Data will travel over Wi-Fi or mobile data. The company's server will 'call' the app. Hushed does this.
Good old telephony: The company's server will forward (this is called 'termination') the call to the telephony network. Very big company may have their own connections into the telephony network, but often they have a contract with a termination party. Sideline does this, but seems to only call your mobile number. NumberBay goes much further allowing you to register all your mobile and fixed-line phone numbers in the app. You can select, per virtual number, which phone number you want NumberBay to forward the calls to.
Let me know if you need more technical details.
My work wants to test their new modems using an iPhone app. We can use a current app or build a brand new one. Third party apps are OK but want to avoid jailbreaking if possible.
We want an app which connects to the network and monitors certain parameters for a set amount of time. We will log attributes from the network and modem. We already know it's possible to test speed, disconnections, reconnection time etc. Some of the parameters we need to track might be more secure or outside Apple's regulations.
These are the responses we are looking for:
Frequency (ie. 2462MHz)
Channel Bandwidth (ie. 20MHz, 40MHz)
Radio Type (ie. 802.11a,b,g,n,ac)
802.11 Deauth Reason code
802.11 Association Status code
How can we track the above attributes using an iOS app?
Are there any apps out there that can track this information? Does iOS have anything for tracking these parameters?
Thanks so much!!
After successful purchase I save receipt+transactionID into NSUserDefaults. Same information is sent to server to keep a record.
Later(on demand) when user want to download content from my own server, my app will send receipt+transactionID to server. It will find stored receipt by transaction ID sent from app, verify both stored and new receipts with Apple. If some of the keys matched then provide downloadable content.
However, nowadays it's not hard to get hold of NSUserDefaults and extract receipt+transactionID. Even if I place information in keychain, it's possible to capture receipt from internet connection.
Now if someone will have receipt+transactionID, can send a request to my server and get content from any PC. How can I patch this logic without using cryptography?
Although you can patch your logic to make it harder to break, if you want real protection you need some kind of cryptography. You do not need to apply it explicitly - something as mainstream as switching from HTTP to HTTPS will often do the trick.
The three places where you need to protect your sensitive data are on the device, on the server, and in transit.
To protect the data on the device, store it in the Keychain: after all, storing small chunks of sensitive data is the main purpose of adding Keychain to the array of storage possibilities on iOS.
Server protection is a large topic that has been treated in numerous online and offline publications; for the purpose of this answer I assume that your server is adequately secured.
What is left is protection of your data in transit between the device and the server, and between your server and the Apple's server. You can use HTTPS for achieving transport-level protection.
Note that adding all these levels of protection does not make your data absolutely secure: an entity with a lot of time and resources (e.g. a government of an unfriendly country) could potentially discover your keys - for example, by disassembling the physical device, and inspecting the data coming out of the CPU with a logic analyzer. However, the point of this exercise is not to achieve the absolute protection, but to make it prohibitively expensive to break your security scheme. To that end, a combination of Keychain and HTTPS should achieve the goal of making it more expensive to break your protection than to buy your content legally.