Information assymetry is probably your only advantage against credit card fraudsters, because there is no security hole, rather they are exploiting your core business flow.
I want to explore openness wrt fraud prevention, not out of a facile rejection of "security through obscurity," but as part of Gittip's identity as an open company. It's accepted doctrine that "information asymmetry is probably your only advantage." I'm asking: can we be open about fraud prevention and prevent fraud? If we can be, we should.
What are your thoughts on the value of the social graph in spotting suspicious accounts? It seems to me that we should be able to whitelist new accounts based on a review of GitHub or Twitter profiles, and perhaps for flagged accounts we "authorize without capturing," as dangrossman suggests above.
I admire your motives, but I can't offer much encouragement.
My experience is that there is no such thing as preventing fraud in the absolute sense. It's not a binary proposition—maybe general security isn't either, but it's a hell of a lot less gray than credit card fraud. So while I think it's good for general fraud prevention techniques and information to be widely disseminated, I can't in good conscience discuss specifics of techniques that I've employed because those would be easily traceable to companies I've worked for, and thus would impose an undue cost on them. A lot of people who have worked on these issues are probably in similar position where we'd be happy to go into details over a beer but not on public record.
It may be the only thing I can do to help mitigate credit card fraud but is it not the solution to preventing it. Credit card companies should be operating on the theory that people freely throw around their credit card number (because, let's face it, a lot of people do) and come up with solutions that do not rely on hiding that information.
Obscurity of process/information can definitely be a benefit to the security of a system but it should not be the solution. The system should be designed for the absolute worst case scenario where this process/information could be exposed.
I realize this can only go so far until at some point there is going to be some sort of secret that needs to be kept (i.e. physical hardware key, encryption codes, etc) where if this is cracked your system is exposed and at that point you need to have some sort of plan B to regain control and minimize damage.
This is gobbledygook. You are still thinking in terms of security, but with credit card fraud there is no security issue or system to be cracked per se. Rather it's an identity and information problem. You can impose additional steps to vet the legitimacy of a transaction, but there is nothing that can ever give you a 100% guarantee. So you have to balance your efforts at vetting the transaction against usability barriers that add friction to your core business function.
The difference between publishing your techniques (even with specific variables hidden) and often the difference between attackers being able to iteratively determine the minimum work around to get desired results and having to dedicate orders of magnitude more effort than necessary to ensure they are flying under the radar.
You're correct. I was not thinking about conning the system but actually breaking into it which is obviously a lot harder. It is a lot easier to look at ways to dupe the algorithms for determining fraud rather than breaking the system and bypassing them. Thanks for opening my eyes.
Information assymetry is probably your only advantage against credit card fraudsters, because there is no security hole, rather they are exploiting your core business flow.