Answers.Body: <p>Hitting the right keywords is always fun.  Here's a partial answer, from the how-to side of the question.
  <a href="https://civicrm.stackexchange.com/questions/651/is-there-a-way-to-encrypt-a-single-field-in-civi-database">Is there a way to encrypt a single field in Civi database?</a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-20T15:55:47.507Z
Answers.LastActivityDate: 2016-06-20T15:55:47.507Z
Answers.LastEditDate: 2017-04-13T12:53:13.207Z
Answers.UserDisplayName: G H
Answers.Body: <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-20T15:39:49.253Z
Answers.Text: I fully agree on all points.  Can I assume that this means that you are not doing any kind of database encryption?
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-20T15:34:47.670Z
Answers.LastActivityDate: 2016-06-20T15:34:47.670Z
Answers.UserDisplayName: KarinG - Semper IT
Answers.Body: <p>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:</p>
  
  <ol>
  <li><p>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.</p></li>
  <li><p>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.</p></li>
  </ol>
  
  <p>I think your conclusion (roll your own using the Civi-supplied Crypt object) is probably the right answer.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-20T20:28:18.603Z
Answers.Text: 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?
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-21T14:37:41.963Z
Answers.Text: Sounds like you have the right attitude here, so let's stop this discussion that might attract undue attention ...
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-20T20:02:25.833Z
Answers.LastActivityDate: 2016-06-20T20:02:25.833Z
Answers.UserDisplayName: Alan Dixon
Body: <p>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.  </p>
  
  <p>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.</p>
  
  <p>Yes, I'm aware of CiviHR, but having a completely separate install and database means a lot more complexity than seems feasible.</p>
  
Tags: <wordpress><custom-fields><database><mysql><security>
Title: Storing Personally Identifiable Information
ThreadText: # Storing Personally Identifiable Information
  
  (Asked by: username_0 on 2016-06-20)
  
  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.
  
  **Tags:** wordpress, custom-fields, database, mysql, security
  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_0 on 2016-06-20. Score: 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?](https://civicrm.stackexchange.com/questions/651/is-there-a-way-to-encrypt-a-single-field-in-civi-database)
  
  
  ---
  
  ### Answer by username_1 on 2016-06-20. Score: 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.
  
  > **Comments:**
  > **username_0**: I fully agree on all points.  Can I assume that this means that you are not doing any kind of database encryption?  
  
  ---
  
  ### Answer by username_2 on 2016-06-20. Score: 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.
  
  > **Comments:**
  > **username_0**: 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?  
  > **username_2**: Sounds like you have the right attitude here, so let's stop this discussion that might attract undue attention ...  
  
  ---
  
  