Pizza Orders Reveal Credit Card Scheme, and a Secondhand Market - NYTimes.com

[Eric Shapiro]

I think the takeaway story here for app developers is to throttle invalid credit card attempts:

http://mobile.nytimes.com/2014/12/06/nyregion/pizza-orders-reveal-credit-card-scheme-and-a-secondhand-market.html?_r=0


------------------
Eric Shapiro
er...@relium.com

[Paul Bruneau]

And maybe valid ones!

> --
> You received this message because you are subscribed to the Google Groups "CocoaHeads Ann Arbor" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to a2-cocoahead...@googlegroups.com.
> To post to this group, send email to a2-coc...@googlegroups.com.
> Visit this group at http://groups.google.com/group/a2-cocoaheads.
> For more options, visit https://groups.google.com/d/optout.

[Keith Bourne]

Ha, ironically, the place I get the most free pizza is Cocoaheads!

In terms of preventing this, you can run credit card authorizations in your app, if you take CC payments, through the payment service you use.   But beyond that, what could you reasonably do in this case?

I imagine all these schemes, such as setting off flags at HQ when a single app tracks orders to multiple addresses in a designated time period, and other similar algorithms, but that isn't trivial in terms of development time/cost.  Doesn't seem like most groups, even Dominos, is going to be able to justify the cost unless this becomes widespread.  And it doesn't seem like something that is limited to just pizza.  

Maybe there is an opportunity in this?  Maybe an SDK-based service for tracking this type of fraud...

Keith Bourne

Arbormoon Software, Inc.

Mobile Strategist
734.929.8026

Find me @:

Arbormoon: http://arbormoon.com 
Web: http://keithbourne.com
Twitter: @keithbourne

[Glenn Everitt]

It seems like the easiest thing to do would be to limit  purchase failures within a time period.  For example, someone get 6 failed purchase attempts in 2 hour time period. You just keep the purchase failure count and timestamp of last attempt.

Once you hit that failure count threshold you have wait an hour or two to try again.  It seems like the thieves would want to work through the credit card numbers quickly and this scheme would frustrate them enough that they would find another app or another way.  In either case it reduces my app backcharge loses.

Glenn Everitt

[Eric Shapiro]

On Dec 7, 2014, at 2:08 PM, Keith Bourne <keithe...@gmail.com> wrote:

> Maybe there is an opportunity in this? Maybe an SDK-based service for tracking this type of fraud...

Fraud detection should be done on both the server and client. The client can always be compromised by a determined hacker, but it's still a good first line defense against fraud.

The server can detect 'funny' activity using rules such as 'multiple invalid credit card numbers from a single IP address within a few minutes' or '4+ different credit cards used by a single device within a day'.

On an iOS client, I would write a record to the keychain indicating the date of recent credit card rejections. The keychain will survive deleting and reinstalling an app, so users would have to wipe the device, jailbreak, hack into an app, or reverse engineer the protocol to circumvent.

I would write a UUID to the keychain as well so the server can uniquely identify a device, similar to the now-deprecated 'deviceIdentifier' but more persistent than the replacement 'identifierForVendor'.

All communications should be secure and rather than using standard HTTPS URLs, you could build the certificate into the application or at least check the certificate issuer. This will help prevent hackers from using proxy servers, packet sniffers, and self-signed certificates.

I would check application integrity using digital signatures.

Rather than using plain JSON, you can use a binary protocol that's harder to reverse engineer. Or you could put a checksum parameter into the protocol to prevent replay attacks.

You can check if the software is being debugged at runtime and, if so, refuse to run or run different code paths.

There is software from companies like Arxan that will de-symbolize and scramble your application to make it harder to reverse engineer. I think it's mostly used by banks and game companies - turns out hackers like hacking into multiplayer games to cheat.

We spent a lot of time coming up with crazy security schemes when I was at Widevine with the realization that hackers would spend even more time breaking them.

-Eric

------------------------------------------------
Eric Shapiro sha...@relium.com
------------------------------------------------

[Keith Bourne]

Those are cool concepts.  Would Apple allow writing your own UUID to the keychain?

For this particular case, are we talking about hackers or just people that are using this particular app to test out CC #'s?  Maybe that is how they got the CC #'s?   

Either way, if you go down this road, seems like you will quickly get into the methods you describe, since the perps will continue to get more sophisticated.

Keith Bourne

Arbormoon Software, Inc.

Mobile Strategist
734.929.8026

Find me @:

Arbormoon: http://arbormoon.com 
Web: http://keithbourne.com
Twitter: @keithbourne

[Eric Shapiro]

On Dec 7, 2014, at 4:29 PM, Keith Bourne <keithe...@gmail.com> wrote:

> Those are cool concepts. Would Apple allow writing your own UUID to the keychain?

I don't think they would notice it frankly. For security I suspect it would be ok. It is essentially the same thing as Apple's identifierForVendor API, but without the side effect where deleting all apps from that vendor resets the identifier.

> For this particular case, are we talking about hackers or just people that are using this particular app to test out CC #'s? Maybe that is how they got the CC #'s?

In this case people bought lists of stolen credit cards and wanted to see which ones were valid. So they ordered pizza using the Dominos app, typically sent elsewhere, to see which numbers were valid. If valid, they later used those credit card numbers to make larger purchases.

> Either way, if you go down this road, seems like you will quickly get into the methods you describe, since the perps will continue to get more sophisticated.

Yeah, it's a never-ending arms race. One trick is to make it hard enough that hackers use someone else's app instead. This is the "I don't have to run faster than the bear, I just have to run faster than you" security system.

It'll be interesting to see if ApplePay raises the security bar - can you use that to order pizza yet?