Legally breaking the DSS

[npuetz]

All,

I ran into a very interesting situation today. I was working with a client and they asked about a new credit card accepting application that they are rolling out. What is different about this application is this...

1. The user is presented with a client side java script form to enter their cardholder data into.

2. Once they hit submit, the java script will cut the credit card number in half.

3. The script with take the first half of the number and email it to a customer order processing account that the client.

4. The script will then take the second half of the number and store it in a database.

To process the transaction, a customer service rep. will open the email and access to the database to determine the full card number. The order will then be placed using a separate, already PCI compliant, application. Does the java based application need to be PCI compliant? The application doesn't process or transmit a full card number ever. Technically, it stores a full card number in memory for less than a second; however, this occurs on the client side.

[lyalc]

The server-side java app is in scope for PCI.
Things like logging, password handling/storage/complexityrules, error handling etc still need to be addressed.
If there no (including logs) storage of card numbers by the app, the section 3 requirements may be easily addressed.

Database access controls and auditing remain in scope as well.

Also, the network traffic from browser to the web server will still need to encrypted (Javascript can only send to the server from which it was served).

I'd be uncomfortable about this, although PCI doesn't get too detailed on certain risks. e.g. if someone stole the DB records with the 'half-PAN', its likely (intuitive guessing here) that the PAN could be derived with reasonable to high accuracy by simply guessing the other half based on published BIN ranges, and seeing if the check digit was valid.
Does this obfuscation method really add long term protection to the PAN?

Lyal