"Let's talk about that CVV for a moment. ... PCI DSS is very clear about how the CVV (or CVV2 as it is these days) should be stored ... It shouldn't be stored and that's what makes this breach such a big issue. Violation of PCI DSS guidelines can lead to pretty serious fines and even loss of merchant facilities; the card providers take this very seriously.
It checked out - this is the CVV."
I learned this the first time I was implementing a system. They gave me the guidelines and I was like, good deal, no CVV. Pretty easy but how many developers actually ever see real requirements?
That's because you have a brain. You wouldn't believe some of the stuff I've seen people try to use.
So much copypasta, often with just enough changed to be hacked into a customer's system.
While we're on the subject, how do Amazon get a pass for not making the user re-enter the CVV for every transaction?
When you're amazon, you can negotiate anything. They're probably the single biggest online credit card merchant.
AFAIK the CVV is not required to perform a transaction. It's just that you take the hit in case a fraud occurs when you don't check the CVV.
Depends on your merchant account I believe. We tokenize them somehow, and can do further transactions by referencing the first transaction.
You don't need to make the user enter the CVV for any transaction, it just helps with a lower fee and to shift the chargeback liability.
The author doesn't explicitly mention it, but the CVVs were saved as a part of debug logging. That mistake should serve as a warning to others implementing PCI DSS systems.
Debugging or not, you must never store the CVV per guidelines. Send it out, done.
Where do you have that information from? I've seen the theory in the comments on troy's website, but no confirmation of it. My kid's after school program got hit and I'm working with them to translate Regpack's obfuscation of what went on and ask some pointed questions.
Oh man this Troy guy is the hero we need, fighting the good fight.