Back to the future – QR codes are coming

QR codes are coming

Who’d have thought that the humble barcode – reimagined in 3D – would have posed a genuine threat to the global behemoths that are the international card payments schemes?  And, of all the times, why now? Well, as always, there’s no single answer. We’re seeing multiple trends coalescing to drive uptake of QR code initiated payments, but the announcement by PayPal that they’re rolling their solution out to all CVS stores is perhaps a critical moment:

PayPal and InComm on Thursday (July 30) unveiled a QR code payment system that will enable touchless checkouts by PayPal and Venmo users with their mobile phones at brick-and-mortar stores.

Paypal teams up with CVS to offer touch-free payments

It’s not so much that it makes QR codes mainstream, it’s more that it validates the point that they’re a perfectly viable way of making in-store payments, and then tying it to a e-comm type payment method: now that’s replicable. Four things are coming together to drive the adoption of QR codes:

  1. Smartphones: The widespread availability of smartphones makes them a perfect solution for retail payments. If everyone has one then creating a pervasive alternative to card payments is possible.
  2. Connectivity: In fact it’s not absolutely necessary to always have mobile data connectivity to allow QR code based payments, but I helps managing the risk. And even where mobile data isn’t available a lot of mainstream retail chains are providing in store WiFi or Bluetooth capability.
  3. COVID-19: Suddenly contact-free payments are the way to go – and QR Code initiated payments are a guaranteed way of ensuring that payments can be made without touching merchant equipment.
  4. Integrated retail experiences – “omnichannel”: Merchants with a good omnichannel experience are having a better crisis because the ability to order and pay on one channel and fulfil on another is critical. Increasingly merchant POS estates have API based access to backend systems which can be used to access QR code authorisation or approval channels.

The pay-by-app model, we’ve been touting for years is actually, finally, coming to fruition. Lots of individual merchants – and probably every major supermarket chain in the world – has its own app that allows QR code based payments. Those apps allow a range of other functions to be integrated, including scanning, checkout, automated loyalty redemption and real-time customer data analytics.  The ability to make the customer relationship sticky is attractive and with the average supermarket basket value increasing as customers shop bigger and less often ensuring that you’re the retail destination of choice is critical.

Behind this, however, is another change – and one that the PayPal deal with CVS lays bare. There is nothing that forces one of these QR code initiated payment apps to use payment cards as the means of transaction. Sure, they’ll be there as a backup but any API-based payment solution – and there are hundreds, if not thousands – can be integrated. As direct to account payment APIs, such as the PSD2 payment initiation API that’s mandated in Europe, become more widespread, it will be possible to go direct to the payment account in order to authorise payments.

This trend has other, major implications for other aspects of payments such as settlement and refunds but, as we can see from our own clients, a lot of thought and effort is going into resolving those issues. For retailers who can see lower cost of payments, reduced fraud, significant reductions in the cost of handling chargebacks and faster settlement this is a win-win-win-win situation.

As you might surmise, here at Consult Hyperion, we are heavily involved in all aspects of this change. From helping to develop and secure the apps, to advising on the business and governance models, through to designing and developing the solutions, and providing regulatory advice. We’re leaders in the field. If you’re interested come back to the future with us, QR codes are coming…

Is your mobile banking app exposed by someone else’s software?

This post was written in collaboration with Neal Michie, Director, Product Management, Verimatrix.

Banks are facing massive disruption and change from many directions. The rise of app-only banks has made the need for traditional banks to have compelling app services an imperative. Banks have of course been building mobile apps for several years. If not already, they will soon be the most important channel for engaging with and serving customers. However, mobile banking apps will also become the primary focus of hackers, intent on getting access to other people’s information and money.

How have mobile banking apps evolved?

From lightweight apps supporting basic banking functions they have now evolved into full service branches including all manner of sophisticated features such as biometric identification, payments, loyalty and personal finance management driven by data science and machine learning.

Some of the things you might expect to find feature rich mobile apps include:

  • Numerous APIs supporting the large number of features – creating a large attack surface through API Abuse.
  • A mixture of native code, managed and web-code – providing different levels of control over how sensitive data is handled.
  • Dozens of dependencies on third party SDKs and libraries – each outside of the direct control of the bank.
  • Hundreds of thousands of lines of code – making isolating and auditing critical security functionality very difficult.
  • Use of WebViews to render web-code – providing great flexibility but making the app more reliant on external services for its security.

Third-party components are a particular issue

The use of third-party components may expose banks to new security risks. If these risks are not carefully managed and the customer data is compromised, then banks risk regulatory fines and reputation damage, not to mention the inconvenience and worry caused to customers.

To give you an idea of the size of the issue – third-party components can provide all manner of functions such as remote user monitoring, instrumentation, error and crash reporting, profiling, binding the user to the device, analytics, cryptography, UI enhancing, financial charts and many more. Components may be proprietary or open source code. They are integrated into the app where they may gather or process data and connect to third-party backend servers that may or may not be under the control of the bank.

The risk isn’t just theoretical. The well-publicised attack on British Airways breached the airline through known vulnerabilities in third party code. The business risk: a fine equivalent to 1.9% of revenue and long-term reputation harm – we are still talking about it 2 years later.

While not exhaustive, some of main security issues to watch out for include:

  • Auditing: Banks may not have access to the source code of proprietary third-party SDKs and libraries. This makes the task of ensuring that the software is safe much more difficult. Penetration testing techniques can be used to monitor the behaviour of the component, but this is no substitute for a source code review.
  • Deployment model: Often third-party components need to connect to the third-party backend services. Sometimes those backend services have to be operated by the third party. Other times it may be possible to bring those backend services in-house. Obviously bringing them in-house gives more control to the bank to ensure any sensitive data stays within their infrastructure. Where this is not possible, then the bank may unwittingly introduce a “data processor” in GDPR terms into their service without the necessary oversight.
  • Known vulnerabilities: Third party components may in turn utilise various other proprietary or open source libraries. Some of these dependencies may have known vulnerabilities which leave the bank app exposed.
  • Potential information disclosure in transit: Third party SDKs may not have adequate transport security enabled. For instance, no or weak TLS certificate pinning may be implemented, making any communication between mobile apps and the backend susceptible to man-in-the-middle attacks. This can potentially leak sensitive information in transit.
  • Potential information disclosure at rest: Third party SDKs may gather and handle sensitive customer or bank information, and this may be cached in the persistent storage without encryption or without being cleared from memory after use. A backup of the device/app can potentially expose sensitive information if not adequately protected.
  • Potential information disclosure due to misconfiguration: Backend service endpoints necessarily allow connections from the mobile apps. If these are misconfigured, then they may potentially leak sensitive information. A recent example was the exposure of personal data by Google Firebase. Data exposed included email addresses, usernames, passwords, phone numbers, full names, GPS information, IP addresses and street addresses.

How can we mitigate the identified security risks?

  • Risk Assessment: A risk assessment of third-party components will help to determine whether using “black box” components is acceptable. Consult Hyperion’s Structured Risk Assessment (SRA) methodology is designed for just this, ensuring that technical decisions have the right business context.
  • Code review and penetration testing: Source code review and penetration testing should be a standard process in any bank, employed for every release. Banks should go beyond the use of automated scanning and analysis tools. These may help in catching common issues but will not cover everything. For third party components, the options available could include reverse engineering (which is costly) or dynamic testing, where the behaviour of the component and its external communications are monitored real-time as it is used.
  • Tamper detection and integrity protection: Banks should also utilise tamper and integrity protection to protect code and builds – often known as App Shielding or In-App Protection. This should cover the integration of any third-party components where possible – either separately or as a whole. By anchoring third party libraries and obfuscating their boundaries, vulnerabilities become much hard to find and exploit. This additional layer of security can safeguard mobile banking apps and provide security assurance against reverse engineering and runtime hacks.

Conclusion

Protecting the personal and financial information of customers is a fundamental responsibility of banks. Doing so in mobile banking apps is more important than ever. The use of third-party components makes this more challenging. The contract a bank has with a third party may only provide very limited protection when things go wrong and it will certainly not cover the detrimental risk of losing customer trust and business. Great care is needed therefore, when choosing, integrating and deploying third party components.  On the other hand, third party components allow banks to provide their customers with better services quicker, so it is imperative that they employ best practice to ensure they serve their customers well, maintaining their trust.

About the Co-Author
Neal Michie

Neal Michie serves as Director of Product Management for Verimatrix‘s award-winning code protection solutions. Helping countless organisations instil trust in their IoT and mobile applications, Neal oversees Verimatrix’s foundational security products that are relied upon by some of the world’s largest organisations. He champions the need to position security as a top-notch concern for IoT companies, seeking to elevate code protection to new heights by serving as a sales enabler and brand protector. Neal brings more than 18 years of software development experience and spent the last decade building highly secure software solutions, including the first to be fully certified by both Mastercard and Visa. A graduate of Heriot-Watt University with an advanced degree in electrical and electronics engineering, Neal is an active and enthusiastic participant in Mobey’s expert groups.

Leveraging the payment networks for immunity passports

COVID-19

As if lockdown were not bad enough, many of us are now faced with spending the next year with children unable to spend their Gap Year travelling the more exotic parts of the world. The traditional jobs within the entertainment and leisure sectors that could keep them busy, and paid for their travel, are no longer available. The opportunity to spend time with elderly relatives depends on the results of their last COVID-19 test.

I recognize that we are a lucky family to have such ‘problems’. However, they are representative of the issues we all face as we work hard to bring our families, companies and organizations out of lockdown. When can we open up our facilities to our employees, customers and visitors? What protection should we offer those employees that must or choose to work away from home? What is the impact of the CEO travelling abroad to meet new employees or customers, sign that large deal or deliver the keynote at that trade fair in Las Vegas?

It is no longer unusual for a company in the City to regularly test its employees before allowing them to work in their offices and support the additional costs of their commute avoiding public transport.

Billions are being invested in vaccine research and tests to confirm that we have the antibodies to protect us and those with whom we interact. But will that be sufficient? Will it allow you to visit your relatives in the care home, sit inside your favorite restaurant, work in close proximity to your colleagues and/or travel without the need to quarantine for 14 days when you arrive and/or return?

Experience would suggest that over the next year or so a variety of vaccinations and tests will be released, which will work to a greater or lesser extent. The question will be: ‘is the vaccination, or test, recognized by the venue (and their insurers), or country, which you are trying to enter?’

For some organizations, the fact that the COVID-19 tracing application on your phone turns green, will be sufficient. Others will only recognize specific vaccinations and tests and will want to check that the immunizations are still valid. Both will be concerned by the availability of fake immunity certificates. Thus, in parallel with the medical developments, we have to implement a robust and efficient method of sharing and remotely validating the immunity certificates or passports that they will deliver.

Those of us who regularly travel in North Africa and South America are used to handing over our yellow International Certificate of Vaccination or Prophylaxis (ICVP), with our passport, to prove that we had yellow fever vaccine. This program, which is governed by International Health Regulations, could provide the governance framework for the operation of the COVID-19 immunity passports.

Over the last few months, Consult Hyperion has proven that the contactless payment networks, which allow you to use your credit or debit card anywhere in the world, can also be used to share and remotely validate your COVID-19 immunity passport.

Our idea is that anywhere you can use your payment card you can also validate that you have the required immunity to enter the building or country. As with your payment transaction, an organization can choose whether or not to accept your immunity passport based on the:

  • Issuer of the immunity passport
  • Vaccinations and/or tests administered
  • Date when the vaccinations and/or tests were administered
  • Potential that the passport is a fake or you are not the genuine passport holder

If required, the organization can also revert to the issuer of the immunity passport to check there and then that your passport is still valid.

The consumer experience delivered by the immunity passport is similar to that of a contactless, Apple Pay or Google Pay transaction. The immunity passport is stored in a secure application in your smartphone or biometric smartcard. When asked to prove your Immunity Status you use your fingerprint to authenticate yourself to your phone/card and then touch your phone/card to a contactless reader. An application on the reader validates your immunity passport and passes only the required information to the restaurateur, owner of the care home or office or border control officer.

From the international community’s perspective, the payment infrastructure over which the immunity passports are shared and remotely validated is in place, proven and robust. It is supported by a raft of rules administered by PCI, which protect the security of personal information, at rest and in flight, within the system. There is an active marketplace for cheap, certified readers, operating secure protocols, which offer Contact Free validation of the immunity passport away from the classical point of sale locations. These include mPOS and SoftPOS solutions which allow a standard mobile phone to be used as a contactless payment terminal, and ruggedized terminals used to validate tickets in high traffic areas, such as the entrance to sports arenas and concert venues.

While the world waits to see if the science supports the ability to establish immunity to COVID-19, and society works through the implications of immune people being able to avoid restrictions which apply to others, we technologists need to prepare the infrastructure that will allow people to share and validate immunity passports.

One of the things I love about working at Consult Hyperion is that we regularly come up with, and deliver, ideas that significantly impact people’s lives – contact and contactless payment cards (worldwide), M-PESA (Kenya), Open Loop Transit Ticketing (London) and more recently SoftPOS (London), just to mention a few. Something tells me that immunity passports will be the next. If you are interested and would like to help deliver the network that will allow life to return to something close to ‘old normal’, please let me know.


Subscribe to our newsletter

You have successfully subscribed to the newsletter

There was an error while trying to send your request. Please try again.

By accepting the Terms, you consent to Consult Hyperion communicating with you regarding our events, reports and services through our regular newsletter. You can unsubscribe anytime through our newsletters or by emailing us.