Hacker News Reader

Comment by dsl | Hacker News Reader

This isn't money laundering (from your initial github ticket its obvious that is what you were looking for, so thats what you found).

Before selling stolen credit cards, bad guys have to verify them. This is often done with small (<$10) donations to charities or small purchases of intangible goods that are considered low risk merchants.

With Gittip they found a way to get the low dollar amounts to come back to them, but since this wasn't really the goal to start with, you'll likely see donations to random leaderboard members that are unaffiliated with the fraud itself in the future.

View on HN

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

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

Agreed. When I read this it looks like a verification process for a batch of stolen credit cards to see which are still valid and which aren't. Note that the "successful" transactions may very well be charged back to you at $15 each or more so you want to refund any suspicious payments quickly to avoid going into the negative.

You basically have to catch it before the charge is even settled; either within the same business day before your settlement cutoff, or by authorizing without capturing for a day or two so you have time to review. Once the charge is settled, a refund almost never stops someone from charging back the payment -- for whatever reason, when a card is reported stolen, people and banks simply charge back everything unauthorized even if a quick review of the account would show some of the payments were already refunded. You can dispute these chargebacks by providing proof of the previous refund, but you're still out the chargeback fees, and these chargebacks still count against your account -- so they can end up getting you terminated if your CB rate is pushed too high.

Thanks, good info. My plan at this point is to whitelist accounts, because I want to try to keep from charging suspicious accounts in the first place.

We get these, have seen a case where we refunded but apparently they were going after the currency conversion amount with the chargeback. Do some providers offer longer settlements? Feels like we only get a few hours a lot of the time to void a transaction.

You have 1-3 days to capture an amount you previously authorized. You only have so little time because you're authorizing and capturing at the same time. If you need more time to review, decouple them. Some payment gateways also let you decide the settlement cutoff time, so you can set it after business hours.

Informative, thank you both. On this ticket we discussed why Gittip isn't the best system for extracting value from a card:

https://github.com/whit537/www.gittip.com/issues/329

The desire to verify stolen cards with the added benefit of recovering that waste seems to explain the motive for using Gittip.

I read up on money laundering, and changed the blog post to talk about "stolen money" instead. Thanks.

It's not even about stealing money per se, it's a step in the process of credit card theft. Fraudsters often do the same thing on Amazon and iTunes - they'll make 1 dollar purchases that allow them to 'verify' the cards. In these cases the 1 dollar purchases aren't for any direct material gain.

Sure. And yet from Gittip's POV as well as that of the original victim, it's still stolen money, on Gittip. No?

Sort of. Theft isn't the primary motive, so I think it's inaccurate. A lot of what the fraudsters are (or will be) doing is transferring money from victims to innocent people. The real-life analogy I would use is going to a store and putting something in someone's bag without them noticing to test the store's security. That is arguably not theft, even though it's illegal.

I'd say the proper term is fraud. But I don't really like semantic arguments, so I'd say it's not a huge deal either way :)

edit: I should add, the reason I don't think it's stealing is because the money often gets returned; the illicit transfers can be reversed. When the real stealing will be going on the fraudsters will be taking lots of money and running.

edit2: I feel bad for even objecting, it's really not a big deal. 'Stealing money' is close enough to what's going on.

That is arguably not theft

That is common law theft. Property taken, no consent, deprives legitimate owner of use of it. The thief gaining value from the property is not an element of the crime.

I think it's a valuable distinction you're making, and I don't think it's merely a matter of semantics. Knowing the motivations of the criminals involved is useful in building workable defences - the fact that they don't care if they get the money or not is important information, and not immediately obvious. I for one have learned something from this thread, anyway.

Agreed. When this kind of fraud started the anti-fraud industry was a bit unprepared because low amount transactions were historically not dangerous. Understanding why it was happening helped quite a bit.

Fair enough. "Some" money coming into Gittip from stolen cards is in fact going out into bank accounts, some of them belonging to "innocent people" (myself included)--but some of them not. Theft, strictly defined, is in fact taking place.

edit2: :^)

-- Perhaps best to make a conforming edit to the HN title

@heathanderson?

> Before selling stolen credit cards, bad guys have to verify them. This is often done with small (<$10) donations to charities or small purchases of intangible goods that are considered low risk merchants.

They also verified them on SoundCloud without any purchase. Don't know if it's still possible.

Did you mean verify that an account is associated with the credit card?

Or just verify that the credit card number is potentially a legitimate one?

Because if it's the latter, that's just the Luhn algorithm (http://en.wikipedia.org/wiki/Luhn_algorithm) and no transactions are required to perform the verification.

If it's the former, until you make a transaction there's no way to verify in advance whether or not a card has a still valid account attached to the backside of it.

I know you're saying "without any purchase", but maybe it was just for a vanishingly small amount.

> If it's the former, until you make a transaction there's no way to verify in advance whether or not a card has a still valid account attached to the backside of it.

It's possible, with most credit card processors, to perform a $0 authorization to confirm that a credit card number is linked to an active account. It doesn't guarantee that any charges against the card will go through -- the card may be at its limit, for instance -- but it will correctly reject numbers that are structurally valid (e.g, pass Luhn) but which don't correspond to any account.

it's just that they offer a free trial without charging any 0.01, if it passes they cancel the account and the owner never knows the card was tried out. this method can work on any 'free trial cc required' as long as it doesn't charge any test ammount.

Reply on news.ycombinator.com