Evan Schuman's StorefrontBacktalk

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 a 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 cyberthief 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?

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.

Cyberthieves 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 giftcards, 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 cyberattack 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.