[Asterisk-biz] CC Fraud

[Kenneth Shaw]

Including 8 digits of a 16 digit number and an MD5 hash isn't secure to
begin with. This makes no sense at all. We provide merchant accounts,
processing gateways, etc. at ExpiTrans. Your processing gateway already
has white and black lists of credit cards. You're talking about
reinventing the wheel.

There is only one way to get around this right now, and that is to use
Visa's 3d Secure, which requires the user to basically log into a Visa
authorized site, and provide more information. MasterCard has something
called SecuriCode (I think?) which is supposed to be deployed later this
year around the globe, and is basically the same thing.

Look, the "Card Verification Codes" (CVC/CVV/CVV2) don't do jack. It was
a BS marketing ploy by MasterCard in the mid 90s to create an illusion
of security. All it does is extend the card number by 3 or 4 random
digits. The solution to this isn't an account/pin solution (which is
what a CVC really is) but a fully qualified challenge/response
mechanism. Otherwise, CVC codes just become databased like anything
else.


On Sun, 2005-06-19 at 10:32 -0700, David Pollak wrote:
> Well...
> 
> You could have a shared DB of MD5 hashed CC #'s (never store the
> actual CC #) along with the first 4 numbers and last 4 numbers of the
> card.  You could count the number of merchants in the network the CC #
> has been used with over a certain period of time, the IP address that
> the CC # was used from, etc.  One could then run some statistics on
> the CC #'s.  If there was too much traffic on a single card or on card
> sequences, etc. you could alert the merchants and they could void the
> charges or issue refunds.
> 
> This would also be a good "single point of contact" for enhanced
> verification techniques:
> - Debiting or crediting the account with a few pennies and getting to
> user to enter the amount in another web site
> - Calling the user on the phone and getting them to answer a simple
> math problem (what's 3 + 4) and recording their voice authorizing the
> charge
> - Maybe more
> 
> It could be an interesting project.  Any thoughts on how many
> different folks on this group would be willing to join a merchants
> group to build something like this?
> 
> snacktime wrote: 
> > > Like SPEWS.org, maybe it's time for a CC blacklist for the iMerchant
> > > community.
> > > 
> > > Anyone would be able to query the blacklist--a negative response would
> > > indicate a merchant had chargebacks (or other trouble) on the CC#.
> > > 
> > > Anyone would be able to enter a CC# into the database.  A legit. CC
> > > holder would get off the list simply by changing his CC# with his bank.
> > > 
> > > The trouble with this is the vast community of underemployed lawyers.
> > >     
> > 
> > There aren't any legal issues with this as long as you have specific
> > defined critieria.  You can't just put someone in a negative database
> > because you *think* they are fishy or you don't like them.   negative
> > databases in the bankcard industry are common practice.
> > 
> > The problem is that negative databases don't make sense for stolen
> > cards.  If a card is stolen get the bank to cancel it or investigate
> > it.  Negative databases are usually for legitimate cardholders that
> > simply have a habit of charging back.
> > 
> > Chris
> > _______________________________________________
> > Asterisk-Biz mailing list
> > Asterisk-Biz at lists.digium.com
> > http://lists.digium.com/mailman/listinfo/asterisk-biz
> >   
> _______________________________________________
> Asterisk-Biz mailing list
> Asterisk-Biz at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-biz

-- 
Kenneth Shaw
Director of Technology
ExpiTrans, Inc.
2428 Newport Blvd #8
Costa Mesa, CA 92627
tel: 949 278 7288
fax: 866 494 5043
ken at expitrans.com