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.