ASP.NET Database Security and Encryption

mickdoc used Ask the Experts™
My company is programming a web application, accessed through a browser via SSL only. It has an authentication database that contains, among other things, usernames and passwords (hashed of course!). Authentication is taken care of by the auth provider.

Once logged in to the authentication database, the user is presented with a control panel that lists all the apps they can access. If you are allowed to see it, one of the apps will be a high security database system. I say "will be" as I haven't written it yet.

There are some strings attached to this:

Our company cannot have anything to do with the security of this system ie it will be encrypted and the customer will be the only one to have the password.

Let me give you an example:

(Remember all this is done over SSL only)

The customer creates a new high security database (We will provide a web form for this)
They input a password
Whenever they go to access this database they click the link (they will only see a link if they are authorised through the auth database detailed at the start)
A password box appears and they type in the password for the high security database
They then have access via our web forms to the contents of the high security database

*I am saying we use a modal password dialog box but there may be a better way... I'm open to suggestions.

Up until now, I have only done moderately secure systems, requiring hashed passwords, SSL, ASP.NET auth provider etc. This is the first time I have had to do a highly secure system like this with data encrypted by the client only and am unsure how to do it, well, securely!

The authorisation database will use SQL Server 2008 R2 but I thought of using SQL Server Compact 4.0 for the high security system as space is not an issue and 4GB will be way more than I need but I can use almost anything (low cost only so no specialist hardware or anything but full blown SQL is not out the question, nor is something like Firebird etc)

The security on the server and the datacenter is taken care of too so that part is ok. The servers are also well locked-down too.

I have thought of a few options and would love some feedback:

Option 1

User creates db
Enters password to encrypt
We create a salt and store it in the authorisation database
We hash the password (with the salt) before it is used to encrypt the database (CE 4.0 will hash it also using SHA512 I believe)
A user comes along and opens the high security system and inputs the password
We hash it and add it into a connection string
This connection string is used to access the high sec db for that session.

Problem: Where is the password / connection string stored for that session as session vars will probably not be advised and the password is sent across the wire?

Option 2

User creates db
Enters password to encrypt
We create a salt and store it in the authorisation database
We hash the password (with the salt) before it is used to encrypt the database (CE 4.0 will hash it also using SHA512 I believe)
A user comes along and clicks the high security system link and inputs the password
We store the hashed password in the secure auth cookie
Cookie is used each time the user accesses the database

Problem: Password is passed across the wire

Option 3

User creates db
Enters password to encrypt
We create a salt and store it in the authorisation database
We hash the password (with the salt) before it is used to encrypt the database (CE 4.0 will hash it also using SHA512 I believe)
We store the hashed password in the other database and as long as the user types in the correct password when he first opens the database he then gets access

Problem: We have a copy of the password on our servers, albeit hashed

We need to secure the high security database but we want to be able to say that "we cannot possibly see inside the customer high security database as we don't have a password"... I am unsure how to create a database like that without having the password stored somewhere on our kit.
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Grant SpiteriSenior consultant


Create yourself a wcf security service  that encrypts data (in this case password) with AES 256 encryption.

if you have the pipe or msg encrypted SSL + the password residing in the db but it is aes256 encrypted i honestly wouldnt worry to much to be honest, if the security is at the point of top secret i would invest in Hardware encryption and once again have your security service consume the hardware api and do the same thing.

This is the scenario i have use for a pci compliant security service the only difference was the initalise vector and master key were stored on 1 server(for non hardware version), the security service on another server and the hardware device obviously separate
@gspiteri, can you please help me understand how having a WCF security service to encrypt a password will be better than having a simple class on server-side that provides AES encrypted data.
-Modal password dialog box looks good to me as well.

-I would prefer SQL Server Express 2008 over SQL Server Compact 4.0/3.5SP2. So because Express gives more programmability support like Procedural T-SQL. You may like have a look at this link Still which DB to choose depends on your projects current and any possible scalability/performance future needs.

-Your browser to server traffic is over SSL. So I don't think there is much to worry when "Password is passed across the wire".

-I am really skeptical about how much correct will it be to say that "you cannot see inside customer's high security database" when your application is an intermediary between high security database and the browser. It is your application that will have to connect with the high security customer specific database and provide user access to the contents of the high security database. If your web-app can connect with the database means you know how to look inside customer's database! Please correct me if I am misunderstanding anything you wrote.
Rowby Goren Makes an Impact on Screen and Online

Learn about longtime user Rowby Goren and his great contributions to the site. We explore his method for posing questions that are likely to yield a solution, and take a look at how his career transformed from a Hollywood writer to a website entrepreneur.

Grant SpiteriSenior consultant

Jagrut for 1separation of concerns, 2 different boxes having the security service sitting behind a firewall on an app tier that is not publicly exposed and 3 reusability for future applications that require encryption regardless of what platform or medium
Thank you gspiteri. Those are certainly the benefits of a service layer in-general but my question was more from the standpoint of the original question of this post.

Since I (or we) don't know mikedoc's complete project requirements it won't be fair to further discuss benefits you suggested about having a WCF encryption service.


Encryption h/w is too expensive so we will have to rely on software-based encryption. As for WCF, it is something we will look at in the future if it's required. We have logical tiers in the apps but we haven't physicall separated them like using a bunch of app servers between the web servers and databases.

You are right that we can technically see inside the DB but only when the customer has opened it. Even then we would need to read the server memory at the time etc... logistically it's going to be a total nightmare... It just needs to be almost impossible to see inside it. If it's encrypted with their password then that's good enough. It's not for military customers, or even close to that level of security so Top Secret documents won't be stored in it. It's just something that some customers will find immensely valuable and will want assurances that their guys will (in all practicality) be the only ones that can get to it, hence the reason I thought that SQL CE 4 would be ideal (they wont be using anything like 4GB)

My main concern was the passing across the wire of the password and its implications and how that would look when we explain it to the customer (and they will ask :))
Grant SpiteriSenior consultant

Ok so simply run AES 256 encryption to encrypt the password, let the client know you are using the latest and greatest of software encryption simple.
1. "My main concern was the passing across the wire of the password and its implications"
Again, you already use SSL so client to server communication will be encrypted. I don't think anything more than SSL can be done for this particular concern! Customers should be happy to know that. You can compare your HTTPS implementation with any banking websites.

2. As I wrote SQL CE doesn't support Procedural T-SQL. I was expecting your comment about whether or not that is will be a concern for you. Please study the comparision given at the link I gave in my first post.

3. You can store your application's log-in password in encrypted form. You may use any well-known "one-way" encryption algorithm for this encryption. However, if you plan to use user provided password for database connection I think you will have to encrypt such password's with an algorithm that allows decryption as well. I usually will avoid such "two-way" encryption algorithm.

So for DB password I will adopt following policy:

a. DB password's won't be passed on the wire. This prevent's majority of the threats.

b. DB password's will be auto-generated and stored in authentication DB. If you want you can encrypt it using any "two-way" encryption algorithm of your choice. If you encrypt you can atleast tell your customer's that even DBA having access to authentication DB cannot see these passwords. Only your program can decrypt it.

c. User wanting  to connect with the DB from web-site (with the link) will have to provide one more password, lets call it password2. Remember this won't be the actual DB password. When password2 is saved, DB password will be auto-generated on-the-fly and the
"user <-> password2 <-> auto-generated DB password" mapping can be saved into authenticaton DB.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial