Our last blogs have provided an overview into  what a virtual payment is, as well as an overview into  the major components of the virtual payment (aka mobile wallet) infrastructure.  There is no doubt that there are many moving parts to it, in a way like a car.  If one part of it fails, then it is quite likely you will not be able to proceed with the checkout process with your choice of payment mechanism (whether it is Apple or Google).

But just like anything else, this too is prone to security vulnerabilities and risks, and these  were also examined in depth as well. In today’s blog, we  shift focus and discuss some of the major security related issues which are posed directly to Apple Pay.  Currently, this is the most widely used virtual wallet scheme, and thus, it is important that you be aware of them.  Here we go:

The use of stolen credit cards

As the last article explained in detail how an end user can enroll into the Apple Pay system, there was one big assumption that was being made:  The end user is actually using their own authorized and verified card, not a stolen credit card.

Given the sophistication of the Internet, it is actually pretty easy to steal credit card numbers, especially if the Cyber attacker knows there way around what is the known as the “Dark Web”.  It has been claimed that stolen credit card numbers can be sold here for as high $2.00 apiece.

Thus, the problem becomes entering in a stolen credit card number into an iPhone which is provisioned with a hijacked cell phone number as well. This has been deemed to be even a form of Identity Theft, which has been labelled specifically as “Provisioning”.  There is no doubt that it is easy for a Cyber attacker to enter in a stolen credit card number.

Although the Apple Pay does confirm the identity of the end user as he or she logs into the iPhone, it does not confirm the identity of the end user as they enter in a credit card number.  In other words, although the end user is the legitimate owner of the iPhone, they could also be the “owner” of a stolen credit card number without any questions being asked as they enter it into the Apple Pay.

The primary reason for this is that Apple does not confirm the validity of the credit card number (although it does make use of Encryption and tokens) after it has been processed by Apple Pay; rather they leave that to the issuing banks to accomplish this task.

Although these banks do have specialized Fraud Prevention Protocols in place (which just essentially check for any anomalies), the truth of the matter is that the algorithms which formulate the basis of these protocols need to be completely revamped and fine-tuned in order to keep with the ever-increasing sophistication of the Cyber attacker.

But, the important question to be asked, is just exactly where in the process of confirming the credit card number in Apple Pay is this fraudulent activity set into motion?  It actually occurs at the point where the issuing bank receives the credit card information as well as the information which is relevant to the iTunes account; the general location of the end user, and any relevant links to the banking mobile apps which are installed on that particular iPhone device.

Thus, given the more or less outdated Security features that the issuing banks possess, all the Cyber attacker has to do is hijack this information which is transmitted from Apple Pay to the issuing bank.  Then from there, he or she needs to obtain a new iPhone device, load in the stolen credit card information, and covertly steal the phone number of the person to whom the stolen credit card belongs to.

In the next  blog, we discuss the next major security issue with Apple Pay:  The fake WiFi hotspot.