Encrypting/decrypting data to database

Question

I need to create a .NET application that will store some confidential information to the database (e.g. passwords and stuff). I could use symmetric encryption to encrypt these before I store them to database but if someone de-compiles source code symmetric password could be compromised.

Since this is going to be service application I cannot ask a user to provide symmetric password. I also cannot use a password that is Machine related as this data will be read from different computers.

What would be the best way to do this?

Update: Hashes does not work for this case... cause someone needs to enter valid password to validate it against hash and this is not the case. Information must reside in the database but it will be retrieved by windows service applications (no users here). There is no one to enter password and validate it against hash, so I need to retrieve the original password...

Answer 1

Store the password as a one-way hash. When a user enters a password for validation, hash their attempt the same way as the password and verify that the hash results match.

Here is an example in Php, but the concept is the same regardless of language: How to store passwords in databases

Edit

You may want to look into encrypting at the database level. I'm assuming your using SQLServer: http://msdn.microsoft.com/en-us/library/cc278098.aspx

Oracle has similar encyption techniques where the application using the table is unaware of the encryption. If you pair this with encrypted connections by your service to and from the database, you should accomplish what it seems like your after.

Answer 2

When hashing the passwords, the decompiled source code won't give your hackers any chance of breaking passwords.

Answer 3

So you have an application that needs to encrypt/decrypt data, but doesn't require the users to enter passwords to use it? First off, that sounds like a security hole right there - a hacker doesn't need to get the key or a password - they just need to get the application.

In order to do this securely, without storing the key in your application code, you would have to have some kind of password that came from the user that you could use to encrypt/decrypt the "real key" that is used to encrypt and decrypt the actual data.

If you are using a service to access the data, and no password is entered, you could generate a unique string from the machine information and use that as a type of password to encrypt your key.

To do this on multiple machines, each machine would have its own "password" generated from the machine information. This password would be used to generate a key (unique to that machine) which would then be used to encrypt a shared key (which is used to encrypt the actual data). This information would be stored in the database in a simple table with two columns: MachineID and EncryptedSharedKey.

At startup, the service would examine the machine info, generate its password, use that to generate its key, and use that key to decrypt the shared key from the database table. It would then be able to use that shared key to encrypt/decrypt data.

When you set up a new machine with the service, you would have a separate program that would read the shared key from a text file, generate the machine key, create a row in the table with the machine id and encrypted shared key, then delete the program and text file with the un-encrypted shared key in it.

This would be reasonably secure against someone copying your program to another machine, but really just relies on obscurity. If someone figures out how you generate the machine key, and has access to one of the machines with the service on it, they could generate the machine key themselves using the info from the compromised machine.

Answer 4

You could use Database Level encryption (assuming Sql Server since you said .net) and use Encrypted Connections to Sql Server. This takes care of protection of data while in storage and in transit to the application server.

This takes care of security without any special passwords -- it's based being able to authenticate to the database server. Same as you would have to without encryption.