4 ms·

So? Make them use those card#s, a limited asset, and put the banks to work protecting those interests instead of leaving all the load for us.

getcrunk 5y ago
If only the banks cared
dylan604 5y ago
If you are accepting credit cards, you are liable for the charge backs that occur. If you are only nominally charging <$1 for accounts, then maybe fraudulent charges wouldn't be noticed by the card holder as it wouldn't noticeably alter the balance on a quick glance. However, if you do get a lot of people challenging these charges, then the site owner can pottentially lose their privileages with which ever card processor they are using regardless of the values of those charges. Eventually, the site owners won't want to deal with that either. So, who's court do we put the ball in now?
- KMag 5y ago
  Yea, the incentives in the wrong place for credit card processors. They actually charge credit processing fees for fraudulent purchases, and then get to charge processing fees again for the chargeback when the fraud is discovered, even though the merchant sends all the info they have to the processor and the processor okays the transaction. The credit card processors have the most information, but the least incentive to fight fraud. At LimeWire, for a while, the price for LimeWire Pro was a hidden field in the order form, because the CTO (rightly) wanted to minimize the amount of logic running on anything that touched credit cards. The form was generated on one host and posted to another, and the logic for experimenting with lower prices at certain times, etc. was kept off of the host that processed credit cards. As a result, some more technical users could order LimeWire Pro for $1. But, they could also find LimeWire Pro using the free version, so no real loss there. However, some carding gangs also noticed, and would validate huge batches of credit card numbers by buying LimeWire Pro for $1. The cargebacks were a bit painful, but more importantly, if your fraud rate is above some threshold, your fees go up, and at some point our credit card processor gave us 2 months to bring down our fraud rate or they'd cancel our merchant account. The processor also refused to give us fraud information updates with any finer granularity than monthly, so we basically had two tries to bring the fraud rate down. All of the existing CAPTCHA systems I could find required a shared filesystem between the process generating the CAPTCHAs and the process checking the answers. That was a no-go with our policy of minimizing attack surface of our credit card processing host. So, I wrote a CAPTCHA that used HMAC to generate a 96-bit tag from a timestamp (at 1 minute granularity), the user's IPv4/24, and the price. The other 64 bits of SHA1-HMAC output were used to seed the prng that generated the CAPTCHA. The timestamp and 96-bit tag became hidden fields in the HTML purchase form. That way, the credit card processing box could validate the time, IP address, and price, and check the CAPTCHA answer, all from the submitted form data. Answers with timestamps more than 20 minutes old were rejected, so the processing box only needed to remember all of the correct CAPTCHA answers over the past 20 minutes to avoid replay attacks. Making the timestamp 1-minute granularity prevented bots from hammering the system until they got easy CAPTCHAs. The first day we put my CAPTCHA system in production, we saw an IP in Virginia very rapidly trying to make purchases without the CAPTCHA. Then it paused for a few minutes while the attacker figured out what was going on and manually solved one CAPTCHA. Then a rapid-fire batch of purchases came through with the same CAPTCHA answer, and only the first purchase came through. A couple minutes later, that exact same CAPTCHA 96-bit tag and answer came in from a UK IP address, but it was rejected because the 96-bit tag didn't match the HMAC. Those were fun days, but it's a shame incentives are so misaligned.
  - adrr 5y ago
    We had the same issue for our $3 price point plan. We never used CAPTCHAS. We fingerprinted browsers, used proxy detection, and other methods to detect them. They would script the page, so we would move live url to a new one and then feed bad data on old page which polluted their data set. It was quite fun messing with them. Most of the bot nets would get caught on browser fingerprinting and that they were falsifying their user agent. Our browse fingerprint ban would say their IP was banned so we would watch them jump from bot net computer to not bot net computer.
    - dylan604 5y ago
      > It was quite fun messing with them. While I can appreciate that, how much time did this take, of how many people, for how long? I ask all of that as someone about to launch a public facing retail site, and absolutely dread this type of stuff. It's a side hustle project on top of my actual day job/contract jobs, AKA I don't have a lot of time to dedicate to this.
      - adrr 5y ago
        Not much time. Probably a couple days. We used maxmind proxy detection and FingerPrint.js. We also used source of traffic. Bots never come in on ads. They come in direct. Stuff we built at a neoBank to prevent credential stuff from password leaks was a lot more sophisticated. Couldn’t trust email based 2fa because people re-used passwords. We did invasive hashing of internal networks with webRTC and also pierced proxies with STUN. Along with using a commercial waf that did real time profiling.
  - KMag 5y ago
    The day we turned on our CAPTCHA, I also remember being horrified at the number of people likely running LimeWire on US Navy vessels. One IP address in the DC metro area had multiple purchases per minute, with half of the email addresses ending in .navy.mil, so I added an IP address whitelist to not drop those CAPTCHA answers into the replay-prevention cache. I'm pretty sure that IP address was the base station for a US Navy satellite. I mean, not horrified enough to prevent them from paying my company $18.88, but still horrified. In retrospect, given that we were a 13 person company selling software with a marginal cost near zero, we should have left the system in place and never processed the $1 charges. Instead, we should have used a CRC32 of the upper-cased name and credit card number (in case they verified consistency) to accept 98% of $1 purchases without ever charging any of the cards. Even better would be to do a 2-part credit card transaction, first placing a hold on the credit card for the full purchase price, and waiting one minute to see how many different credit card numbers came from the same IP address in the next minute. If less than 4 different numbers came in the past minute, go ahead and complete those transactions, otherwise put the IP on the hellban list to start getting randomized results. Injecting pure noise into the carding ecosystem would have cost us nearly nothing (and given a 100% discount to a bunch of active duty sailors).
- sodality2 5y ago
  Something like a Stripe Payment Link [1] would help with this, right? The payment is directly on Stripe.com so they have the best chance at stopping fraud across the whole platform. [1]: https://stripe.com/payments/payment-links https://stripe.com/payments/payment-links
  - dylan604 5y ago
    I'm pinning my hopes on that. It's the only 3rd party JS library I'm using, and hope to not have to deal with the nightmare of fighting these battles
    - sodality2 5y ago
      Me too. Stripe's chargeback protection is just 0.4% per transaction, which is well-worth it when the products are under ~$5 and chargebacks cost $15, but it's unavailable for payment links as per customer support just now :/
      - dylan604 5y ago
        Interesting. Is Stripe itself not available or just this chargeback protection? Mind sharing what type of business?
        sodality2 5y ago
        Stripe offers Payment Links [0], which makes it really easy to accept payments (just paste a link into your product page and handle a webhook serverside; a single href is adequate). They also have a separate "Checkout" offering [1], which requires some code client- and server-side to generate the page. So far, Stripe has been awesome for me selling $2.50/mo subscriptions using just the link [2], and as far as I know, suspicious transactions are very likely to be blocked by Stripe Radar which is across all of Stripe. However, their chargeback protection service (0.4%/tx for total protection for any chargeback) [3] is only offered for the Checkout version. This means I won't be protected in the case of a chargeback, whether by a customer or fraud that slipped past Radar. ("Currently, Chargeback Protection is only available on the new version of Checkout" is what I was told by support) [0]: https://stripe.com/payments/payment-links https://stripe.com/payments/payment-links [1]: https://stripe.com/docs/checkout/quickstart https://stripe.com/docs/checkout/quickstart [2]: As a student I get fees waived for the first $1000 in volume, otherwise fees would eat through 20% of my revenue immediately at this price point. I posted about this side business recently as a Show HN if you would like to know more :) [3]: https://stripe.com/radar/chargeback-protection https://stripe.com/radar/chargeback-protection
- mh- 5y ago
  Not just that processor, but potentially across all of Mastercard. Google tmf match for more info. One such result: https://stripe.com/docs/disputes/match https://stripe.com/docs/disputes/match
- mccorrinall 5y ago
  Just force 3d secure. It shifts the liability from you to the customer’s bank
  - dylan604 5y ago
    I don't know how you "just force" something like this. I had to look up what it even is. If I visited a website that "forced" this, I would be unable to complete the transaction. I've never seen this to even see how it would work. Doesn't seem like it's one of those things that should "just" be done and expect it to not negatively impact things.
    - lovingCranberry 5y ago
      All banks in the EU support 3ds (SCA is mandatory since 2019). The majority of banks which don't support 3ds are located in the US, but even there it's only a *zero point x percentage. Turns out that banks don't like fraud either :P You can manually trigger a 3ds authentication flow when setting up the payment intent: just set payment_method_options[card][request_three_d_secure] to "any". Ran a 3.000+ tx/day business with this and got less than double digit disputes per month which are usually lost by the customer. Those disputes are also not for "stolen credit card", but "not delivered product" or similar bs. Fun fact: If three_d_secure.authenticated is false but three_d_secure.succeeded is true, the bank did not authenticate the payment but you are still protected from chargebacks since the bank accepted the liability shift. (Happens for smaller purchases, e.g. < 30€ && known device && customer authenticated another purchase in the last three purchases he did with the card) If you are using a no-code solution and are not setting up your payment intents manually, you can also subscribe to radar and create a rule for 3ds if amount >= 0€. * These numbers are from my experience of running our shop for a software company.
- rhizome 5y ago
  Not <$1. $5.
8note 5y ago
If you make 30k per successfully abused account, you can spend a lot on stolen credit cards. Or if you want, use virtual credit cards that give you a new number every time, and will pass without a name/address match

getcrunk 5y ago

If only the banks cared

dylan604 5y ago

If you are accepting credit cards, you are liable for the charge backs that occur. If you are only nominally charging <$1 for accounts, then maybe fraudulent charges wouldn't be noticed by the card holder as it wouldn't noticeably alter the balance on a quick glance. However, if you do get a lot of people challenging these charges, then the site owner can pottentially lose their privileages with which ever card processor they are using regardless of the values of those charges. Eventually, the site owners won't want to deal with that either. So, who's court do we put the ball in now?

KMag 5y ago
Yea, the incentives in the wrong place for credit card processors. They actually charge credit processing fees for fraudulent purchases, and then get to charge processing fees again for the chargeback when the fraud is discovered, even though the merchant sends all the info they have to the processor and the processor okays the transaction. The credit card processors have the most information, but the least incentive to fight fraud. At LimeWire, for a while, the price for LimeWire Pro was a hidden field in the order form, because the CTO (rightly) wanted to minimize the amount of logic running on anything that touched credit cards. The form was generated on one host and posted to another, and the logic for experimenting with lower prices at certain times, etc. was kept off of the host that processed credit cards. As a result, some more technical users could order LimeWire Pro for $1. But, they could also find LimeWire Pro using the free version, so no real loss there. However, some carding gangs also noticed, and would validate huge batches of credit card numbers by buying LimeWire Pro for $1. The cargebacks were a bit painful, but more importantly, if your fraud rate is above some threshold, your fees go up, and at some point our credit card processor gave us 2 months to bring down our fraud rate or they'd cancel our merchant account. The processor also refused to give us fraud information updates with any finer granularity than monthly, so we basically had two tries to bring the fraud rate down. All of the existing CAPTCHA systems I could find required a shared filesystem between the process generating the CAPTCHAs and the process checking the answers. That was a no-go with our policy of minimizing attack surface of our credit card processing host. So, I wrote a CAPTCHA that used HMAC to generate a 96-bit tag from a timestamp (at 1 minute granularity), the user's IPv4/24, and the price. The other 64 bits of SHA1-HMAC output were used to seed the prng that generated the CAPTCHA. The timestamp and 96-bit tag became hidden fields in the HTML purchase form. That way, the credit card processing box could validate the time, IP address, and price, and check the CAPTCHA answer, all from the submitted form data. Answers with timestamps more than 20 minutes old were rejected, so the processing box only needed to remember all of the correct CAPTCHA answers over the past 20 minutes to avoid replay attacks. Making the timestamp 1-minute granularity prevented bots from hammering the system until they got easy CAPTCHAs. The first day we put my CAPTCHA system in production, we saw an IP in Virginia very rapidly trying to make purchases without the CAPTCHA. Then it paused for a few minutes while the attacker figured out what was going on and manually solved one CAPTCHA. Then a rapid-fire batch of purchases came through with the same CAPTCHA answer, and only the first purchase came through. A couple minutes later, that exact same CAPTCHA 96-bit tag and answer came in from a UK IP address, but it was rejected because the 96-bit tag didn't match the HMAC. Those were fun days, but it's a shame incentives are so misaligned.
- adrr 5y ago
  We had the same issue for our $3 price point plan. We never used CAPTCHAS. We fingerprinted browsers, used proxy detection, and other methods to detect them. They would script the page, so we would move live url to a new one and then feed bad data on old page which polluted their data set. It was quite fun messing with them. Most of the bot nets would get caught on browser fingerprinting and that they were falsifying their user agent. Our browse fingerprint ban would say their IP was banned so we would watch them jump from bot net computer to not bot net computer.
  - dylan604 5y ago
    > It was quite fun messing with them. While I can appreciate that, how much time did this take, of how many people, for how long? I ask all of that as someone about to launch a public facing retail site, and absolutely dread this type of stuff. It's a side hustle project on top of my actual day job/contract jobs, AKA I don't have a lot of time to dedicate to this.
    - adrr 5y ago
      Not much time. Probably a couple days. We used maxmind proxy detection and FingerPrint.js. We also used source of traffic. Bots never come in on ads. They come in direct. Stuff we built at a neoBank to prevent credential stuff from password leaks was a lot more sophisticated. Couldn’t trust email based 2fa because people re-used passwords. We did invasive hashing of internal networks with webRTC and also pierced proxies with STUN. Along with using a commercial waf that did real time profiling.
- KMag 5y ago
  The day we turned on our CAPTCHA, I also remember being horrified at the number of people likely running LimeWire on US Navy vessels. One IP address in the DC metro area had multiple purchases per minute, with half of the email addresses ending in .navy.mil, so I added an IP address whitelist to not drop those CAPTCHA answers into the replay-prevention cache. I'm pretty sure that IP address was the base station for a US Navy satellite. I mean, not horrified enough to prevent them from paying my company $18.88, but still horrified. In retrospect, given that we were a 13 person company selling software with a marginal cost near zero, we should have left the system in place and never processed the $1 charges. Instead, we should have used a CRC32 of the upper-cased name and credit card number (in case they verified consistency) to accept 98% of $1 purchases without ever charging any of the cards. Even better would be to do a 2-part credit card transaction, first placing a hold on the credit card for the full purchase price, and waiting one minute to see how many different credit card numbers came from the same IP address in the next minute. If less than 4 different numbers came in the past minute, go ahead and complete those transactions, otherwise put the IP on the hellban list to start getting randomized results. Injecting pure noise into the carding ecosystem would have cost us nearly nothing (and given a 100% discount to a bunch of active duty sailors).
sodality2 5y ago
Something like a Stripe Payment Link [1] would help with this, right? The payment is directly on Stripe.com so they have the best chance at stopping fraud across the whole platform. [1]: https://stripe.com/payments/payment-links https://stripe.com/payments/payment-links
- dylan604 5y ago
  I'm pinning my hopes on that. It's the only 3rd party JS library I'm using, and hope to not have to deal with the nightmare of fighting these battles
  - sodality2 5y ago
    Me too. Stripe's chargeback protection is just 0.4% per transaction, which is well-worth it when the products are under ~$5 and chargebacks cost $15, but it's unavailable for payment links as per customer support just now :/
    - dylan604 5y ago
      Interesting. Is Stripe itself not available or just this chargeback protection? Mind sharing what type of business?
      - sodality2 5y ago
        Stripe offers Payment Links [0], which makes it really easy to accept payments (just paste a link into your product page and handle a webhook serverside; a single href is adequate). They also have a separate "Checkout" offering [1], which requires some code client- and server-side to generate the page. So far, Stripe has been awesome for me selling $2.50/mo subscriptions using just the link [2], and as far as I know, suspicious transactions are very likely to be blocked by Stripe Radar which is across all of Stripe. However, their chargeback protection service (0.4%/tx for total protection for any chargeback) [3] is only offered for the Checkout version. This means I won't be protected in the case of a chargeback, whether by a customer or fraud that slipped past Radar. ("Currently, Chargeback Protection is only available on the new version of Checkout" is what I was told by support) [0]: https://stripe.com/payments/payment-links https://stripe.com/payments/payment-links [1]: https://stripe.com/docs/checkout/quickstart https://stripe.com/docs/checkout/quickstart [2]: As a student I get fees waived for the first $1000 in volume, otherwise fees would eat through 20% of my revenue immediately at this price point. I posted about this side business recently as a Show HN if you would like to know more :) [3]: https://stripe.com/radar/chargeback-protection https://stripe.com/radar/chargeback-protection
mh- 5y ago
Not just that processor, but potentially across all of Mastercard. Google tmf match for more info. One such result: https://stripe.com/docs/disputes/match https://stripe.com/docs/disputes/match
mccorrinall 5y ago
Just force 3d secure. It shifts the liability from you to the customer’s bank
- dylan604 5y ago
  I don't know how you "just force" something like this. I had to look up what it even is. If I visited a website that "forced" this, I would be unable to complete the transaction. I've never seen this to even see how it would work. Doesn't seem like it's one of those things that should "just" be done and expect it to not negatively impact things.
  - lovingCranberry 5y ago
    All banks in the EU support 3ds (SCA is mandatory since 2019). The majority of banks which don't support 3ds are located in the US, but even there it's only a *zero point x percentage. Turns out that banks don't like fraud either :P You can manually trigger a 3ds authentication flow when setting up the payment intent: just set payment_method_options[card][request_three_d_secure] to "any". Ran a 3.000+ tx/day business with this and got less than double digit disputes per month which are usually lost by the customer. Those disputes are also not for "stolen credit card", but "not delivered product" or similar bs. Fun fact: If three_d_secure.authenticated is false but three_d_secure.succeeded is true, the bank did not authenticate the payment but you are still protected from chargebacks since the bank accepted the liability shift. (Happens for smaller purchases, e.g. < 30€ && known device && customer authenticated another purchase in the last three purchases he did with the card) If you are using a no-code solution and are not setting up your payment intents manually, you can also subscribe to radar and create a rule for 3ds if amount >= 0€. * These numbers are from my experience of running our shop for a software company.
rhizome 5y ago
Not <$1. $5.

8note 5y ago

If you make 30k per successfully abused account, you can spend a lot on stolen credit cards. Or if you want, use virtual credit cards that give you a new number every time, and will pass without a name/address match