3 ms·
A BIN attack is feasible if the entry point lets you endlessly try card info. There's not that many, and issuers will give leeway on the card details (some won'
by makeitdouble 2y ago
A BIN attack is feasible if the entry point lets you endlessly try card info. There's not that many, and issuers will give leeway on the card details (some won't care if the card holder's name is botched or completely wrong for instance)
That's also why a PSP will ban the seller if they let that happen on their payment page.
- hypeatei 2y ago> A BIN attack is feasible if the entry point lets you endlessly try card info Yeah, I just figured with all these fraud detection systems in place that rate limiting would be figured out and implemented. Regardless if the seller has a custom page or not, I still would think that PSP APIs would inherently disallow this to protect their customers.
- makeitdouble 2y agoThe complicating factor is that every business is different, and there are legitimate cases where an influx of random card just happens, or a slow trickle of payments goes on at a steady pace. In particular the PSP usually have no window on the seller's system (the seller handles the client and transparently passes the info to the PSP, contractually promising it won't peek into it). So they can't decide on their own if a set of payment requests come from a single end user or multiple ones. There usually will be additional services and hooks to protect from these issues, but with additional fees attached to it, and a bit of dev to do on the seller side. Which means some smaller shops will forgo them and get bitten.