Is encryption application credentials using certificate encryption good practice?

Question

I'm working on a small web application. The web application needs access to a database, so the application needs access to a database username and password.

The application runs in an environment where virtual machines comes and goes and there are no persistent disks. The only environment configuration we can set up which remains over time are certificates, all other configuration must be stored as a part of the application (which we upload to the hosting service in a zip). Certificates which we upload to the hosting providers are automatically installed into the Windows certificate store by the hosting provider.

The database server we are using do not support authentication using certificates - only user name and passwords, so I'm wondering if the following scheme would make sense:

1. We create a self-signed X509 certificate using openssl or makecert.
2. We upload the certificate (with private key) to the hosting provider (we do this once, or when we want to renew the certificate).
3. We encrypt the database passwords in the application configuration using the public key-part of our certificate (using RSACryptoServiceProvider).
4. We upload the encrypted password in a configuration file as part of our application package zip to the provider
5. In our application code, before connecting to the database server, we decrypt the database password using the certificate (again, using RSACryptoServiceProvider)

With this, we get the following:

1. Anyone (me or my friends) working with the application can set a new database password, encrypt it and update the application configuration, without access to the private key in the certificate.
2. Only people with the private key (which is installed on the servers and stored locally by me) can decrypt the database password.

It seems like this would be a pretty good solution, but I would appreciate if someone else could spot a flaw.

Answer 1

On the surface this sounds like a fine idea - if you're trying to provide a buffer against:

• Version control (git / svn hosting) compromise
• Theft of a physical machine containing the codebase / credentials
• Malware on one of your developers machines leaking the credentials in some way.
• Any other way in which the files containing credentials are stolen by an attacker

Just remember that this wont protect your database if your web app itself is compromised, as it will still have the unencrypted credentials in memory at some point. If you're just trying to protect the credentials from being stolen from somewhere other than the live machine this should work just fine, though.

Also, in my opinion the environment that you're describing sounds quite non standard, which worries me a little. You're relying on whatever service the hosting provider is exposing to access the private keys in a big way.

Answer 2

Its not clear to me if you're using Azure VM or PaaS but you may want to consider a flow using SAS tokens.

On Azure you have a built-in mechanism called SAS -shared access signatures. You can read more about SAS here https://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-shared-access-signature-part-1/

Your flow would be like this

1. Pass credentials and get a timed one time SAS token
2. You can use SAS with functional granularity - ie - different tokens for different data operations. This will give you a great solution using native Azure functionality

While the vulnerability of storing a username/password in your backend code exists - if an attacker compromises physical machine/your VM or exploits your code and elevates permissions then using public/private key scheme as you describe will not be an effective security countermeasure and will only cost you a lot of grief and time testing and debugging. So forget it. Code your credentials in the code and use SAS

In general - I would do a threat analysis on your application before implementing security countermeasures and also as a best practice never DIY cryptography!