Take the 2-minute tour ×

I am encrypting data (health care industry) using the aes encryption classes in the .net framework. What are some of the recommended locations for safely storing the key? I have it in the web.config for development, but that does not feel production worthy, to say the least.

share|improve this question
add comment

4 Answers

You can encrypt your web.config values using built in methods in the framework:


This is probably a reasonable place to store your key - if somebody has managed to access your server to retrieve these details, then you probably have bigger worries.

share|improve this answer
True. Is DPAPI more "secure" though? –  Saraz Oct 25 '10 at 14:35
@Saraz - Sorry, don't know the answer to that... –  Paddy Oct 25 '10 at 14:46
@Saraz: More secure than what? It's more secure in the sense "is infeasible to recover without administrator-level access on that specific machine" (as the encryption algo is dependent on data that are unique to the machine). In other words, if someone managed to get your web.config, they still couldn't decrypt on a different machine. –  Piskvor Oct 25 '10 at 14:57
add comment

If application requires authentication using your keys then
normal approach on unix machines is to store passwords in hashed form.
You can use sha-512 + salt.

Then you can calculate hash when user inputs password and check against your.

The passwords/key itself can be stored anywhere if its hashed. If not store it in the technical user directory where none has access.

EDIT for those which don't want to put too much effort in understanding USE CASE which i've presented

Johny has some AES encrypted data.
He stores his key in head.
He wants to store this hey somewhere on his PC to automate access.
He can store it as ASCII in web.config.
But he can hash that to be no more ASCII but hash.
During authentication application calculates hash checks is it proper key, then uses this key....
Low probably of collision with proper algorithm.

ps. just posting my point of view on the topic.
Why are you so sensitive for word "hash"???

I know what is hash,
I know what is so called 2-way encryption....

share|improve this answer
Who mentioned passwords? I'd assume the OP wants reversible encryption. –  Seva Alekseyev Oct 25 '10 at 14:32
Indeed, not looking to one way hash ;) –  Saraz Oct 25 '10 at 14:36
I understand everything......seems you didn't understand me. –  bua Oct 25 '10 at 14:41
Re your edit: No. If you hash the key, you can not recover it from the hash (as hashing, by definition, is a lossy transformation). How do you then use a key that is not anywhere on the computer? (That word. You keep using it. I don't think it means what you think it means.) –  Piskvor Oct 25 '10 at 14:51
@Piskvor from application cache.... when there would be any superuser authentication tunneled key sending. –  bua Oct 25 '10 at 14:54
show 10 more comments

What you need to do is hide this key somewhere, and a secure location would be inside a database. Preferably a different database than the one that contains your data. Since data require username/password combinations to open them, you just add a second security layer to your application. Your app would need to log in to the key database, retrieve key X for application Y and is then able to use it. You would have to store the connection string for this database somewhere, though.
Even if you would store just a single key in a key database, it would be worth the trouble. It forces a hacker to take a bit more trouble to open this database to find the key before he can access the data. Since there's no perfect security, your options are just limited to delaying the amount of time it would take a hacker to gain access.
Encrypting the web.config file or data within it will also help to delay the hacker but if the key is inside the config file, all he needs to do is decrypt it again.

share|improve this answer
This is not really any different to storing a key in the config file - you need to store the connection string to your key database somewhere, and if your hacker has access enough to get to your config file, he will probably be able to get this... –  Paddy Oct 25 '10 at 15:01
True. But it adds a second layer. You need to access the database to get the key and in general, databases are stored on a different system. If the database server is set to only accept calls from the web server location, you make it more difficult for a remote hacker to get access to the key. And if the database stored a few hundreds of (dummy!) keys then the hacker still doesn't know which one to use. –  Wim ten Brink Oct 25 '10 at 15:07
add comment

One approach which will provide good security if the only people who will need to use the key for any purpose can be trusted absolutely with it is to store the key encrypted with another key, a copy of which is stored for each user, encrypted with a hash of that user's password (salted differently from the one stored for password validation!). Even an evil person with access to every bit of data, anywhere in the universe, associated that database's key, would be unable to access the database without reverse-engineering at least one of the passwords.

Note that if the passwords for all valid accounts were ever lost or forgotten, the data would be irretrievable. That's part of the nature of real security. If one wants to avoid the possibility of losing data, one must ensure that backup copies of the necessary keys and/or passwords are stored securely.

share|improve this answer
add comment

Your Answer


