> Savvy attackers may start looking for patterns in the bank identification numbers (BINs) that we issue, and proactively deleting or excluding them from their dumps. For this reason we are in discussions with a number of banks to onboard their BINs to the system too, further mixing in legitimate cards with tokens.
> It’s a compelling argument: “Would you like attackers to first remove your bank’s cards from dumps they steal?”
I've thought about something similar for spam calls: I can play whack-a-mole blocking individual numbers, but it won't scale fast enough and scammers will always get to me. I can rely on iphone's "scam likely" notification and just not answer those, which helps.
If the latter (and whatever similar feature android has) were somehow perfect, scammers would have a bad time. But.. if they convinced (paid) some (more-)legitimate companies to have their outgoing calls show up as the same number as the scammers use, people would eventually learn that they have to pick up scam calls or else miss calls from their bank/pharmacy/whatever.
> if they convinced (paid) some (more-)legitimate companies to have their outgoing calls show up as the same number as the scammers use
In the US the STIR/SHAKEN[1] protocol adds source-verification. If/when this finally gets fully rolled out, spoofing caller ID without it being blocked is going to get much harder.
But, I'm sure the next step for them is to just go after the millions of small-medium business IP telephony systems that are either poorly configured with default/guessable passwords, or have wide-open security holes.
Many canaries are avoidable if you pay perfect attention - but people slip up, and even if they don't, paying perfect attention does increase the cost for the attacker. (And e.g. throwing out all Amex corporate credit cards (one example of the "banks" they use) as you suggest does reduce the value of stolen data too)
