views:

110

answers:

6

Here's the situation: we have a common library which can retrieve database connection details from a central configuration store that we have setup. Each application uses this library when working with a database.

Basically, it will call a stored procedure and say "I am {xyz} application, I need to connect o " and it will return the connection details for that applications primary database (server, instance, database, user, and password).

How would one go about locking that down so that only application {xyz} can retrieve the passwords for {xyz} databases (there is a list of database details for each application... i just need to secure the passwords)?

+1  A: 

Off the top of my head, try PKI.

Everyone
PKI is not a small subject. Can you expand on this some?
Max Schmeling
I'm less than a newb at cryptography meself, but what i have in mind is something like this. Albeit it is a little sketchy, imho, it may work.This is based upon the assumption that you have access to the source of the application, and build the binaries yourself 1. Generate a key-pair 2. Keep the private key with you3. Embed the public key with each application instance4. Generate a signed string using, say, the timestamp each time the application desires access to your DB.5. Upon receipt of the request, cross-verify the signature with your private key.
Everyone
A: 

Could you explain better your scenario. Does an application have an identifier? If yes, how easily could it be falsified etc.

rayimag
Yes, there it's name is stored in the configuration file (we're dealing with .net mainly). It wouldn't be too easy for our web apps, but we do have a couple of desktop apps and those could easily be changed by the user (which is why we aren't using this system for those apps right now)
Max Schmeling
+3  A: 

The usual way is to have a different config store per app and give each app a different user/password to connect to the config store.

That doesn't prevent anyone from changing the app and replacing the user/password for app X with the values from app Y but it's a bit more secure, especially when you compile this data in instead of supplying it via a config file.

If you want to be really secure, you must first create a secure connection to the store (so you need a DB drivers that supports this). This connection must be created using a secure key that is unique per application and which can be verified (so no one can just copy them around). You will need to secure the executable with hashes (the app will calculate its own hash somehow and send that to the server who will have a list of valid hashes for each app).

All in all, it's not something trivial which you can just turn on with an obscure option. You will need to learn a lot about security and secure data exchange, first. You'll need a way to safely install your app in an insecure place, verify its integrity, protect the code against debuggers that can be attached at runtime and against it running in the virtual machine, etc.

Aaron Digulla
Multiple configuration stores is not an option. The whole purpose for this system is getting everything centralized so we don't have to manage 400 different things.
Max Schmeling
Well, if you have row level authentication in your database, you can use that. Otherwise, save the user and password in the config, too, and return only rows were username and the (hashed) password matches.
Aaron Digulla
Note that in the general case, security != comfort. If you make something secure, it gets hard to use, hard to set up correctly, etc.
Aaron Digulla
A: 

One possibility is to keep the passwords in the database in an encrypted form, and convey the encryption key to the allowed application(s) in a secure connection.Then, only the application with the encryption key can actually get the passwords and not others.

rayimag
Minor detail: You mean "encrypted form" and "encryption key". Hashes are non-reversible, so there is no way to convert a hash back into the text used to generate the hash.
Dave Sherohman
Thanks Dave for the correction. Hashes are one way functions. I should have said encryption and decryption otherwise.
rayimag
+1  A: 

Are you trying to protected yourself from malicous programs, and is this a central database that these applications are connecting to? If so you should probably consider a middle layer between your database and application.

I'm not sure this applies to your case, depending on how what your answers to the abovementioned would be, but by the comments it sounds like you are having a similar case to what this question is about.

Securing your Data Layer in a C# Application

Runeborg
A: 

The simplest/most straightforward way would be to store the passwords in encrypted format (storing passwords in plaintext is just plain bad anyhow, as recently demonstrated over at PerlMonks) and make each application responsible for doing its own password encryption/decryption. It would then not matter whether an app retrieved another app's passwords, as it would still be unable to decrypt them.

Dave Sherohman