We’re developing a mobile app (iOS and Android) for a client which has its own payment processing solution. The app is public-facing, and will be used by individual consumers on their own phones.
The app has to interface with the payment processing solution over a SOAP API. We need to accept the input of the user’s payment card details, and pass them across that API. We don’t have the option of embedding their website within an iframe, or anything like that; we have to use this specific API, which means that our app will unavoidably have to (briefly) possess and process the user’s payment card details.
All the app needs to do is to collect the details (by having the user tap them in on the phone’s keyboard), send them across the API, and then discard them as quickly as it possibly can. It won’t store the data beyond the time taken to complete the transaction, and it won’t send the data anywhere except across the API to the client’s server. We will never have the data on our own servers, we will be careful never to write it into logs, and generally we will be treating it like radioactive waste for the brief period it’s in the app’s possession.
We can safely assume (at least for now) that the client’s systems already do whatever they need to do with regard to PCI DSS. And of course the traffic between the app and the payment server is encrypted.
We’re struggling to get to grips with what we need to do regarding PCI DSS, and we’d appreciate any pointers to help us get started. We’re perfectly happy to (indeed want to) use a consultant to help us achieve compliance – but we don’t really even know who we’d talk to. Everything we can easily find online (including material from the PCI itself) seems to relate to subtly different scenarios, or advises us to sidestep the problem by using something like an iframe, which isn’t an option for us.
To be honest, we’re surprised by how hard it’s proving to find some clear pointers. Lots of apps do process card details! This surely must be a common problem.
So, our questions:
Where should we go to get expert advice relevant to our particular scenario?
Completely informally, and on the understanding that we are going to get properly qualified advice later… how much of a nightmare should we expect this to be? We’ve got to the point of wondering whether we need to worry about key loggers installed on the phone. Is that really the case, or are we going too far?
Is there a magic bullet we’re missing – a library that’s already known to be compliant, for example?
I am a PCI QSA.
Like a lot of things with PCI there are several gray areas in the scenario. You can ask 10 QSAs the same question and will likely get 10 different answers, which is a sad reality of the lack of clear guidance around such scenarios (and there are many oddball scenarios).
So, in my professional opinion (I said opinion), a mobile app where 100% of the card ingestion, processing and transmission is handled on the mobile device AND the cards used on said mobile device belongs to a single user, the risk is very low. If I read the question right, you are the app developer. You are not the merchant, and if all you are doing is writing the code for some merchant or service provider, this problem sits more with them.
They will likely need to have an application penetration test performed and some traffic analysis to confirm the cardholder data flows straight from the device to the acquirer (the processor). You as the software developer are not on the hook for anything PCI, unless you are selling this app on the App Store or some such way. In that case, the above answer is more accurate. You would likely need to put this application through a PA-DSS review with a PA-QSA. Assuming it passes, it would be listed on the PCI SSC website under PA-DSS validated applications. This does not make the processor PCI compliant, but it can help with the assessment process.
As for the magic bullet, there is nothing. However, if you use Stripe as the processor and their mobile SDK to handle and transmit the cardholder data, then Stripe will assume the PCI responsibility after you complete a short questionnaire on their website each year.
I realize this question is pretty old, but I thought the answer could help someone downstream struggling with this issue. Also, I have no connection with Stripe, but I recently encountered this problem and was surprised to see how Stripe handles it. Pleasantly surprised I might add.
I don't think the above replies answer the question accurately. I would urge anyone who needs information specifically about mobile application development and PCI to read the following, taken from the Security Standard Councils documentation:
If the consumer is also the cardholder and is using the device solely for his/her own cardholder data entry, and the application can only be used by that cardholder using his own credentials, then the device is treated similarly to a cardholder’s payment card: The consumer’s environment in which the application runs is outside the scope of PCI DSS, and the consumer-facing application is not eligible for PA-DSS listing.
and this:...
PCI SSC agreed (see PA-DSS and Mobile Applications FAQs) that mobile payment-acceptance applications that qualify, as Category 3 will not be considered for PA-DSS validation until the development of appropriate standards to ensure that such applications are capable of supporting a merchant’s PCI DSS compliance. The PCI SSC recommends that mobile payment-acceptance applications that fit into Category 3 be developed using PA-DSS requirements and the guidance provided in this document as a baseline.
Read the last paragraph of page 2 and first paragraph of page 3. In a nutshell, at this point (17 Sep 2019) there is no validation for PCI compliance for mobile applications - only recommendations and guidance from the Security Standards Council.
I feel your pain, you'd think with something as ubiquitous as taking credit card details there would be a wealth of clear concise information to help you guide you through the process, sadly not the case.
For your first question you need to find a QSA, check out the PCI council website for a list of those and all the official information. I would recommend shopping around a bit, quality and pricing does vary, you'll want someone familiar with your scenario. As you say you should get official guidance before using the views I provide.
For your second question, the first thing to say is PCI is contract based. It's completely your client's responsibility (depending on the agreement they have with their merchant bank or payment processor). So if your contract doesn't say you need to provide a PCI compliant solution, you don't have to...though I would be careful this could be a matter for the lawyers if you've implied it or fit purpose etc. Pragmatically there's a few options depending on the situation, it gets a little tricky here so i'll try my best:
If the client has no control over the code or the system, they just receive the results of it, you'd likely be considered a service provider and you would need SAQ D for service providers at the minimum.
If you just give the client the source code and they implement, then they are fully responsible for, they would have to do code reviews, penetration testing etc etc if that's in scope.
If your client want's to plug your app into their system, and they don't want to be responsible for the PCI details of it then you would need to be PA-DSS compliant.
Ultimately it'll depend on what PCI scope your client can take on, they will likely need SAQ A at the very minimum (yes you may both need to prove PCI compliance), regardless of what course you take.
In terms of the nightmare, I'm not sure for native apps but for web apps if the PAN (cc number) touches your server it's full scope, SAQ D, in a nutshell yes that's a nightmare if you don't already have a secure setup. The best scenario would be SAQ A, but you would need a iFrame for that, if that's not possible then perhaps SAQ A-EP, you can use that with a direct POST so might be ok with the SOAP interface if that is directly from your app. I'm not sure if an app is considered 'e-commerce' which can use SAQ A and A-EP, if not you may need SAQ C. Take a look at requirement 6 at least, it covers software development.
For your last question, check out spreedly.com, they provide a PCI compliant connection to multiple gateways may be useful.
Good luck! And it'd be great to hear what you eventually decided to do.
This FAQ may help: https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/If-a-merchant-develops-an-application-that-runs-on-a-consumer-s-device-e-g-smartphone-tablet-or-laptop-that-is-used-to-accept-payment-card-data-what-are-the-merchant-s-obligations-regarding-PCI-DSS-and-PA-DSS-for-that-application?q=mobile&l=en_US&fs=Search&
This basically says that you are just responsible for following a "Secure Software Development Lifecycle", with such controls outlined in Req 6.3, 6.4, & 6.5.
Related
I am looking to build a mobile app that will send 100 mb of data per instance to a "cloud" system where the data will be manipulated, machine learning models applied to it (not built upon), then the summarised data should be sent back to the users phone. I have written much of my scripts on my local machine and now I need to begin to deploy it. Both in terms of deploying in the cloud, and in app development, I have no experience.
I initially planned to run this all on GCP. However loading models is a bit of a challenge. Whilst working through this, someone suggested that perhaps what I need is a VPS. Initial views suggest yes a VPS could host my data and do my processing for me and a significant cost reduction. However, GCP has the benefit of having Firebase linked to it, and so there is then the question of how I could set up the VPS to receive the data and send it back out to the app.
I know that this is very generic and please ask me more questions so I can clarify as far as I can. My challenge is how to get started in this whole area which I do not have experience in. Links to relevant tutorials / courses which would help me on this path, would be of great help.
In terms of size and frequency of my set up:
One push of data is approximately 100mb. The data sent back will be much less (currently undefined but its summary statistics)
This will then happen up to 5 times per week, and I would hope for 5000-10000 customers
Appreciate any help and hints you can give me, and if this is deemed inappropriate because its not specific enough, could you advise where I could seek the help I am after.
Thank you,
James
You can use Google Compute Engine to create a VM for hosting your app.
To get started, you can create a GCP account which is provided with a credit and follow this quickstart guide to see how it works.
As for the additional resources to help you become familiar with the platform, I can recommend GCE tutorials and Quicklabs.
First things first, I am writing this question after researching quite a bit.
Broader View of the issue
In this day and age, we require a more reliable way to perform peer-to-peer communication, preferably using technologies like NFC.
I mean we are in the year 2018 and I cannot believe that there isn't reliable means to communicate peer-peer between and ios and an android. I am talking about offline, close proximity/range communication, which can open up a new world of possibilities for mobile apps. Many of the apps we use to communicate with other devices require one or more of internet, login, credentials/authentication, etc. I am making this effort because most of the readers/users/developers do not actually know what has changed in 2018, so if anythings changed, I would love to hear it!
Hindrances
IOS has very weak NFC support, functionality-wise..?
IOS doesn't support Android Beam.
Not enough members are bothered to fix this or are helpless.
IOS doesn't support non-ios Bluetooth connection? (Doubt it/Tried but failed)
What I need
Efficient cross platform solution for communication between two different mobile devices preferably offline.
A way to send and receive money other than Apple Pay/GPay/Samsung Pay/iMessage/AndroidMessages, such as over NFC/Bluetooth preferably offline mutually, but connected to internet independently.
A way to automatically send data when two devices (different platforms and within ios) are in close proximity, without the need to login or register or any other steps. At least a way to trigger something upon nearing one device from the other, like NFC basically.
What I have
Working android application that uses android Beam to send and receive ndef messages, which is easy to do, between two android devices. So we can make the payment happen here in this case.
Questions arise when we try to proceed with android -> ios or vice versa.
I have read a lot of related questions where the answer is outright NO. However, am not taking time to write this question to be told it's not possible. I want the crowd here on stack overflow to help me find a way to workaround this situation. I know it is a lot to ask, but I feel this invention or discovery will help man app developers stuck in this same zone. This question should be answerable by someone who is ideally in the Fintech domain, and is an IOS developer or mobile developer, with working knowledge of card emulation, secure element, ios 11+ or ios 12 development, NFC, NFC tags, etc.
Questions/Ideas:
Can we use the secure element and NFC Tag with ios 12 or ios 11+ libraries to simulate this required functionality?
Does any third-party library get close to having the ios/iphone act like a NFC writer?
Can we simulate NFC writer for ios?
Can I simulate a tag on android device, have the iphone read it(do not want the apple pay popup somehow) and then follow through the next workflow via the internet? For example, if I had a sender and receiver (payments), since android supports a lot more than ios, can I simulate something on android so that either the apple pay thinks am a terminal of sorts and pays me electronically (securely of course), or at the least can I read apple pay credentials of sorts and simulate a terminal and accept a payment from ios on android?
Something on these lines, I know its not very clear, though I am trying to be clear and simple.
Suggested by others and why it is not a great solution:
WebRTC - Needs internet
alljoyn - Need only 2 device not 2+ and no need for server or client setup.
Relay Server not quite sure is offline or works
android-ios-peer-to-peer-architecture question talks a lot about it as well!
developing-mobile-p2p-payment-apps question, which seems to be relevant has NO answer.
why-android-ios11-cannot-communicate-via-nfc question talks about React Native. I for one have looked at PhoneGap and Nativescript which just have the same level of support for ios. In short, it won't work.
Any I left out, in short no solution.
Comments:
//Due to the fact that there is no solution, I feel even more motivated to post this question. I feel we should come together as one and fight for this right. I mean usually seemingly impossible questions are answered here, so I figured you guys could take this as a challenge. The challenge would be to find a legal loophole, an ethical approach, nothing unethical of sorts. So let me know if we can arrive at any positive conclusion! Thank you for being patient.
//I have read the rules and "do not ask" section, so I would just request moderators to check if there *can* be any answer before you flag it or take it down, by which I mean we just need one correct answer, and it can come from anyone or anywhere.
I am pleased to reveal that there has been demand for this and Google has released Nearby API as early as 2016. This is the way to move forward. This is a device independent API.
Please checkout Monzo Bank's Nearby Pay
Google and others claim it works with Ios as well.
It has been around since 2-3 years, which means there should be good support and documentation, though I might be wrong.
I hope this answer paves the way for others in my position! Good Luck!
What opportunities are there for regular app developers (with that I mean, you're not a million dollar content producing company or distribution channel provider, but a regular, small app development company) to secure video/audio content for the app from being saved/distributed.
I mention the 'regular developer', because I had seen in the Android core code that Sony had added some code portions into it, in the DRM packages. Let's assume we're not that powerful to talk to Google to include such in their core code.
Are there any real secure ways to protect video/audio (as part of an app) on Android.
Assumptions (correct me if I'm wrong):
devices could be rooted by the users, need to be aware of that
detection whether a device is rooted or not (within an app) is not really possible on Android, as a super user can basically fake any state of the device.
we cannot modify any hardware or the user's system (meaning: we don't bundle our app product with a device, the app should be available as a 'regular' app on the App Market for download)
the media files/stream could be locally on the device or come remotely from a server, both is ok
I have researched this topic quite a bit, googled a lot, went through (hopefully) all related questions here on SO, I have talked to one DRM provider (which is really hard to get in touch with as a small company or freelance developer, or at least to get some real relevant information, technical docs and details).
I looked into DRM as one approach, but "security-by-obscurity" does not seem to be a very good way. Besides, I haven't found any information or real solutions/APIs for regular developers.
Public-key encryption was another idea, but where to store the private key really safely? Furthermore, I assume that in such case, the entire media framework & player would need to be rewritten, in order to pass a secure video stream to the player. Or am I mistaken?
I would like to get some opinions from other experienced developers in the field, as it's really hard to find information about media content protection for Android anywhere.
Update:
In the context of my question, I found this Question and it's update interesting: Streaming to the Android MediaPlayer
Are there any real secure ways to protect video/audio (as part of an app) on Android.
If by "secure", you mean "fullproof", then no. See Analog hole.
detection whether a device is rooted or not (within an app) is not really possible on Android
Nor is it possible anywhere. the laws of the universe make it impossible to detect such a thing, (okay, maybe you could exploit quantum physics for this, but even then I'm not sure) you can only add code to detect known techniques, all of which are trivial to bypass.
Public-key encryption was another idea, but where to store the private key really safely?
There is nowhere to store it safely. Think about it, you want to encrypt content and give the user the key to decrypt it (so he can watch it), but you don't want him to be able to decrypt it (so he can't copy it). This is a contradiction.
The most you can do is encrypt your stream to prevent the user from being able to just intercept it and use it. Then obfuscate the code that decodes/plays the stream. Though by implementing that you risk introducing more bugs (and worse performance), making the legitimate user's experience worse. If decide not to roll your own obfuscation, and use some automatic obfuscater product already available by some big company, it will already be generically cracked, and it will be extremely easy for someone who hardly knows what he's doing to crack your product in a small amount of time. As long as your product becomes remotely popular, one person is going to crack it and upload all the videos to torrent, then everyone will be able to pirate your product without doing any work.
I don't think there is a solution to protect media content in apps from being ripped off. DRM is of course not suitable for regular developer. I don't see also why public key can help.
I have a customer requirement to provide some proprietary business logic in a market licensed application. I've been reading up on Android services and I'm wondering what the best way to do that is. Is it possible to provide a local service through the Android market? It seems the customer would need source code to interact with a local service.
I am a .Net developer, fairly new to the Android world so I apologize if this is a routine question for the seasoned Android developer, but I've searched through other questions and haven't come up with the exact answer I'm looking for.
It's probably worth noting that although we are somewhat concerned about the possibility of de-compilation of this code to acquire the business logic, we believe we have enough back end server capability to protect us for the foreseeable future.
Thanks,
Lance
There is no requirement for an Android “app” (.apk) to actually contain any user interface. There's even a category in Android Market for such things. You can sell your component and have other apps provide the actual UI.
To provide complex services to another application, you define a bound service. You may need to provide some source code defining the interface for communication, to enable others to use your interfaces, but you will certainly not need to provide any of the “interesting” parts of your source code.
We continue to build our fairly small applications on Android, iPhone and other mobile operating systems. This is fine and fun in the beginning of a new era, but when mobile OS matures, gets to be the preferred device for business people in motion, they want something more.
One would guess they want the same access and capability to ERP, MRP, BI-solutions and other reporting systems in there phone, right here, right now. How would we as developers deliver these demands, in a secure yet useful way? Is there today support for this kind of applications given they are not today on the web?
EDIT: I understand the fact most EIS-solutions are web based. Still they are behind company gates, heavily garded by Cheif Information Security Officer (CISO) and his/her staff. Thus they are not accessible through the open unsecure internet but insede companies intranet or internal network. To my knowledge, accessing an EIS using an adress like https://www.thecompany.com/eis-solution/ signing in with username/password isn't done today. In the old days, a VPN-solution was one way to access inside EIS-solutions, but will this be done using a mobile device as well?
I cannot understand what distinction you are making. Oracle Financials -- for example -- is a web-based application. It requires username and password. It can be run in a "portal".
Most companies (even very small ones) use the Web-based deployment through Virtual Private Networks.
ERP, MRP, Financial and BI applications
Are web-based.
Are trivially available from mobile devices.
The vendors are starting to include appropriate changes for the small screen.
"business people in motion" have complete access to all web-based applications. All a company needs to do is (a) purchase or (b) convert their applications to the web.
And Oracle, IBM, CA, HP, SAP and many others have already made many of their applications web-enabled.