Sometimes I think we app sec folks get way too bogged down in the finer points of CAS or protecting application service credentials and tend to stray away from protecting an application against fraud. Both are definitely important but we tend to focus less on the latter. One of the main reasons I respect Bruce Schneier (besides his obvious crypto ninja skillz) is because he is constantly advocating for greater consumer fraud protection.
What I am Trying To Accomplish:
I wish to create a process where a large set of text (addresses) could be compared to determine exact matches and close proximities to put into a fraud report. Searching for only exact matches would be easy, but a crafty attacker could alter the text slightly while still enabling a package to be delivered to the proper address, i.e. 123 Mulberry Lane, 123 Mulbarry Lane, and 123 Mulberry Ln. or Clearwater, FL 11111 and Claerwater, FL 11111. The goal would be to return each of these addresses as a near 100% match as possible.
I thought of developing a one way algorithm that performed exactly opposite of SHA, where a small change to the input created a minimal change to the output. The output could then be used with a second process to compare all these numbers to find near identical matches.
Real World Example Where This Would Be Useful:
Recently, I was given an interesting problem that involved preventing credit card fraud. To demonstrate the problem domain, let’s just say we are dealing with a site that allows users to purchase gold at a small percentage over current market rates with a credit card. This business faces a few interesting problems.
First and foremost it offers a very attractive vehicle for people to launder money. Using a stolen credit card to purchase an untraceable and incredibly liquid asset at 10% over its market value is a lot more attractive compared to buying high end electronics equipment with serial numbers and then selling it on eBay at a fraction of the purchase price.
Secondly, as the amount of fraud increases, so will the merchant rate on credit card transactions. If they are to sell gold at 10% over market, they definitely would want to get the percentage charged by the credit card companies as low as possible. If the amount of fraud becomes too great their merchant account will be revoked preventing them from accepting credit cards effectively putting them out of business altogether.
Ideas for Preventing Fraud:
The first thought I had was to develop an algorithm that effectively throttled the amount that can be purchased by customer AND credit card AND corresponding shipping address. The algorithm would use not only the length of time, but the number of previous valid transaction in determining the amount that can be purchased.
A crafty attacker would see that a way to side step the throttling algorithm would be to use multiple different customer accounts and credit cards to make a large number of small purchases. I had two ideas to combat this. First would be to compare the number of different credit cards used to ship an order to the same address. Second would be to compare the number of different accounts that placed orders from the same IP address.
I am also toying with the idea of comparing the location of the IP address used to make a purchase in relation to the billing address. I believe this may cause too many false positives and take away from the amount of time customer service reps spend analyzing the output from the other processes.
At the end of the day, the goal is to have a fraud report that presents each order placed sorted by a suspected fraud rating and detail the evidence that supports the rating. A fixed number of customer service reps would then spend their time validating as many orders as possible before they are actually shipped. Once they are out the door, all you can do is maintain what amounts to log files that you can turn over to the credit card companies in case someone makes a fraud complaint.
The one way hash seems to be the optimal route for comparing addresses. Anyone have any thoughts on how to accomplish this? Can anyone think of any other fraud protection algorithms for a business like this?
-Eric Marvets