4 ms·
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 atta
by mikestew 2y ago
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?
- ellisv 2y agoToken ABCD is associated to the card number 0123 on the bank's backend.
- kemotep 2y agoBut 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.
- stavros 2y agoThey mean a subscription, you cancel your card and get a new one, but the attacker's fraudulent subscription continues on the new card.
- kemotep 2y agoThe 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.
- stavros 2y agoI don't know if it's lag, I think it's prioritizing the business' recurring revenue over the consumer's control.
- figassis 2y agoWhat 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.
- matthewarkin 2y agoTokens 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.