Detect breaches with Canary credit cards

ocal5 wrote: post #5

Looks neat and thanks for sharing idea. Aren't professionnal going to just discard all numbers associated with this "bank", then ?

> 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?”

Re: Detect breaches with Canary credit cards

#7

Post by detaro » Sun, Jan 22, 2023, 3:14 PM UTC

ocal5 wrote: post #5

Looks neat and thanks for sharing idea. Aren't professionnal going to just discard all numbers associated with this "bank", then ?

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)

Re: Detect breaches with Canary credit cards

#8

Post by detaro » Sun, Jan 22, 2023, 3:16 PM UTC

remram wrote: post #4

Those are free? Wouldn't those cost them something to create or operate?

The Canarytokens service is clearly more or less an advertising expense for them. People that know and use it are more likely to buy their commercial offerings.

Re: Detect breaches with Canary credit cards

#9

Post by whstl » Sun, Jan 22, 2023, 3:24 PM UTC

remram wrote: post #4

Those are free? Wouldn't those cost them something to create or operate?

This is a late-2000s story but: I once worked for a small-time credit card emitter and the only money leaving us was the money from the transactions themselves.

It was quite interesting, AFAIK we had a range of CC numbers that we could use, and we had to "answer" to an API call (a "lower-level webhook", it wasn't HTTP) that provided all the user data for verification, and we had to authorize in a maximum amount of time (hard real-time). The verification happened entirely on our side, so it was even possible to reuse numbers by changing the CVV or expiration date, for example. At least that was how it was explained to me, someone could chime in and correct some mistakes here! :)

This feature later enabled some banks to allow the customer to change their "credit limit" as much as they wanted, or to block/unblock the card using a toggle in the app. But "real time confirmation" wasn't possible because of the hard-real-time constraint we had. I remember we had to reply very fast at the time, and could get punished if we had too many timeouts.

This might not be the reality on every country or region, but by giving everyone a dummy credit card in those conditions, the costs would be only of servers + personnel.

Of course, a partnership with zero dollars worth of transactions would make zero sense to the partnering bank, so they would obviously complain. But this here seems to be a special case where there's a previous agreement.

Re: Detect breaches with Canary credit cards

#10

Post by ocal5 » Sun, Jan 22, 2023, 3:24 PM UTC

lights0123 wrote: post #6

ocal5 wrote: post #5

Looks neat and thanks for sharing idea. Aren't professionnal going to just discard all numbers associated with this "bank", then ?

> 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 th…

win - win : )