3 ms·

Yeah, you nailed it. They claim that their Japanese online Coffee shop was hit by a BIN attack and strip wouldn't let them back in, but didn't exactly give any

Yeah, you nailed it. They claim that their Japanese online Coffee shop was hit by a BIN attack and strip wouldn't let them back in, but didn't exactly give any details https://old.reddit.com/r/SaaS/comments/1f762xf/i_hate_stripe_so_im_going_to_build_my_own_payment/ll5920a/ https://old.reddit.com/r/SaaS/comments/1f762xf/i_hate_stripe...

Dalewyn 2y ago
[flagged]
hypeatei 2y ago
I didn't know what BIN attack was until now but it seems to be essentially brute forcing card details until one succeeds. How is that even feasible and why would the sellers account be banned in the case someone got the right combo? Very strange and suspicious.
- 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 ago
      The 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.

Dalewyn 2y ago

[flagged]

hypeatei 2y ago

I didn't know what BIN attack was until now but it seems to be essentially brute forcing card details until one succeeds. How is that even feasible and why would the sellers account be banned in the case someone got the right combo? Very strange and suspicious.

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 ago
    The 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.