Loophole in digital wallet security even if rightful cardholder doesn’t use one | Hacker News Reader

Loophole in digital wallet security even if rightful cardholder doesn’t use one

techxplore.com

15 pointsPaulHoule24 comments

It's funny how the main initial problems listed in the article don't exist in the EU.

When adding my cards (from different banks) to Google Pay, I had to authorise it via my bank's app (as all online payments, as per PSD2).

When my card expires, all subscriptions using it contact me to update it. Including Google Pay the wallet. If I don't, they stop working. I would assume the same would apply to lost/stolen cards.

So, US banking and most importantly, banking regulators, just need to follow the EU's lead. Banking here is around a decade ahead of the US.

Part of it in the current credit card system with high fees, banks can afford to eat a lot of fraud so they really don't care.

If margins were small, say 0.1% it would be necessary to defeat fraud by technical measures to a much higher degree than today.

With recurring payments being such a theme I think the system needs to change such that your credit card web site has a list of all your recurring payments and you ought to have one place to go to cancel subscriptions with a consistent interface.

> Part of it in the current credit card system with high fees, banks can afford to eat a lot of fraud so they really don't care.

You're saying the banks don't want to fix fraud because they just make me pay for it?

Uhm, who did you think pays for it?

Well, I'm in the EU, so nobody, because the fee cap forced the banks to fix this, which is my entire point. I didn't "think" anything.

They mostly make the merchants pay for it (if you're not otherwise paying interest or annual fees), and some merchants will pass that cost on to you.

Merchants make all their money from customers, so all costs are always passed on to customers. Nobody cuts their margins.

Very few, if any of those costs are passed along as a direct surcharge like small stores do with card payments.

You guessed it right, the EU has a cap on card fees (0.2% for debit, 0.3% for credit).

Came here after reading the article to say that I don't have the issues described in the article, and you have bet me too it (In the UK here).

> First, there is the issue of the initial authentication. "Any malicious actor who knows the [physical] card number can pretend to be the cardholder," says Raza. "The digital wallet does not have sufficient mechanism to authenticate whether the card user is the cardholder or not." He emphasizes that existing authentication methods can easily be bypassed.

When adding my physical card to Apple Pay, I had to auth my card being added with my bank via the banking app. (I also had a message in my "recent activity" section of my banking app that the card had been added to Apple Pay).

> Another issue is that, once a victim reports their card stolen, the banks only block transactions from a physical card, not ones made through a digital wallet. Banks assume that their authentication system has sufficient security to prevent attackers from adding someone else's card to their wallet, which, as Raza points out, is not the case.

My bank offers Virtual Cards, which I can use online via the "virtual" PAN issued or add the virtual card to Apple pay and use that to pay in store. Personally I found this more convenient with budgeting than using my physical card, so I choose to use my banks "Freeze Card" option on my physical card because honestly I only use it once in a blue moon, so might as well "freeze" it, just in case I misplace the wallet I keep it in and use virtual card(s) in Apple Pay IRL. The second I froze the physical card in the banking app I got a notification from Apple Pay telling me that card was no longer usable as a payment method. (The same would happen if I lost the card, its just that my banks process for reporting a card lost/stolen involves you freezing the card first)

So IMO, its not an issue with "digital wallet security", but how card issuers handle that security.

> So IMO, its not an issue with "digital wallet security", but how card issuers handle that security

And mostly that unless forced by regulations, companies will more often than not do the bare minimum at the expense of consumers.

I've been thinking about this and there might be ways to do it without regulations.

The "big gun" without regulation would be if the likes of Apple and Google (and/or Visa / MasterCard) telling the card issuers that they have to use these security standards. But in my "ideal world" I don't like giving Visa/MC even more "power", however in this case at least it would be kicking the card issuers and not the consumer (same could be said for Apple/Google)

The other way would be to hit the US card issuers in their pocket via class action that they were not using these security practices which could have protected customers from fraud.

But yeah you are right, until external forces (be it the card networks, digital wallets, lawsuits, the feds, etc) make entities do the "right thing" they will often just do the bare minimum.

Apologies for the long quote from TFA, but I’m obviously missing something:

“Here is a fictional example: The victim's credit card number ends in 0123. An attacker adds 0123 to their digital wallet and starts making purchases. Again, digital wallets work by sending a virtual number to the vendor, so vendors receive the virtual number ABCD and take this number to the bank to get payment associated with account 0123.

The victim discovers the fraudulent payments and asks the bank to issue a new credit card. The bank sends a new card with the number 4567 and, on the back end, remaps the virtual number: ABCD no longer links to 0123, it now links to 4567. The wallet automatically starts showing the new card to its user without any verification for the new card to be updated in the wallet. Vendors then go to the bank with ABCD, which has now been linked to 4567, the new and active number, and the purchase goes through.”

TFA seems to have left out the “…and then the attacker does…” part. Because now the token ABCD is disassociated with card number 0123, and 0123 should no longer work, right?

Token ABCD is associated to the card number 0123 on the bank's backend.

But from the article and the quote it says that after a new card is issued, the code ABCD (which 0123 generates in the digital wallet) is actually associated with the new card number on the backend.

I think that the article is trying to say is that the digital wallet automatically updates to the new card with no additional authentication mechanism? That’s the vulnerability here, if I understand correctly. Once an attacker can associate a stolen card with a digital wallet, the victim can cancel that card and get a new one issued but the attacker still retains access because purchases are done with the virtual token which is mapped on the backend. As long as you have the right virtual token, the bank will map that to the correct account.

Like this is a serious issue with digital wallets if true. The advice at the end of the article is key then:

> turn on email notifications when a card is added/removed from the wallet, turn on transaction alerts for credit cards, regularly check credit card statements and review devices linked to credit cards through the bank's web portal or mobile app account settings.

They mean a subscription, you cancel your card and get a new one, but the attacker's fraudulent subscription continues on the new card.

The bank issuing a new card absolutely should kill all ongoing transactions and require them to be updated. Only an attacker with persistent access would be able to do that if all previously authorized transactions are prevented from completing using outdated information. It’s a real shame the US lags in this.

I don't know if it's lag, I think it's prioritizing the business' recurring revenue over the consumer's control.

What happens here is something called “account updater” that banks and networks use to notify payment providers that the customer has changed their card, and send information about the new card, so Google Pay would then link their token with the new card and the existing subscriptions continue uninterrupted. Likely there should be a way for the customer to opt out of this, but I don’t think there is. I implemented this integration with JPMC once and this all happens automatically via direct integrations between issuer and payment provider.

Tokens are mapped to the underlying account not to a specific card. This is one of the selling points of network tokenization to merchants. If the underlying card gets lost/stolen/replaced/etc, the token will still work because it is tied to the account and not the physical card.

Ugh. Digital wallets are unbelievably nice. Almost at the point where taking an actual wallet places is completely unnecessary and that feels very nice. Sucks to see issues like this regarding them. Hopefully this gets patched asap.

Interesting and infuriating "loophole" that I'd call negligence, with respect to stolen cards.

Apparently, the banks do not dissociate a stolen card in a digital wallet from your account so someone can steal a card, put it in a wallet and keep using it merrily.

Sounds like a basic thing to get right, but I am sure there are "good" reasons.

I've had to simply cancel a credit card stolen this way, but using an Amazon Integration.

It was an "Amazon Credit Card" and both Chase and Amazon claimed the other was responsible for deauthorizing the card on Amazon, Every time Chase re-issued it they updated the connection with my ex's Amazon account, giving them access to the new card to continue abusing.

My only options were to cancel the card or file a police report.

It smelled like a situation where they had setup fully trusted automation to keep the two in sync, but didn't have a customer service path to stop that automation or insight into the other company's side of it.

My take away is if my physical card number is stolen, I should report it to the issuer and also ask them to disassociate the card from any digital wallets.

Reply on news.ycombinator.com