Cashless india hero

Table of Contents

Introduction
About the Cashless India Initiative
How Will Mobile Play a Significant Role in the Cashless India Initiative?
The Role of Mobile in Global Cashless Economies
Popular Methods for Conducting Mobile Cashless Transactions
Security Challenges for Mobile Cashless Transactions
Best Practices for Writing Secure Code for Mobile Apps
Conclusion
About the Author
References

Introduction


India is one of the largest markets for smartphones and mobile apps, which is why local brands are changing their strategy from mobile-also to mobile-first. Banks and payment gateways will soon follow the same approach for their cashless transactions, and mobile will play a big role towards the Government of India’s “Cashless India” initiative — a major step towards making India a digitally empowered and cashless economy. In this white paper, we will explore the role of mobile in Indian and global cashless economies, identify ways to conduct cashless transactions, address potential security challenges, and discuss best practices for writing secure code for mobile apps.

Back to Table of Contents

 

About the Cashless India Initiative


Digital India is the flagship programme of the Government of India. It was launched on 1st July 2015 by Prime Minister Narendra Modi, with a vision to transform India into a digitally empowered society and knowledge economy. “Faceless, Paperless, Cashless” is one of the professed roles of Digital India. Major progress towards this goal was made in late 2016, when the  government took steps to demonetize the country. Now, even small retailers and shop owners are using cashless models like Paytm for transactions.

A cashless economy is one in which all transactions are made using credit/debit cards or digital devices (e.g., point-of-sales machines, digital wallets, etc.), and the circulation of liquid money or paper currency is minimal. In this economy, a third-party such as the government or a public/private sector bank possesses an individual’s money and can circulate that money whenever it is not needed by the individual.

Cashless transactions

Merits Of A Cashless Economy

Some of the merits of a cashless economy are listed below, going through these you will realise how significant this initiative is and how it will shape the Indian economy in a positive way.

  1. It boost the economy because the cost of making and handling paper money is quite high.
  2. It reduces the terrorist activities, as most of the terrorist activities are fueled by the black money in hard cash.
  3. This aids the environment, as no trees are cut for printing of paper money.
  4. Reduction in crime rates. Crimes with financial motives are rare in cashless economy. An instance of this has been seen in Delhi recently when the government pulled out high value notes.
  5. It is the medicine for fake money problem. No cash simply means no fake cash.
  6. Adherence to labour laws can be achieved, as now labours will be paid in their bank accounts.

Demerits Of A Cashless Economy

Every initiative has a lop side also, some of the demerits of cashless economy with respective to India are given below. In the later part of this article we will talk in detail about the challenges related to cyber security, individual’s financial data, and online banking fraud which a cashless economy can face.

  1. No cash in hand. Always a dependency on your card or bank system connectivity.
  2. Major part of Indian population is not educated about banking systems, specifically about the digital aspect of it. Hence they may resist to make online transactions.
  3. Automation and online transactions will cut down large number of jobs.
  4. India is dominated by small retailers and they don’t have enough resources to invest in electronic payments.
  5. Increase in cyber crimes and online banking frauds.  

Back to Table of Contents

 

How Will Mobile Play a Significant Role in the Cashless India Initiative?

India has shown a rapid growth in the smartphone market worldwide, with around 27.5 million devices sold in the second quarter of 2016, up by 17 percent from the previous quarter (according to IDC). This growth in sales is paralleled by an equally enormous growth in the number of mobile internet users in India. According to a report by the Internet And Mobile Association of India, India was estimated to have 371 million mobile internet users as of June 2016. As per the recent study on the Growth of the Indian Mobile App Market, application downloads in India increased from 1.56 billion in 2012 to 9 billion in 2015. It also says that smartphone users in India have the highest smartphone usage rates globally, with an average of 3 hours spent on their devices (for comparison, the average time spent on mobile phone by users in the US is 132 minutes). These numbers tell us that smartphones and mobile apps are already getting into the DNA of the Indian population.

It is impossible to imagine a life today without smartphones. Mobile apps assist us in every aspect of our daily routines, from communication and navigation to shopping and entertainment. Taking a cue from this market trend, big brands are moving from mobile-also to mobile-first strategies around their products and services. For example, brands like Quikr, Olx, Uber, and Flipkart now advertise their presence on mobile devices first. As such, we can assume that mobile will take a front seat when it comes to implementing initiatives like Cashless India.

Banks and payment gateway companies have already started leveraging mobile networks as a channel for extending their existing payment infrastructure because of the reach and easy of access that mobile offers. Paytm wallet, India’s largest mobile payment service platform, has over 150 million wallets and 75 million Android-based app downloads as of late 2016. The app enables users to buy air and movie tickets, book taxis, recharge their mobile devices, pay various bills, purchase fuel at petrol pumps, and even shop at small retailers and neighbourhood shops.

Transactions

Furthermore, the Government of India’s additional initiatives like Mobile Seva and reward schemes like Lucky Grahak Yojana and Digi Dhan Vyapar Yojana are supplementing the use of mobile in a cashless economy. Mobile Seva provides a fully operational mobile payment gateway, incorporating various channels for making electronic payments through mobile devices. Government departments and agencies can integrate the gateway with their applications, so that citizens and businesses can make payments for various government services through their mobile devices.

Launched in late 2016, Lucky Grahak Yojana distributes daily and weekly rewards to thousands of retail consumers. Similarly, Digi Dhan Vyapar Yojana distributes weekly rewards to thousands of small businesses. To qualify for these rewards, applicants must make digital payments through a Unified Payment Interface (UPI), RuPay, the Aadhaar Enabled Payment System (AEPS), or an Unstructured Supplementary Service Data (USSD). These initiatives have boosted confidence in digital mediums for payment services and will likely lead to increased private sector mobile payment services, as well.

Back to Table of Contents

 

The Role of Mobile in Global Cashless Economies


Let’s take a look at how other countries are leveraging mobile to create cashless economies.

Kenya

Kenya’s M-Pesa, a mobile banking service, allows customers of the mobile phone operator Safaricom to hold cash balances that are recorded on their SIM cards. Cash may be deposited or withdrawn from M-Pesa accounts at Safaricom retail outlets located throughout the country, and they may be transferred electronically from person to person as well as used to pay bills. Here’s how it works:

  • The M-Pesa agent network consists of a multitude of small shop owners and retailers.
  • A customer pays the agent cash, and the agent loads the customer’s phone with virtual credit, often referred to as “cash-in.”
  • The credit can then be transferred to another mobile for either purchasing goods or sending money to friends or family.
  • The process of sending payments is similar to sending a text or SMS message.
  • A recipient can choose to either store the virtual cash on their phone or go to an agent, who exchanges the text message code for the physical cash (“cash-out”).

M-Pesa statistics are incredible, with 21.8 million registered M-Pesa users in Kenya making payments person-to-person (KSh 106 billion), person-to-business (KSh 23.5 billion), and business-to-person (KSh 27.8 billion) per month (according to Safaricom). In fact, Economist Intelligent Unit reports that the transactions that flow through M-Pesa amount to 60% of the country’s GDP!

Cashless Kenya
http://www.gsma.com/mobilefordevelopment/wp-content/uploads/2013/07/MMU-Infographic-The-Kenyan-journey-to-digital-financial-inclusion.pdf

China

Alipay is a third-party online payment platform that was launched in China in 2004 by Alibaba Group. It is supported by Alibaba, Taobao, Tmall, and an increasing number of independent online stores. Here’s how it works:

  • The buyer chooses a product and pays the seller via Alipay.
  • Instead of transferring the money to the seller’s Alipay account immediately, Alipay keeps the money as escrow and informs the seller that the buyer has made the payment. At this time, the money is neither directly controlled by the buyer nor the seller.
  • The seller sends the product to the buyer.
  • Upon receiving the product, the buyer confirms receipt in their Taobao or Alipay account.
  • Once Alipay receives the buyer’s confirmation, it sends the money to the seller.

According to an analyst research report, Alipay has the biggest market share in China with 400 million users. As of late 2016, it controlled just under half of China’s online payment market. According to Credit Suisse, the total value of online transactions in China grew from an insignificant size in 2008 to around RMB 4 trillion (US $660 billion) in 2012.

Alipay1

Alipay2
http://consultclub-iima.com/?tag=alipay

USA

Now let’s look at how a developed country like the USA is adopting mobile financial services. According to the Federal Reserve Bank’s report on Consumers and Mobile Financial Services 2016:

  • 43% of all mobile phone owners with a bank account used mobile banking between March 2015 – 2016.
  • 53% of smartphone owners with a bank account used mobile banking between March 2015 – 2016.
  • Consistent with previous years, the three most common mobile banking activities among mobile banking users were:
    • Checking account balance or recent transactions (94%)
    • Transferring money between individual’s own accounts (58%)
    • Receiving alerts (e.g., text message, push notifications, e-mail) from their bank (56%)
  • 24% of mobile phone owners reported having made a mobile payment between March 2015 – 2016.
  • The three most common mobile payment activities among mobile payments users with smartphones were:
    • Paying bills through a mobile phone web browser or app (65%)
    • Purchasing a physical item or digital content remotely using a mobile phone (42%)
    • Paying for something in a store using a mobile phone (33%)
Usa
https://www.federalreserve.gov/econresdata/consumers-and-mobile-financial-services-report-201603.pdf

Back to Table of Contents

Popular Methods for Conducting Mobile Cashless Transactions

Cashless transactions via mobile, commonly referred to as “mobile payments,” are generally defined as payment services operated under financial regulation and performed via a mobile device. Thus, instead of paying with cash, cheque, or credit card, a consumer can use a mobile phone to pay for services or goods. Although this concept has been in place for a long time, it is only recently that the technology needed to support such a system has become widely available. There are numerous enablers in the mobile payment space, the most popular of these models of mobile payments are described below.

Payment types

Mobile Wallets

Mobile Wallets enable consumers to make 1-click payments via a mobile phone because the user’s card information has already been stored securely in the cloud. In this model, a consumer only has to enter their credit card information once. Some of the major players in this space include PayTM, Apple Pay, Android Pay or Google Wallet, Paypal, Samsung Pay, Square Wallet, and Capital One Wallet.

Mobile Banking Apps

Most of the larger banks offer mobile banking apps on popular mobile platforms like iOS, Android, Windows Phone, etc. In addition to enabling consumers to view their balance and transaction history, transfer money between accounts, and make credit card payments, these apps also allow consumers to pay their utility bills and generate One-Time-Password (OTP) for some online purchases. These apps also have some useful features like locating banks or ATMs, contacting banking personals, changing PINs, etc.  

Card-Based Payments

In this model, retailers offer a mobile app that integrates with payment gateways (e.g., PayPal, Authorize.net, Securepay, etc.) and enables consumers to enter their credit card details to make purchases. The drawback of this model is that when a consumer has to enter details onto a mobile phone, it can reduce the success rate (conversion) of payments. If a payment vendor can automatically (and securely) recall a consumer’s card information, it provides the customer with a simple click-to-buy experience, which increases conversion rates for additional payments. Most of the eCommerce mobile apps support this model.     

Carrier Billing

Consumers can also make purchases on an eCommerce or mobile app using mobile billing, or carrier billing. Based on a two-factor authentication process involving a PIN and an OTP, carrier billing charges purchases to the consumer’s account (i.e., the carrier pays the charges and passes along the charges to the consumer’s next mobile service bill). Since carrier billing does not involve credit/debit cards or even pre-registering a consumer’s banking details with an online payment vendor like PayPal, it is a true alternative payment method (and very prevalent in Asia).

Contactless / Near Field Communications (NFC)

With contactless payment, a consumer inputs their credit card information into their smartphone (e.g., Apple Pay), where it is securely stored on the embedded smart chip for future use. When the consumer wants to make a purchase at a store, they simply hold up their phone to the mobile payment reader at the point-of-sales (POS) terminal. The smart chip on the consumer’s phone connects to an antenna, and the POS terminal emits a high-frequency radio wave that facilitates communications between the reader and the phone. When the phone is in range, a wireless communication protocol links the terminal and the phone, which exchange information and conduct a secure transaction. All of this occurs in a fraction of a second.

Near field communication (NFC) technology works by bringing together two electronic devices, typically a mobile device such as a smartphone and a reader of some kind. NFC always involves one initiator that generates an RF field to power a passive target. In terms of payment technology, the reader is the initiator and the smartphone (which contains the credit card information) is the target.

Back to Table of Contents

 

Security Challenges for Mobile Cashless Transactions


There are a number of vulnerabilities in mobile cashless transactions that can be exploited by hackers and result in the denial or theft of services for consumers, as well as the loss of revenue, brand reputation, and customer base for vendors. In this section, we will identify some of these vulnerabilities and explain how mobile app developers and end user/customers can prevent their sensitive personal information and transactions from being hacked. In the next section, we will focus on how developers can further prevent these attacks altogether through stronger, more secure code.

Hackin

Insecure Public Wifi

Nobody wants to burn their cellular data when public wifi hotspots are available everywhere, but free public wifi networks are mostly insecure. Unlike your home wifi, which is encrypted with a password (hopefully), public wifi is not. This means you are at a risk from attackers monitoring your online activity, such as texts you sent and websites you logged into.

Wifi uses radio waves, and radio waves are not direct or sent through a secure physical line. They broadcast, which means that anyone within range and with the right network sniffing tools can see what you are doing online. Network sniffing is the process of intercepting data packets sent over a network. Sniffing can be used to capture sensitive data such as login credentials, eavesdrop on chat messages, capture files transferred, intercept and modify requests (man-in-the-middle attack), etc. To avoid such attacks, you should always use OpenSSL, which is provided by most of the websites — including Google, Facebook, and most bank sites. You will know OpenSSL is enabled when the website URL has HTTPS (versus HTTP).

Another security threat from public wifi is the possibility of having your phone infected if someone else on the same public network has a malware on their phones. To prevent such threats, you should have good malware protection installed on your phone.

To be safe, use free wifi sparingly on your mobile devices, and never use it to access confidential or personal services (e.g., banking or credit card information). Moveover, you should only connect to the known public wifis and always verify the name of a business’ wifi network before connecting to it.

Developers: You should not allow invalid certificates. Instead, use SSL certificate pinning and include an additional encryption layer over HTTPS. These measures will ensure that your mobile apps are fully secure, especially if they have mobile payment integration.

Android Repackaging Attack

Android has the biggest market share in terms of mobile operating systems, with more than 95% in market share in 2016 in India. In Android devices, a common security threat is the repackaging attack, in which:

  1. Hackers download the binary of a popular mobile app from app markets
  2. Reverse engineer the app
  3. Modify its code or add some malicious payloads
  4. Upload the modified app to the app market

Often it is very difficult for consumers to tell the difference between the modified app and the original app, as they look and work exactly the same. Furthermore, Android’s signature method allows self-sign, which make it relatively easy to repackage apps. Once a modified app is installed on the consumer’s mobile phone, the malicious code inside the app can conduct attacks, usually in the background.

Developers: To prevent hackers from reverse engineering your mobile app, you should use tools like DexGuard for high-level code obfuscation. You can also add security measures like verifying the application signed certificate in code upon app launch.

Interception of OTA Transmission

Hackers can also intercept data traffic when it is transmitted over the air (OTA) between a phone and a POS terminal, resulting in security issues like identity theft, information disclosure, and replay attacks.

Developers: Countermeasures include (1) only establishing connections with trusted platforms, (2) using secure protocols for connections, and (3) implementing an additional layer of encryption over the secure connection protocols.

Malicious Third-Party Apps

Carelessly installing malicious third-party apps on your mobile phone and providing elevated access rights to them may result into sensitive information disclosure and loss or corruption of file system and system resources. Thus you should only install apps from trusted hosting platforms and websites, and you should carefully read the app’s instructions before installing it and granting it permissions.

Absence of Multifactor Authentication

Simple password- or PIN-based authentication does not stand a chance against the technological advancements in attacking methods. As CPU processing speeds increase, brute force attacks have become a real threat. Developments like GPGPU password cracking and rainbow tables have provided many advances for attackers. GPGPU cracking can produce more than 500,000,000 passwords per second, even on lower-end gaming hardware. Similarly, rainbow tables can crack 14-character alphanumeric passwords in about 160 seconds.

Using weak passwords or PINs further empowers such attacks, which is why vendors are increasingly using multi-factor authentication schemes that require more than one identity credential. Multifactor authentication combines two or more independent credentials, such as what the user knows (i.e., password or PIN), what the user has (i.e., security token) and what the user is (i.e., biometric verification). The goal of multi-factor authentication is to create a layered defence and make it more difficult for attackers to perform an unauthorized access.

Lost, Stolen, or Resold Mobile Devices

Mobile devices are small and handy, and we carry them with us everywhere. This makes them vulnerable to theft and loss, which in turn leaves sensitive personal or corporate data open to exploitation. And if you sell your phone without first wiping it, you risk selling all of that information, too.

Once an attacker get access to a lost, stolen, or unwiped mobile device, they can jailbreak it or make it rooted, which in turn compromises the security layer at the OS level. If your application is running on a phone that is jailbroken, then it can compromise your personal data and the security of your overall system in a number of ways. Even iOS, which is very popular for its security capabilities, can be exploited in a number of ways when jailbroken:

  1. The keychain in an iOS device is a secure storage container that can be used to store sensitive information like usernames, passwords, and tokens. Apple itself uses the keychain to store wifi passwords, VPN credentials, email credentials, etc. But on a jailbroken iOS device, a keychain_dumper tool can be used to extract all the information from your phone’s keychain.
  2. If an attacker accesses the source code of your mobile application, they can discover security lops in it. If the attacker has a jailbroken iOS device and the target iOS app is running on it, they don’t need to access the actual source code because they can just use tools like class-dump, clutch and cycript to decypher and perform a runtime analysis of the target app’s source code. They can also use techniques like method swizzling to manipulate the target app’s code at runtime.    

To defend against such security threats, consumers should always remote wipe your lost or stolen mobile device to completely erase its data. Application developers should (1) include a jailbreak/rooted detection code in their apps to prevent attackers from accessing their critical features, and (2) implement an additional layer of security before storing data even in the mobile OS’s secure storage keychain.

Hole in WebView Container Approach for Hybrid Apps

Although most modern web browsers prevent certain vulnerabilities such as malicious scripts or cross-domain requests, hybrid applications use UIWebview (iOS) or WebView (Android). These are native controls that use WebKit engines and do not offer the same level of support as a browser does. Hence, there can be certain vulnerabilities that your hybrid application can face, such as attacks through holes on the WebView access control mechanism.

This attack is possible through WebView’s addJavaScriptInterface API, which enables a web application’s JavaScript code to invoke the Android application’s Java code (similar implementation is available for iOS, as well). Allowing apps to bind an interface to WebView fundamentally changes the security of browsers — specifically, it breaks the sandbox model adopted by all browsers. Because of the risk of running untrusted JavaScript programs inside the browser, all browsers implement an access control mechanism called a sandbox to contain the behaviour of these programs. The sandbox basically achieves two objectives: (1) isolate web pages from the system and (2) isolate the web pages of one origin from those of another origin. The second objective mainly enforces the Same-Origin Policy (SOP).

When an application uses addJavascriptInterface to attach an interface to WebView, it breaks the browser’s sandbox isolation, essentially creating holes in the sandbox. Through these holes, JavaScript programs are allowed to access system resources such as files, databases, camera, contact, locations, etc. Once an interface is registered to WebView through addJavascriptInterface, it becomes global. All pages loaded in the WebView can call this interface and access the same data maintained by the interface. This makes it possible for web pages from one origin to affect those from others, defeating SOP.

Developers: Developers can prevent this attack by (1) making sure no sensitive data is maintained in the class implementing the JavascriptInterface and (2) having proper input parameter validations in the function calls of the class implementing the JavascriptInterface.

Malicious Access to Session Token

Tokens are used by many apps to perform multiple transactions without having to re-authenticate users for a specific amount of time or for a limited number of transactions (called a “session”). Since these transactions can involve sensitive information, a token should remain confidential.

Improper session handling occurs when an app unintentionally shares such session tokens with malicious actors through hacking, thus allowing them to impersonate legitimate users. To avoid such threats, a session token must be kept encrypted within a device’s memory and should only be shared with the user’s server module over a secure communication channel.

In the next section, we explain how developers can keep tokens confidential and encrypted by using best practices to write secure code for mobile apps.

Back to Table of Contents

 

Best Practices for Writing Secure Code for Mobile Apps  

As we have discussed, mobile devices face many security challenges and threats, especially when it comes to financial transactions and handling personal sensitive data. Furthermore, hackers often tap vulnerabilities or bugs in the design and code of mobile applications. In this section, we will explore what mobile app developers can do to remove such vulnerabilities and make their cashless transaction apps more secure.

Security

Use Hardware Level Security For Sensitive Data

Speed and power efficiency are critical for mobile devices. Cryptographic operations are complex and can impact a mobile device’s performance and battery life if not designed and implemented properly. As such, mobile devices come with hardware encryption features that are both fast and more secure.

iOS devices have a dedicated Advanced Encryption Standard (AES) 256-bit crypto engine built into the DRM path between the flash storage and the main system memory, making file encryption highly efficient. This engine works with the SHA-1 cryptographic hash function, which is also implemented in the hardware to reduce the overhead of cryptographic operations.

In hardware encryption, the AES 256-bit key is fused into the crypto engine to make it more secure. Thus building encryption into the physical architecture makes it faster and more reliable to encrypt data stored on iOS devices. Android phones also support such hardware encryption engines, depending on the manufacturer (e.g., Nexus devices have been encrypted by default).

Since hardware security varies for different platforms, developers should refer to a platform’s unique API guidelines to better understand how to leverage its built-in hardware security measures.

Only Store PINS in User’s Memory

A PIN or password should be used a generate the encryption keys at runtime, but they should never be saved in the app. As we have seen in the previous sections, even the most secured storage like the iOS keychain can be hacked. Hence you data is never safe unless it is guarded by something that is not present on your phone at all, like the PIN that is only in user’s memory.

For this you have to make sure that all your sensitive data is encrypted using an encryption key, and this key should only be generated based on some confidential algorithm that takes a PIN as the input. Only when a user enters a valid PIN will the sensitive data be retrieved in a valid form; otherwise, the data will be retrieved in an invalid form. If a hacker accesses your phone, retrieves your stored sensitive data, and reengineers your app code, they will not be able to understand the data that they retrieve.

Encryption Key Should Be A Function Of User PIN

One of the best ways to ensure that your encryption key is secure is to make it a function of the user PIN and not save the PIN anywhere on the phone. With other encryption key generation methods, there is a chance of it being compromised. Here are some example scenarios:

  1. If your encryption key is hardcoded in the code, or if it is generated at runtime with some confidential runtime routine, a hacker can reengineer your app code from its binary.
  2. If your encryption key is stored in some secure storage like the iOS keychain, then it can be hacked as explained in the previous section.
  3. If you receive your encryption key from the server over the network using an HTTP or HTTPS connection, then it can also be compromised by network sniffing attacks.

Your encryption key is most secured if it only exists when a user enters their PIN. This way, it will be cleaned when the app is closed or it it goes to the background, in which case the app will again prompt the user to enter their PIN.

Use HTTPS Instead Of HTTP

Hypertext Transfer Protocol Secure (HTTPS) is a more secure way to access the web. It’s a combination of two different protocols: Hypertext Transfer Protocol (HTTP) and SSL/TLS protocol. It is a more a secure way of sending requests to a server from a client, and the communication is entirely encrypted, meaning no one can know what you are looking for.

HTTPS encryption also defeats sniffing attacks by concealing the traffic’s meaning from everyone except those who know the secret of decrypting it. The traffic remains visible to the sniffer, but it appears as streams of random bytes rather than the plain text form of JSON/XML body, HTML, links, cookies, passwords, etc.

As such, developers must restrain from using HTTP URLs in their apps. The server must enforce the use of HTTPS to prevent unsecure connections from being established.

Consider POST for Sending Sensitive Data Over GET

The HTTP POST method does not expose information via the URL, in contrast with GET, which passes actual information as part of the URL — thus exposing it through server logs, browser history, or caches. Sending sensitive information via GET parameters also makes it easy to alter the data submitted to the server in sniffing attacks. Finally, a third-party can send a link with a malicious GET request, where (as a rule) you cannot email a link that will force a POST request.

Use Separate Channels of Communication for Sensitive Data

System security should not rely on one channel of communication. It is a best practice to use separate channels of communication when sharing sensitive information such as a PIN or password. For example, you can use an HTTPS network connection to share encrypted data between the client and server, and then use APNS/GCM or SMS to share the PIN or token/key with the client app. This way, even if one channel of communication is compromised, the security of the overall system remains intact.

Accept Only Valid SSL Certificates

An SSL certificate from a provider that your app trusts verifies that the website or vendor is who they say they are. Otherwise, anyone could make their own certificate for google.com or thebank.com and pretend to be someone else. For this reason, your HTTPS connection must reject all SSL certificates that are invalid for any reason.

Follow Secure Coding Practices from Respective Platforms

Every platform publishes and promotes the use of an extensive set of secure coding practices and guidelines. Mobile app developers must be aware of and follow these known secure coding practices. More importantly, they should be part of your code review checklist. Some secure coding practices include:

  • Performing input validation
  • Being careful with memory management
  • Not using insecure C functions
  • Avoiding the use of immutable containers when storing sensitive data

(But remember that this list is just a subset of the extensive guidelines provided by the respective platforms.)

Implement Jailbroken/Rooted Device Detection

As mentioned in the previous section, jailbroken and rooted devices are prone to a number of security threats that can compromise a user’s personal or company data in many ways. Some of these threats include:

  • Hackers may engage in brute force attacks on passcodes.
  • A malicious app with privileged access may drain the device’s battery life or destabilize the operating system.
  • Remote attackers may exploit a secure shell server on such a device, get access to your application’s sandbox, and copy sensitive data.

All apps must be able to detect the jailbroken or rooted status of the device and must limit its functionality, erase data completely, or silently notify the authorities.

Verify Data and Files Integrity With Hash

Examining the integrity and authenticity of the data and files transferred between your app and your server can be of great importance to your app’s security. Implementing hash functions can add great value to your app’s integrity, although you should check the files and make sure that you are the communication channel you use to deliver the hash is different than the one you used for the data and files.

Avoid Data Cloning

Backup and restore tools help users copy their device’s complete data and transfer it to different/multiple devices, resulting in the cloning of your app’s data. However, if a user performs a data backup on someone else’s computer and accidentally copies sensitive information such as their banking details, then this process may result in a security threat.

To prevent users from cloning your app’s data, you should generate a unique device fingerprint to encrypt your app’s data. This will render the data useless on other devices, even after backup and restore.

Always Encrypt Data at Rest and Data in Transit

“Data at rest” is the data stored in persistent storage, either on the client side or on the server side. “Data in transit” refers to the data travelling to and from the client and server over the network. Your application data spends most of its time either at rest or in transit, which makes the data extremely vulnerable from a security point of view. Data at rest is saved in local storage, which can be hacked if the mobile device is lost or stolen. Similarly, data in transit can be hacked through insecure public wifi since it is traveling over the network.

Use symmetric and asymmetric algorithms to keep data encrypted when it’s at rest or in transit. HTTPS best practices can be applied to encrypt data in transit, whereas various database encryption techniques can be used to encrypt data at rest.

Sanitize Sensitive Data

To avoid security breaches, sanitize sensitive data using techniques such as:

  • Encrypt sensitive data in memory immediately after use.
  • Do not create multiple copies of sensitive data.
  • Do not create immutable copies of sensitive data.
  • Always create mutable copies; after using them, reset/set zeroes on its memory locations to avoid creating multiple references to sensitive data.

Strip Debug Symbols and Use Obfuscation Options

Stripping debug symbols and using obfuscation options increases code complexity for “bad actors” who are trying to reverse engineer or disassemble your app’s code by making it more difficult to identify and understand sensitive variables, structures, and critical logic/routines. It encrypts or hides hardcoded strings in the code and secures hardcoded server URLs, user names, passwords, and encryption keys.

Another advantage of obfuscation is size reduction, as long descriptive identifiers can be changed into small, one-character identifiers with ease. A good obfuscator such as DexGuard for Android apps can also remove unused code and provides many other code-shortening features.

Beware of the Background State

On most mobile platforms, apps either stay in the background (i.e., in a suspended or frozen state), or they stay live. Even when an app goes into the background, it may still hold sensitive data in its memory or show a screenshot of the app UI in its display buffer. To avoid security breaches, make sure you erase or encrypt any data still in the app’s memory when it goes into the background, and erase the display buffer for any sensitive UI design views (e.g., password/PIN shown on screen).

Disable Auto Correction and Copy/Paste

A device’s auto correction cache holds the data for autocomplete suggestions. These autocorrection caches are common on mobile devices and are shared across apps by the OS in order to learn user behavior and make autocomplete suggestions smarter. Although this is a useful feature from a user perspective, it may create a security threat when enabled, giving access to sensitive data entry views.

Along similar lines, copy/paste also represents a security threat to sensitive data. Attackers can use the paste function to access the sensitive data that was copied from the UI view (which represents sensitive data in the UI of your application). For example, allowing copying operations on a view displaying tokens, one time passwords (OTP), or passcodes from the app screen may comprise them.

Since UI views are used to acquire sensitive data entry from users or display data, keep autocorrection and copy/paste disabled in text fields, text input, labels, etc.

Disable Logs in Release Builds

Debug logs reveal a lot of information about your app, such as its:

  • Interaction with servers
  • Critical routines
  • Storage and retrieval of app data
  • Classes and their interactions
  • Sensitive information (e.g., username, password, API key, tokens, etc.)

This information can be very useful to attackers in reverse engineering your app code and thus compromising users’ sensitive data. Always disable logs in the release build — no exceptions. On most platforms, you have to disable logs explicitly, such as in iOS NSLog, which appears in both debug and release builds unless disabled using a macro.

Back to Table of Contents

 

Conclusion


With the immense usage of mobile in India, it is certain that mobile will play a critical role in initiatives like Cashless India. As such, both private and government banks and financial institutions will soon offer consumers with mobile solutions for cashless transactions and other financial services.

With such a large adoption of mobile for cashless transactions, there will be an equal increase in security threats in the mobile space. In this white paper, we have identified some of these security threats and discussed how to mitigate them as both consumers and developers of mobile solutions. Furthermore, we have explored how mobile app developers can make their solutions even more secure and ready to face any threats that the mobile cashless transaction movement may face in the future.

Back to Table of Contents

 

About the Author


Ajit Singh is a Technical Architect at GlobalLogic who has been working in the mobile space since 2005. During his career, Ajit has helped design and develop mobile solutions for the world’s top telecom operators and mobile companies (e.g., Mitel, Gemalto, Texas Health Resources, Sprint Wireless, Sandisk, MobiTV) by leveraging mobile technologies across the spectrum (e.g., iOS, Android, HTML5, BREW MP). He has immense experience and expertise in the Mobile Security and Embedded Communications domains.  

Back to Table of Contents

 

References

 

Back to Table of Contents