VbzCart/docs/pieces/security/customer

Purpose: a description of requirements for securely storing sensitive customer data, and any design details necessary to accomplish those requirements

Note that "customer data" is distinct from "access credentials", i.e. (most commonly) the username and password used by each customer to log in and access their account.

Goal

Intruders must not be able to reconstruct sensitive customer data (SCD) from a copy of the VbzCart database alone.

Ideally, reconstruction of SCD should require breaking into two separate systems and copying specific files/records from them. Ideally, one of these systems should not be directly accessible from the internet; if it needs to be internet-accessible some of the time, then its availability should be limited as much as possible, and should not be required for unattended operation of VbzCart (i.e. people should be able to make purchases even when that second system is not available).

Sensitive customer data includes:

• account numbers at any financial institution, such as a customer's:
  • credit card number
  • PayPal username (email address)
  • bank account number
• customer contact information (address, phone, email)

In order to facilitate matching, searching, and reality-checking, some parts of the SCD should be kept in unencrypted form as well:

• last 4 digits of account number
• credit card expiration date
• street number, postal code, country, area code, email domain

Implementation

SCD stored on disk (rather than in RAM) will be encrypted using public-key encryption. This allows decryption ability to be uncoupled from encryption ability -- that is, the private key can be made very difficult to access without impeding the ability to encrypt using the public key.

The private key can be kept on a separate computer, and need only be accessed during the following operations:

• charging of credit cards, debiting of bank accounts, etc.
• printing of shipping labels and packing lists
• initiating contact to the customer (email, phone, letter)

We'll call this computer the "key server".

Key Server

There are several ways of handling key computer security; different levels of sales traffic will probably call for different methods, so we will not hard-code any specific method into VbzCart so that administrators will have the flexibility to pick the best method for their deployment and to update it as their sales traffic changes over time.

method 1: manual entry

In this method, staffers needing access to SCD would enter the private key manually into a web form. The server would receive the private key securely (https), do the decryption, and return the decrypted data without ever committing the key to permanent storage.

For this method, the private key should probably be a memorable phrase, or at least something that isn't nearly impossible to type.

Disadvantages:

• Staff could easily learn the private key, requiring complete re-encryption of data anytime there was any concern about the key being safe (e.g. anytime an employee left).
• Typing in a security key repeatedly would be very arduous, unless a desktop or browser-based application were developed to handle this.
• This approach would be more vulnerable to "social engineering" attacks, since staff would know the key, a staffer might presumably forget the key and need to ask another staffer to remind them of it, etc.
• The key would be easier to guess (brute-force attack), since it couldn't just be an arbitrarily-long random sequence of numbers.
• There would need to be some code review/investigation to ensure that the underlying libraries (e.g. form-submission, form-processing, or decryption) didn't ever write the private key to disk even temporarily.

Advantages:

• The private key would (theoretically) never be stored on disk, and thus would be much more difficult to hack remotely.
• Coding to handle retrieval of the private key would be essentially zero.

method 2: key stored on client machines

In this method, there would need to be something on the client machine which could respond to queries from the main server by either returning the private key via a secure protocal or (better) by doing the decryption locally.

Disadvantages:

• I'm not sure exactly how this would work. It might require a custom web client, or at least some kind of browser-specific plug-in to be written.
• Client machines might be compromised by malware unintentionally downloaded by users.
• Anyone with root access to a client machine would have access to the private key.

Advantages:

• The private key could be quite strong, as no memorization or keying would be necessary.
• There would be no special hardware required to enable decryption on a given client machine.

method 3: key stored on dedicated hardware

In this method, the key server is a separate (and possibly quite inexpensive) machine which knows the private key and never reveals it, but will decrypt data on request originating from machines specifically known to it.

The key server could be on the same LAN (behind a firewall/NAT router) as the clients, and in that case could be configured to only accept requests from within the same LAN -- thus preventing unencrypted data from ever being sent over the public internet and restricting any usage of the key server to known physical locations.

The key server hardware could be not only inexpensive (e.g. an outdated PC running a small-footprint Linux distribution) but even physically quite small, e.g. a Raspberry Pi. For sufficiently small hardware (such as the Pi), the key server could become, in essence, a "hardware key" (of the type which used to be commonly distributed with expensive proprietary software such as AutoCAD) that could be attached directly to each authorized client machine.

Disadvantages:

• There would be some extra hardware required at each location.
• The client machines would probably need some specialized software in order to display the decrypted data. I'm not quite sure how this would work.

Advantages:

• Very tight control of access to decryption.

Links

• Getting Started with PCI Data Security Standard Compliance