2

Is anyone storing Personally Identifiable Information (PII), such as Social Security Numbers (SSN), in their database? How would I encrypt such a field in the database? I'm expecting that it would be a custom field that is part of a Custom Data Set attached to a contact. However, I've not seen a way to simply encrypt the stored data in the database.

Encrypting the whole database wouldn't be a bad idea, and any ideas about that would be great too, but it seems like these types of fields need their own key sets in addition to anything else.

Yes, I'm aware of CiviHR, but having a completely separate install and database means a lot more complexity than seems feasible.

Improve this question

3 Answers 3

Reset to default
2

We're in Canada - but no we don't store SINs for any of our projects. We don't store Credit Card numbers (PCI compliance dictates that) - and one could argue that having your SIN/SSN stolen is far more serious than having your Credit Card stolen. Storing SSNs would substantially increase the risk that a breach would be considered a major privacy breach.

Improve this answer
1
  • I fully agree on all points. Can I assume that this means that you are not doing any kind of database encryption?
    – G H
    Commented Jun 20, 2016 at 15:39
2

Hitting the right keywords is always fun. Here's a partial answer, from the how-to side of the question. Is there a way to encrypt a single field in Civi database?

Improve this answer
2

Encryption is fascinating, but when you think it through, it's often not as attractive as you might want. Basically - you've got two kinds of encryption:

  1. symmetric encryption - a robust and fast encryption, but to be done programmatically requires the use of some key that must be stored on the machine in the first place - meaning if you have full access to the machine then you've really only got security by obscurity. But that might be all you want anyway.

  2. assymetric encryption - this is was ssl is all about, i.e the ability to have a secure conversation with someone with whom you don't have apriori a shared secret key with. But this isn't going to help either unless you're encrypting things programatically that don't need to be unencrypted programatically. If you want to basically receive secrets that can only be unencrypted off line, or with a manually entered secret key, then this would be cool.

I think your conclusion (roll your own using the Civi-supplied Crypt object) is probably the right answer.

Improve this answer
2
  • Yes, and in the same vein, security is the farce of a cat and mouse game where you are essentially attempting to make yourself less of a target than the next guy. Hence the question, how juicy of a target at what expense and how do you mitigate the maximum amount of risk at the lowest cost?
    – G H
    Commented Jun 20, 2016 at 20:28
  • 1
    Sounds like you have the right attitude here, so let's stop this discussion that might attract undue attention ...
    – Alan Dixon
    Commented Jun 21, 2016 at 14:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.