CV2 versus Confirmation

The PCI DSS is clear on how to handle CV2 (also known many other acronyms: CVV, CVV2, CVN, CCV, CVC). You may not store this number "subsequent to authorization", not even encrypted. This means the number is highly sensitive. It is treated as the one true anti-fraud measure for Cardholder Not Present transactions. Of course, this is slightly odd - it's written right there on the card for any old waitress to see - but the Payment Card Industry makes the rules and this is the rule they've set.

The user friendly model for e-Commerce payment is this:

Confirm these purchases -> Enter credit card details -> Please confirm that all of the above is correct -> Thanks, here's your order confirmation.

The final confirmation is vital for making sure customers are informed about exactly what they're agreeing to. Customers, en masse, are stupid, and they often get to this stage before realising they've messed up something. The difficulty then is that the request where the web application received the credit card details is different to the one where the customer authorises it to go ahead. This means that the credit card details must persist for at least one request. In the unhappy world of statelessness that is HTTP, that translates as 'indefinitely'.

To investigate how other software tackles this I've come across a startling lack of awareness in open-source shops.

First I looked at Satchmo. Satchmo stores CV2 unencrypted in the database. I couldn't see any code that deletes it after authorisation. It also stores the card number (PAN) encrypted symmetrically with a key from the settings file. This is incredibly naïve! A compromised server would compromise the card information for the entire order history.

Then I looked at osCommerce. Unbelieveably, osCommerce appears to return the CV2 to the customer... in the address bar! Where it will be stored in the browser's unencrypted history for maybe 90 days.

These are the technical options as I've thought of so far:

1. Send a PreAuth request to the gateway when you have the details and a PostAuth when they confirm. I had thought this was the unequivocally correct way - now I'm not sure. A PreAuth request isn't an uncommitted payment authorization: funds are reserved on the card when the PreAuth is requested. Moreover, if there is an error on the confirm page that affects the amount to be billed, you need to re-request the card details. In essence, a PreAuth is a more binding transaction than the customer feels they have entered into at this stage.
2. Encrypt the card details with symmetric encryption and send them back to the browser in a hidden field. This is quite elegant, in that it remove the specific problem the PCI DSS is trying to tackle: that a compromised server potentially compromises all credit card details held. It's still encrypted storage, though in this form it may well fall under encrypted transfer. It's permissable to transfer CV2s as necessary, provided there's strong encryption.
3. Encrypt the card details with symmetric encryption as above but keep the encrypted blob and give the user the key. The cryptographic strength of this protocol is only as good as the previous if the keys are cryptographically random, but it is what the PCI DSS mandates you don't do, assuming the strictest intepretation of the standard.
4. Only request the CV2 on the confirm page. This could seem quite natural, if expressed as "Please enter your CV2 number for this card to confirm the transaction". It doesn't really help secure the other card details.
5. Don't show a confirm page, or at least combine the confirm page with the form to submit credit card details, and add a big red button saying "Place this order".

Given these the only option that I am personally happy with is 2 so that is what I intend to implement. I don't like the PCI DSS, incidentally. I don't like global financial companies mandating what the little people must do to protect their profits. I don't like the way it's written - describing what you mustn't do without offering it's view of approved methodologies. I think it's paranoid about network security, it overstates the benefit of firewalls, and it's not comprehensive enough about application security. But I like security and I'm tolerant of this PCI DSS for that reason.

I'd very much like to hear if anyone has a better solution or a different opinion.