On 2012-06-09, at 10:56, Owen DeLong <owen@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
On 6/9/12, Alexandre Carmel-Veilleux <acv@miniguru.ca> wrote: 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