Sunday, March 8, 2015

Repairing the Apple Pay Vulnerability

The Apple Pay architecture works; financial institution (FI) validation of its users once again fails miserably. FI must protect all their customers better and Apple Pay users far better. There is no excuse for retail FI to continue to live in the stone ages. There is no excuse for FI not evolving with continuously changing attacks on accounts in their care. The FI approach: “this vault worked for our founders and we will not change it now” is bankrupt. FI need to continuously review their security posture and create architectures that evolve with attacks or everyone will pay increased fees to cover FI unnecessary losses.

The Apple Pay vulnerability allows thieves to enter stolen payment card data to use as payment. FI receive an initial request to validate the user of the payment card data. FI need to improve their validation techniques for this preliminary non-financial transaction and use these techniques for all their varied cardholders, regardless of the payment initiation methods they use. 
At a minimum if FI customers plan to use a personal electronic device (PED), then the FI needs to send a text message or an email to their customer on receipt of a validation request. If the card holder does not respond appropriately to the validation request within reasonable time then the FI denies the validation request. FI cardholders with greater value at risk need better protection. FI should store a picture taken while the customer is present in the FI and compare it to the same picture stored in the customer’s PED during the initial validation of  payment card data stored on a PED.

These techniques in today’s  Wild West require that Apple and its competitors create standards for validation of cardholders and the PED applications. Once again greed prevents the development of standards to protect the paying public so FI fees increase to cover preventable losses. Government cannot create laws to protect users from FI incompetence without creating significant greater costs to FI. Perhaps a patchwork of differing FI techniques to validate its users will serve until the techniques becomes routine and therefore non-proprietary and therefore ripe for a standard.

Regardless of the uniformity of approach, FI, and financial application developers need to consider vulnerability posture before releasing payment solutions to the paying public. Whether the validation request comes from Samsung Pay, Apple Pay, or Google Pay, FI need to prove the request comes from their customer and not an impostor. FI know how to compare data from a transmission to one stored on their processing platform. FI know how to create response transmissions. FI know how to set a timer to expire if there is no response from a cardholder. Knowledge is worthless however if FI continue to think that a physical vault protects their customers from attack.

Next Blog: Removing the Security Standard Development Obstacles

No comments:

Post a Comment