I have been given the task to rejuvenate an existing Human Resources application from Access into ASP.NET. This is a strictly internal application, and I have no problems developing it within our standard ASP.NET environment. It does however pose it's own problems, both technically and ethically.

The HR app will be responsible for storing employee pay data, for which it is not appropriate for me, the developer, to see. It's essentially three fields (salary band, actual salary, comments) and four other values, calculated on the front end.

I'd like to go down the cryptography route to encrypt said data - cryptography with the .NET Framework is very easy to implement. I could "roll my own", which as we all know is a bad idea. However I was wondering if there was a more better way of doing it. Here are some points:

  1. For starters, we're all attached to the same domain.
  2. I've heard and read about Certificates, can they be useful here? (x.509?)
  3. The data will be stored in our local SQL Server, obviously the actual data here needs to be encrypted, so can SQL Server help me? Certificates again?
  4. If a user doesn't have the appropriate certificate, can the data just be null? (You can't see this matey!)
  5. This encryption problem doesn't have any relevance to usage of the system via a permissions model.
  • 1
    Views and permissions? – Peter Taylor Aug 4 '11 at 11:26
  • @Peter Thanks! There is aspect yes, we use that on our other system. However the difference here is that I am writing the system in its entirety which means I have access to everything, I'm trying to protect myself - from my own software - but I'd prefer not to obscure myself from the actual data schema itself... – Tom Aug 4 '11 at 11:34
  • 1
    can't you develop it with test data? Or, at worst, take a copy of the DB and then UPDATE tblWhatever SET Salary = RND() before you do anything? – Peter Taylor Aug 4 '11 at 12:04
  • 1
    I can and will almost certainly do this, however I will be responsible for both developing, deploying and maintaining the deployed database, so keeping that data secure (from my eyes and many other eyes) is essential. – Tom Aug 4 '11 at 12:48
  • I think this question would be better on security.stackexchange.com. (You can flag it for moderator attention to move it there, if you see this, too. Don't simply repost it, though.) – Paŭlo Ebermann Sep 3 '11 at 14:12

This sounds to me like the same issue as credit card data in pci certified systems. You as a developer and later on the sysadmins and support staff are not allowed to see the data. Read into how people solve that problem and it should solve yours.

It comes down (a really short description) to encrypting each row with different keys and an environmental key. The environmental key should be stored only on the app servers, the per row key can be stored in the database. This way, someone with only database access cannot decrypt it, someone with only appserver access cannot decrypt it. Make sure that production and dev/test are not using the same environmental keys. So, a production database going back to dev or test for debugging purposes cannot be decrypted because dev does not know the production key. Still you can reset all data in the database (production backup downloaded for testing) with a single sql update (point it to a single per row key and use the dev encryption key and set everything to the same encrypted value).

Have a tool to replace an environmental key (decrypt with old and encrypt with new the data) if it might be compromised (or an employee having access to it leaves.)

There are a lot of sites with information on these pci standards and implementations. Read into it and you will certainly get an implementation which would work for your problem.

The encryption algorithm itself does not really matter, as long it is a known strong method


Your comments indicate that you are "writing the system in its entirety which means I have access to everything". Can you not lean on your IT team here?

  • Ask a current user of the Access database to make a copy of it and replace everyone's salary with $10,000 (for instance).
  • Develop the application on your workstation or on a development server.
  • Provide a proper security model to ensure that the correct users (aka not you) can see what they need to see
  • Provide a tool to allow an administrative user to enter the proper salaries
  • Get IT to deploy the application and enable something like SQL Server's TDE on the production version

Additionally, using something like Microsoft's WIF or ADFS to provide single sign on is also a good idea given that you indicate your users are on the same domain.


If you just want to hide clear data from eyes - store encrypted information in database and decrypt it when necessary. You can use asymmetric alghoritm and store private key in file that can be accessible only for several users. This approach would require additional code to search/sort/filder the information, but it will be secure.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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