Hacker News Reader

Comment by exratione | Hacker News Reader

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-fo...

View on HN

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.

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

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.

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")

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

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.

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. :-)

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.

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

Or $31,000 on EC2. Are these logs per-request or per-transaction? The former could get awfully expensive.

Of course, checking a single target IP address would be trivial. Whether that matters depends on their threat model.

Noted on the ticket, thank you.

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.

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?

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.

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

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

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).

Reply on news.ycombinator.com