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.
+1
A:
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"???
EDIT 2
I know what is hash,
I know what is so called 2-way encryption....
bua
2010-10-25 14:30:33
Who mentioned passwords? I'd assume the OP wants reversible encryption.
Seva Alekseyev
2010-10-25 14:32:15
Indeed, not looking to one way hash ;)
Saraz
2010-10-25 14:36:38
I understand everything......seems you didn't understand me.
bua
2010-10-25 14:41:40
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
2010-10-25 14:51:21
@Piskvor from application cache.... when there would be any superuser authentication tunneled key sending.
bua
2010-10-25 14:54:25
@bua: the question is not about authentication. His application needs to encrypt data which will be decrypted by another application. To do this he must use an encryption key.
egrunin
2010-10-25 14:58:29
@ Seva Alekseyev , I'd assume he has 2way encryption already and wants to keep key safe...
bua
2010-10-25 14:59:46
@egrunin you are another one thinking not 'out of the box'....think about architecture. Please, authentication can be internal application process..
bua
2010-10-25 15:01:08
bua, to keep a key safe, a hash is not a solution since then the key is gone. 2way encryption would work but we're talking about a key that's used for 2way encryption, so you'd end up with a second key! Letting the user provide a password makes no sense if it's just the application that needs to know the key. There might not even be any user interaction. We're just talking about an encryption key that needs to be stored by the machine. So, where to do that?
Workshop Alex
2010-10-25 15:03:32
@bua: Ok, that would work...except that a human operator will have to authenticate as superuser on every boot. That may be possible, but is it practical for a web server? (Since we're going to these lengths for security already, I can't imagine that the system could be accessed remotely by the superadmin. "Hello Johny, I know it's 3 AM, but the server crashed and we need you to drive here and input the password to boot it.") Then your problem shifts to "who has the password?", which could become the age-old "password on a post-it note on the bottom of the keyboard".
Piskvor
2010-10-25 15:05:57
@bua: You could set up a system where the password for the master key is stored on a paper in a physical safe, but at that point you'd be better off with a RSA keyfob, as the password becomes "something you have". While this would provide commendable security on the computer side, it will merely shift the problem to physical security (which *may* be simpler to manage, but *will* be more expensive).
Piskvor
2010-10-25 15:07:41
@Piskvor now we are on the same page :) cheers.
bua
2010-10-25 15:15:32
@bua: If this is done right, it could be workable. If the server needs a reboot, something is Seriously Wrong anyway; the procedure becomes more complex, but it's manageable. Since we're talking HIPAA data here, the increased hassle may be worth the increase in security (although other attack vectors won't change, but that's not the point). (Glad we sorted that out :))
Piskvor
2010-10-25 15:16:52
@Piskvor yes too much unnecessary overhead, my imagination went too far, but I've assumed that it might be interesting.
bua
2010-10-25 15:21:34
+4
A:
You can encrypt your web.config values using built in methods in the framework:
http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx
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.
Paddy
2010-10-25 14:33:19
@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
2010-10-25 14:57:10
A:
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.
Workshop Alex
2010-10-25 14:57:24
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
2010-10-25 15:01:18
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.
Workshop Alex
2010-10-25 15:07:39
A:
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.
supercat
2010-10-25 16:00:01