Storing encrypted personal information - common sense?

Question

Hi everybody,

We're in the middle of developing a e-commerce application that will be used by our customers on a pay-monthly-plan.

We have thought a bit about offering encryption of all personal data that is stored in the database, to make our application a notch safer to the final consumers.
The encryption would be handled completely transparent in both front and backend and make sure that even if someone would gain pure database access, it would be impossible to decrypt the personal details of the final consumers without the encryption key.

Is this common sense, or are we taking on a too big bite to chew compared to the increased safety this would add to the final customers?

Answer 1

My answer is: Sometimes. I've worked for a few companies that employ e-commerce solutions. Security and Encryption need to be better than what the information is worth. Names and address not as "valuable" than say credit card numbers and transaction information. The setup I'm most familiar with is one where all general CRM data - names, address, etc - that is typically fetched more frequently are stored on servers databases - plain text - and the security for the server is increased (Firewalls, patches, etc) and the script accessing the database is of course - secured to the best of the developers knowledge.

Credit card, transaction information, the real down and dirty "information people would want to steal" was contained on a server - encrypted, secured, and only available via local lan. The encryption key was on a second server access to these machines was dictated by a rotating authentication key that only a third server knew. The two key/data servers were unaware of each other. When purchases were made the third server - accessed by a forth - would "magically" make it all come together to complete the purchase.

It's a very convoluted, and terrible answer. In short - protecting/encrypting the very sensitive data is a must is you wish to ensure your customers protection from theft - but ALL information may be an unnecessary overhead for your application. Security is only worth what the data is worth to the thief.

Answer 2

Doing this you lose many of the relational database advantages (searches, reports for the business intelligence and so on).

Furthermore, if you store the keys you just add a layer of 'security': an attacker will have to obtain the keys in order to read the data, but if he has full access to your database, he probably has access to the keys' repository, too (as must have access to that repository the frontend and backoffice applications).

If you instead give the users the responsibility to store their own keys, you lose the possibility to restore the data in case an user lose his key.

Get the real sensible information, put it in a separate server, put as much security as possible around it and acces the data only when needed.

In my opinion the main threat of your approach will be the (false) sense of security that the encryption will give. Sensible data must be treated with all the due caution in storing, but also during elaboration and use: put your money in good system administrators, prepared software engineers and periodical security assessments, if your business require.

Answer 3

Why is it safer?

You need to store the decrpytion key in order to provide that data to the user - it's not really relevant that its only held in the 'front-end' system - in order to get to the back end a hacker must get through the front end first.

You also eliminate a LOT of the searching functionality.

You have to do a lot of coding to imlpement this.

You're placing much heavier demands on the system (i.e. more hardware cost, poorer performance).

IMHO your money and time would be better spent on improving security elsewhere.

C.

Answer 4

I might be out of my depth here, as I'm not a security expert, but here's a few questions that come to mind:

• What are the chances of an attacker gaining access to the data?

• Does the data contain anything confidential?

• What could an attacker stand to gain from accessing the data?

• What could you, or your company, stand to lose if an attacker gained access to the data? It's not just the data, it's potentially your reputation too.

• How much will it cost to implement?

• What are your legal obligations with regard to customer data?

• If data are encrypted using a single global key, how will you keep the key safe?

• If the key is really safe, how will you use it to encrypt and decrypt data?

• If data are encrypted using multiple keys (perhaps one for each customer login), how will you recover data if a customer loses their key/password?

• If you are able to recover customer data, how does that affect its safety?

• What access will computer repair technicians, sysadmins, etc., have to your database server, and how will that affect data security? (It's not just about external hackers).

• What are the performance effects of encryption and decryption?

• What other mechanisms, like firewalls, physical security and employee vetting can be put in place?

Here's a quote from the UK FSA Your responsibilities for customer data security (pdf):

Getting data protection wrong can bring commercial, reputational, regulatory and legal penalties. Getting it right brings rewards in terms of customer trust and confidence.