4 ms·

This is exactly correct. I've supported a number of different online credit card donation forms for various charitable and other causes, and you see this behav

This is exactly correct. I've supported a number of different online credit card donation forms for various charitable and other causes, and you see this behavior of card testing whenever you set the minimum allowed donation too low, and adopt too few of the necessary precautions. I wrote a post on the approach to raising the bar I took - it really doesn't require much to get the credit card testers to go away, and if you don't get rid of them rapidly, you'll be dealing with chargebacks from here until eternity: http://www.exratione.com/2010/10/three-necessary-defenses-for-open-credit-card-submission-forms/ http://www.exratione.com/2010/10/three-necessary-defenses-fo...

whit537 14y ago
Thank you, good info. For privacy reasons, we've been hoping to not track IP addresses: https://github.com/whit537/www.gittip.com/issues/345 https://github.com/whit537/www.gittip.com/issues/345 Even then, I'm not sure I would trust this approach. I feel much more comfortable white-listing accounts, and for the time being that's not too onerous.
- rmc 14y ago
  For privacy reasons, we've been hoping to not track IP addresses You could hash the IP address, with some suitable salt. Then compare against that. The purpose of storing IP addresses isn't to find out "the IP address of the user submitting the form", but instead to answer "How many other credit card numbers have come from this address?", something that can be done with sha512("salt_mc_salty_$IP")
  - whit537 14y ago
    Good call. I've made a ticket for this, "roll our own automatic fraud prevention," and have included this suggestion: https://github.com/whit537/www.gittip.com/issues/360 https://github.com/whit537/www.gittip.com/issues/360
    - schiffern 14y ago
      The only problem here is, IP addresses are such a small space (4 billion addresses) that it's so easy to brute-force the entire database that I don't see it offering any protection. If the data is stolen it will be cracked in no time, and if the data is subpoenaed that cost will likely be ruled as insufficiently "onerous". Even IPv6 doesn't save you, since the space is sparsely populated. No, with IP logging it's all-or-nothing. You might as well store them as uint32/uint128.
      - whit537 14y ago
        Noted on the ticket, thank you.
      - alaaibrahim 14y ago
        You are kinda of right, but I guess you missed some point here. For the attacker to be able to brute-force, he would require the salt value. So it would be important to make sure it's not in plain-text. And of course if Chad wants to do that, he can easily build a rainbow file, but he can make it easier for himself by just lying about storing the ips. Now another problem with this approach, would be the ability to change the salt. The moment it's changed, all data is lost (or meaningless). So in order to make it secure, it would be very very long, and unpredictable. Also encrypted. Another thing, if an attacker would access the server where the code is running, if it's in the memory he would get it. So when it's in memory, it should only reside there when it's being used, and destroyed immediately. So it makes it harder to the attacker to get it, (until the moment it's used). But come to think of it, if the attacker is that good, I think he would be interested in other things, like things that would get him more money than a list of IP addresses. :-)
      - rmc 14y ago
        It's not as clear cut as that. With suitable salt and suitable (long) hashing function, you can delay From a security / data privacy angle, things are rarely 100% perfect or 100% broken. Just because an approach is not 100% perfect, doesn't mean that it is worthless. It can still offer protection of sensitive data. Storing IPs in the clear in a DB means that if anyone gets any access to it (e.g. SQL injection type attack), they can have the whole lot. With salted IPs it's harder and much longer before they have any decent data. If you tweaked a hashing algorithm to take circa 100 milliseconds to hash an IP, then "brute forcing" would be much less of a problem because it would take about 13 years to hash the whole lot.
  - deleted 14y ago
    [deleted]
- asdfaoeu 14y ago
  It seems most of the backlash around that was due to you suggesting you publish IP addresses. Since you are already taking credit card details I don't think people would object to recording IP addresses to prevent credit card fraud (maybe only record IP addresses for credit card transactions not general usage of the site). If someone wants to anonymously contribute they already have to get an anonymous credit card, getting around an IP address block would seem trivial. I would also, advise against your plan to just white list givers. There are already too many barriers to contributing. I would suggest just charging and holding onto money when the transactions seem dubious. Do you also get charged the cost of fraud? because if you don't I would just charge the credit cards and forget about it and let your provider do their job.
huhtenberg 14y ago
Ah, I see Vietnam is still at it. Persistent buggers.
- someone13 14y ago
  Despite the downvotes, this guy is correct - Vietnam is probably the country with the most incidences of credit card fraud.
pfg 14y ago
I've had the exact same experience with donation forms for multiple NGOs last week. We're probably going to implement some kind of IP limiting (similar to your solution) and additional plausibility checks (since it's only used by national NGOs, that's not too much of a hassle).
bcoates 14y ago
Are the fraudsters using the charity website itself for confirmation that the card works? Could you run them off by just always displaying success for any sane-looking small value donation, without leaking the result from your payment processor?
- caf 14y ago
  This seems like one of the best options - just makes sure the LUHN checks out and the expiry date is in the future, for any small value donation. Alternately (or in addition to this), you could rate-limit form submissions from the same address.
caf 14y ago
From your linked page: Most small online businesses do not store credit card data locally, but that doesn't stop you from using salted hashes of credit card numbers to compare. Storing a "salted hash" of a credit card number in the manner you describe is only fractionally better than storing the credit card number itself. This is because credit card numbers have very little entropy - less than 36 bits per issuer code, so bruteforcing these hashes can be done very quickly.

whit537 14y ago

Thank you, good info. For privacy reasons, we've been hoping to not track IP addresses: https://github.com/whit537/www.gittip.com/issues/345 https://github.com/whit537/www.gittip.com/issues/345 Even then, I'm not sure I would trust this approach. I feel much more comfortable white-listing accounts, and for the time being that's not too onerous.

rmc 14y ago
For privacy reasons, we've been hoping to not track IP addresses You could hash the IP address, with some suitable salt. Then compare against that. The purpose of storing IP addresses isn't to find out "the IP address of the user submitting the form", but instead to answer "How many other credit card numbers have come from this address?", something that can be done with sha512("salt_mc_salty_$IP")
- whit537 14y ago
  Good call. I've made a ticket for this, "roll our own automatic fraud prevention," and have included this suggestion: https://github.com/whit537/www.gittip.com/issues/360 https://github.com/whit537/www.gittip.com/issues/360
  - schiffern 14y ago
    The only problem here is, IP addresses are such a small space (4 billion addresses) that it's so easy to brute-force the entire database that I don't see it offering any protection. If the data is stolen it will be cracked in no time, and if the data is subpoenaed that cost will likely be ruled as insufficiently "onerous". Even IPv6 doesn't save you, since the space is sparsely populated. No, with IP logging it's all-or-nothing. You might as well store them as uint32/uint128.
    - whit537 14y ago
      Noted on the ticket, thank you.
    - alaaibrahim 14y ago
      You are kinda of right, but I guess you missed some point here. For the attacker to be able to brute-force, he would require the salt value. So it would be important to make sure it's not in plain-text. And of course if Chad wants to do that, he can easily build a rainbow file, but he can make it easier for himself by just lying about storing the ips. Now another problem with this approach, would be the ability to change the salt. The moment it's changed, all data is lost (or meaningless). So in order to make it secure, it would be very very long, and unpredictable. Also encrypted. Another thing, if an attacker would access the server where the code is running, if it's in the memory he would get it. So when it's in memory, it should only reside there when it's being used, and destroyed immediately. So it makes it harder to the attacker to get it, (until the moment it's used). But come to think of it, if the attacker is that good, I think he would be interested in other things, like things that would get him more money than a list of IP addresses. :-)
    - rmc 14y ago
      It's not as clear cut as that. With suitable salt and suitable (long) hashing function, you can delay From a security / data privacy angle, things are rarely 100% perfect or 100% broken. Just because an approach is not 100% perfect, doesn't mean that it is worthless. It can still offer protection of sensitive data. Storing IPs in the clear in a DB means that if anyone gets any access to it (e.g. SQL injection type attack), they can have the whole lot. With salted IPs it's harder and much longer before they have any decent data. If you tweaked a hashing algorithm to take circa 100 milliseconds to hash an IP, then "brute forcing" would be much less of a problem because it would take about 13 years to hash the whole lot.
- deleted 14y ago
  [deleted]
asdfaoeu 14y ago
It seems most of the backlash around that was due to you suggesting you publish IP addresses. Since you are already taking credit card details I don't think people would object to recording IP addresses to prevent credit card fraud (maybe only record IP addresses for credit card transactions not general usage of the site). If someone wants to anonymously contribute they already have to get an anonymous credit card, getting around an IP address block would seem trivial. I would also, advise against your plan to just white list givers. There are already too many barriers to contributing. I would suggest just charging and holding onto money when the transactions seem dubious. Do you also get charged the cost of fraud? because if you don't I would just charge the credit cards and forget about it and let your provider do their job.

huhtenberg 14y ago

Ah, I see Vietnam is still at it. Persistent buggers.

someone13 14y ago
Despite the downvotes, this guy is correct - Vietnam is probably the country with the most incidences of credit card fraud.

pfg 14y ago

I've had the exact same experience with donation forms for multiple NGOs last week. We're probably going to implement some kind of IP limiting (similar to your solution) and additional plausibility checks (since it's only used by national NGOs, that's not too much of a hassle).

bcoates 14y ago

Are the fraudsters using the charity website itself for confirmation that the card works? Could you run them off by just always displaying success for any sane-looking small value donation, without leaking the result from your payment processor?

caf 14y ago
This seems like one of the best options - just makes sure the LUHN checks out and the expiry date is in the future, for any small value donation. Alternately (or in addition to this), you could rate-limit form submissions from the same address.

caf 14y ago

From your linked page: Most small online businesses do not store credit card data locally, but that doesn't stop you from using salted hashes of credit card numbers to compare. Storing a "salted hash" of a credit card number in the manner you describe is only fractionally better than storing the credit card number itself. This is because credit card numbers have very little entropy - less than 36 bits per issuer code, so bruteforcing these hashes can be done very quickly.