CVV numbers

Sat Jun 9 21:25:04 UTC 2012

On 6/9/12, Alexandre Carmel-Veilleux <acv at miniguru.ca> wrote:
> On 2012-06-09, at 10:56, Owen DeLong <owen at delong.com> wrote:
>> How does having the CVV number prove the card is in my possession?
> It doesn't, it merely proves you must have handled the card physically at
> some point since storing that value in a database is forbidden.
[snip]
Someone must have something in a database that can easily derive the
CVV2 number;
otherwise there would be no way for it to be verified that the correct
number has
been presented,  there's really no hashing  scheme for 3-digit numbers
that cannot be trivially brute-forced,  once any salting procedure is
known by an attacker.

I bet there is at least one small retailer out there who takes phone
orders and gathers CVV2, and at least one  POS software developer out
there who is unaware of, has ignored, or has
intentionally/unintentionally disobeyed the rule about never storing
CVV2 values in a database,    and does at least one of these things:
transmits it without storing but fails to encrypt it (e.g. number sent
to a backend with unencrypted XMLRPC transaction),  records it in a
database,  e-mails the data internally, puts it in a spreadsheet, and
stores it as data at rest (encrypted it or not), and fails to scrub
it,  eg  deleted but not overwritten file on a computer, file on a
share,  e-mail saved in a folder,  writes it down,   or otherwise
misappropriates the CVV2 value  together with the CC# and Expdate.

In other words CVV2 is a "weak"  physical "proof" mechanism that only
works if  all parties involved obey the rules perfectly without error,
 even parties such as merchants who are not necessarily trustworthy,
but even if trustworthy may also have kept record of CVV2  CC Expdate
by accident, poor process,  or   failure of  staff to follow
established procedures  for the handling
of the data.

-- 
-JH