50p 2017

Paying via Credit/Debit cards (or NetBanking) one huge leaky cauldron on mobile apps.
We have a new food delivery or clothing merchandise startup popping up every day, and those enormous discounts pull you into making purchases from them from the get go.
But when you put in your payment details in your random built-in-a-month startup-level-amateurly built app, you have no clue how many people are seeing your secure payment method details.

Outline

How are payments in mobile apps integrated these days :

• A startup builds an app (which doesn’t have basic security measures, saves keys in unencrypted flatfiles)
• They need to add payments wihtin 2 days . . so let’s use an SDK - Razorpay/Paytm/Zaakpay etc
• Use the SDK like a black box, just feeding it an API key
• The SDK uses a payment method like Freecharge/PayU/Paytm
• The Payment Wallet uses a payment fullfilment service like Juspay, Citrus
• That uses a bank gateway like ICICI/Citibank
• Oh wait, where does the app run ? Android.
• OEM has access to Android base classes and the runtime. Most OEMs are known to spy on users, some have virii.
• User’s phone could be rooted, have xPosed installed, could be using a VPN.

The list just goes on, for all the places from where the details could leak. The OEM can sniff any text entered or displayed in an app.If not the OEM, on a rooted app, anyone else can reflect into your Java classes and sniff data. The SDK can monitor the payment details. The payment fullfilment service works via a Webview, and they can too.
How compromised are we exactly when we pay using our cards/netbanking when buying that delicious chicken wrap from the latest food startup’s app ?

Speaker bio

Arnav teaches Android and NodeJS at a programming bootcamp, Coding Blocks, in Delhi. He has been an avid Web and Android developer for over 5 years now, with contributions to many FOSS projects like Arduino IDE, CyanogenMod, the Linux kernel and even Google’s vanilla Android OS Project (AOSP).

Slides

http://cb.lk/50pdecks