The fact that the Payment Card Industry association hasn't been pushing this for decades, and it's up to some random infosec nerds to invent it, is yet more evidence that our entire payment infrastructure is fundamentally flawed.
Well to be honest Honey Tokens is being used since beginning of the 2000s, https://en.wikipedia.org/wiki/Honeytoken. I personally implemented them in a Bank, 20 years ago, generating some fake credit cards number (and other information) and having them being monitored in AV, IDS, IPS, Antifraud solutions like browser extensions, google search and etc.. So maybe we can say that I'm a random infosec nerd, but i guess, I'm not the only one, just that people and companies preferred to make it in silence, to actually catch the bad guys out there. We actually were able to catch internal people selling data and we could understand some ways data used to flow and work pretty tight with the Police to intercept and bust criminal groups.
Yeah, trust self important HN commentators like myself248 to imply incompetence throughout an entire industry while being completely ignorant about said industry.
people normally imagine that finance and specially banks, are just COBOL, mainframe and legacy, and even though it is part of their BAU, there are lot of innovation there, specially in the infosec/antifraud segments.
How would the operator of an ecommerce website have gotten their hands on these things to seed their data with them? Is this something they would've known to ask for?
So either you generate some fake but valid credit card numbers (i.e with credit card number generator) and set some monitoring on them or even better, you generate a credit card number with something like revolut, and as soon you get some transaction on that number, you know your database was leaked.. not hard actually to setup something like that.
I wouldn't say this is much of a solution to the problem, though. There's no guarantee that anyone will attempt to use your canary card before they use your actual card. For one-time purchases, a better approach is to generate ephemeral cards that can only be used for a short amount of time, where it doesn't matter if the card gets leaked. And plenty of credit cards do offer this service.
Think about it at the population level: nobody is impervious to theft but it lowers the window for an attacker to quietly steal money considerably and forces them to slow down their activity trying to avoid canaries.
To use a physical security analogy, real world bank robbery is a fool’s game now because of many measures which do not perfectly prevent theft but effectively reduce the profits & odds of avoiding capture. If attackers can’t get enough money to be worth the risk & effort far fewer people are going to try even though it’s still possible.
I'd say this is still putting the burden on the wrong party, though. For this to serve as a useful deterrent in general, canaries need to be quite common. Rather than hoping that thousands of customers will choose to use a canary and monitor individually, any company that stores credit cards should instead contract with an outside auditor, whereby any time a user stores a real credit card in the system, the auditor generates a canary and stores that in the database as well. This way it happens transparently in the backend, without having to ask users to do it, and immediately turns any credential leak into a minefield where you have a 50% chance of getting only one card before a canary goes off.
I don’t think those options are mutually exclusive: merchants should definitely be doing it but note also that many of the scenarios are things where you might want to verify your personal data storage or deal with internal business security.
