Storing Social Security Numbers

前端 未结 11 1116
渐次进展
渐次进展 2021-02-03 23:48

The HR department at the company that I am currently working for has requested that I provide a system for storing employee social security numbers in our company database. The

相关标签:
11条回答
  • 2021-02-04 00:23

    Social Security numbers fall under "PII" (Personally Identifiable Information)... and you should encrypt them, but it's not required. So, yes AES is perfectly fine... really, anything you do is a plus.

    Credit Card numbers fall under "PCI" (Payment Card Industry) compliance, and that is a mess. But in your case, you're ok.

    BTW: AES 128 is considered perfectly good enough for Visa, Amex, Discover, etc (PCI).

    0 讨论(0)
  • 2021-02-04 00:29

    The best method I've seen for storing sensitive data is public key encryption, and storing the private key somewhere other than the database (say, through an application only available to the head of HR and the CEO):

    Then we started storing people’s credit cards…but out on the website we’d immediately encrypt them with a public key. ...

    On the backend, we had the private key, and with the right pass-phrase we could temporarily decrypt [the private key], then use [the private key] to decrypt a credit card, and charge the card for a DVD.

    0 讨论(0)
  • 2021-02-04 00:33

    My recommendation would be to rely on limiting access. Only have a single account able to actually read (and if necessary write) the table where the SSN's are stored. Use that account from within your application to access the db and block access from every other account.

    0 讨论(0)
  • 2021-02-04 00:36

    My recomendation: store your MySQL data on encrypted disks, so that in the event of laptop misplacement, etc, the data cannot be retrieved.

    If the database application itself is compromised, of course, nothing can help, as the application itself uses the SSNs. Perhaps that is a design flaw you can correct. I would tend to think in terms of a small, limited application that maps SSN to a (non-SSN) key, and then using that new key as the "user ID" in your database rather than the SSN. I would avoid proliferation of the SSN itself at all costs.

    0 讨论(0)
  • 2021-02-04 00:36

    MySQL has a number of encryption functions that you can use to encode/decode. They should be sufficient for an internal application.

    0 讨论(0)
提交回复
热议问题