Will Google Wallet ID Give Thieves Access To More Cards?

Security wasn't Google's top priority when it came up with its new architecture for Google Wallet. Mainly, the Android-maker wants customers to actually start making mobile payments with it. But by replacing actual payment-card numbers on the phone with a Wallet ID that looks exactly like a payment-card number to processors, Google has raised some new security questions that so far don't have clear answers.

For example, what happens if a thief manages to scoop up that Wallet ID? Could that give him access to all a customer's payment cards?

Here's how that problem could play out. Google speaks of extensive security around the Wallet ID, which is housed in the secure element. But if a cyber thief was able to access that ID, could that thief insert it into a legitimate Google Wallet download and, in effect, take over the identity of the victim shopper?

Fraud protection

The hole here speaks to how fraud protection is typically done today. When a processor or a card brand detects suspicious transactions, the customer is contacted (or, if the charges look serious enough, the card is immediately suspended). If it's fraudulent, the card is shut down. But there's no current mechanism for shutting down all of a shopper's cards. So if someone has taken over the full Wallet, one deactivated card would not slow the thief down beyond the split second the Wallet takes to move on to the next card on file.

Cyber thieves live for that window. They know, calculated to the minute, how long they can use a card before fraud will likely be detected. That's why they often use stolen cards to purchase gift cards, to slow down the trail.

In short, this means that every Wallet ID could be worth three to five cards (however many are stored in that victim's wallet). As a practical matter, the secure element is indeed the safest place to store such data. Cracking into it would be extremely difficult, but isn't that what's been said before every major cyber attack into what had been considered uncrackable vaults? The Wallets could also be cloned, but that has its own drawbacks.

Under the new architecture that Google unveiled on August 1, card numbers will be pulled out of a mobile phone's NFC Secure Element and will now be stored on Google servers. (Google calls this a cloud approach, but that's just buzzword bingo; it's the same way Amazon's 1-Click works, and what online retailers have been doing for more than a decade.)

What's stored in the phone now will be a 16-digit Wallet ID, which looks to retailers and processors exactly like a card number issued by a bank named Google. Transactions are routed to Google, which charges the appropriate payment card attached to the customer's Google Wallet account, and then sends the transaction authorization back to the processor and retailer. Google also separately sends a receipt to the customer's phone.(If this sounds annoyingly familiar, it's a lot like one of the ways we outlined in June for Apple to use its cache of 400 million customer payment-card numbers to make mobile payments "just work" on the iPhone.)

What this means for retailers

For retailers, that means no further POS hardware or software changes are required for the revamp, either for the 25 chains that have already modified their POS to handle Google Wallet deals and coupons or for any other retailers that only accept contactless cards.

Google can't currently collect line-item detail, but that's coming, said Robin Dua, head of product management for Google Wallet. Google will also apparently be the merchant of record for transactions. As for security and PCI, the new Google Wallet will use all the same EMV security and meet all the same PCI requirements as before.

"Many retailers have really dabbled in this whole contactless area," Dua said. "Retailers have not had a major incentive to address those customer issues and to invest in signage and that sort of thing. The dynamics are now going to shift dynamically."

In other words, Dua is admitting that most haven't promoted either Google Wallet or generic contactless payments with in-store signage or customer encouragement by associates or with any meaningful employee training. "They have that incentive now."

Well, maybe. There are far more contactless cards out there than Google-Wallet-enabled devices, and that fact hasn't moved either retailers or customers to use them.

The other obvious benefit to Google is that it can now add customers' payment-card numbers at will on its servers. It turns out that the plan of getting thousands of banks to go through a months-long process to become capable of installing a customer's payment card inside an NFC Secure Element wasn't working for Google or the banks.

The process of provisioning cards over the air to the mobile device's secure element took "six months to one year," Dua said, adding that, given the huge number of players involved, "This would literally take a lifetime."

Dua also offered a small dig at ISIS, pointing out that Google is not charging issuers to get their cards in the Wallet, something that ISIS is doing, he said.

Whether the big expansion in issuing banks and card brands will actually jumpstart Google Wallet usage among customers remains to be seen. Wallet mobile payments are still supported by only a handful of phones and Google's new Nexus 7 tablet. Dua insists that Google is still committed to phones for its primary platform. But if lots of customers start showing up waving tablets at POS devices, we can be pretty sure Google misjudged its market.

Security risks

A bigger question is whether Google has misjudged its security. That Wallet ID is effectively the key that unlocks as many payment cards as a customer has registered with Google. Suppose a retailer or processor is breached, and a thief steals that Wallet ID along with a collection of other payment-card numbers. What then?

Google refused to talk about specific security details, but we can walk through the process. If card numbers are scooped up in a breach, the usual course of action for a thief is to put the numbers on magstripe cards or use them online. That shouldn't work with the Wallet ID.

Google knows it doesn't issue magstripe cards, so it should reject any transactions that don't look like they came from contactless cards. And it's not clear whether Google Wallet users will even know what their Wallet IDs are—there's no reason it shouldn't be completely internal to Google—so cases where the Wallet ID number is used online should be rejected, too.

And—presuming Google has its security act together—any such attempt should flag Google that the Wallet ID has been stolen, which should in turn both flag a breach for a retailer somewhere (although no one will know for sure where) and trigger a notification to the user that his phone's Wallet ID has been breached and that his real cards might be at risk. (Yes, Google will have to explain to those users that Google doesn't know what retailer or processor was breached, or when, or how, just that there must have been a breach and it wasn't Google's fault. Welcome to the world of breaches.)

Of course, these days professional card thieves increasingly sort card numbers, so they know which ones are PIN debit (prized because they can be converted to cash directly at ATMs) and what banks issued them. Google Wallet IDs will probably be discarded by the professionals as not worth the effort, because figuring out how to load the number on a contactless card, or else mimic an NFC-enabled phone running Google Wallet, would require a lot of work just to add a few more card numbers to the stash.

Then again, the challenge of out-thinking Google might actually attract some hackers with security obsessions and too much time on their hands. If that happens, we may get definitive answers to how secure the new architecture is—even if Google doesn't like it.