After scouring the web to find countless similar questions, I still find it important enough to ask based on my client's specific requirements. Now I know most if not all are not a lawyer, but if you've had experience in this field, please share.
- Environment - ASP.net c#, SQL Server
- It's my server on AWS, with multiple client sites on it.
- Site is protected with SSL certificate
My client has requested that I create an onboarding process for their hiring managers, that of which is accessed via private website (username, password) and controlled by security roles as to who can access these specific pages.
This onboarding process can take as little as a day, and as long as a month. They need to store the employee's social security number and other personal identification information during this time, in their website's database. The flow works like this:
- Manager role fills out an initial hire request with basic information
- When approved, manager is notified and completes the rest of the documentation (including SSN)
- Then another manager is notified and goes through the process of background checks and various other enrollments that all require the SSN.
Aside from me being paranoid about any legal requirements of this, the following is what I'm thinking:
- I store a symmetric key in
- Also, instead of storing this key broken up in a few places, take a hybrid approach and when initially encrypting, use the key in
web.configand a few other items (i.e. created date, guid, last name) to encrypt. I was thinking of this approach (https://www.aspsnippets.com/Articles/AES-Encryption-Decryption-Cryptography-Tutorial-with-example-in-ASPNet-using-C-and-VBNet.aspx)
- When client loads the detail view to access this information, in order to see this SSN they enter in one of those partials that I previously mentioned, like
createdin the form of mmddyyyyhhmm and then that pieces the key back together:
mmddyyyyhhmm user input+
So I'm trying to eliminate the possibility of access to this information if a manager's user account on the website was breached. An attacker would have no immediate notion that the created date needs to be entered. At this point it seems the remaining danger is if someone somehow gets access to the sever itself and decompiles the assembly to see how the unique encryption key for each employee is being generated in order to decrypt what's in the database.
Then when the process is complete for that employee the associated record in the database would be removed.
Is there anything blatantly wrong with this approach?