In my .net core app (.net5), I'd like to store my environment variables values encrypted. This means I need to decrypt the values when loaded via EnvironmentVariablesConfigurationProvider. For example,
SET Product_SecretKeyEnc=#$SELOW#RLJLSKDFJ
In the product I'd like this realized as a configuration value "SecretKey" with a value of "DecryptedString"
So, I'd like to translate the key and the value during bootstrap.
This application is hosted in AWS Elastic Beanstalk which does not have integration with AWS Secrets Manager. AWS EB docs recommends storing configuration in environment variables. But I understand these are not secured. My intent in encrypting the environment variables is to prevent someone from getting a dump from being able to get anything useful.
Note: Andrew Lock does have a great blog post on using AWS Secrets Manager from .net core. But I thought the encrypted environment variables would suffice.
I agree with the commenter that you may be XY'ing this a bit, and that storing encrypted environment variables is not a good idea.
That said, if you persist, then what you need to do is implement your own provider derived from EnvironmentVariablesConfigurationProvider that knows how to identify which environment variables are encrypted and knows how to decrypt them.
You'd then add it to the set of configuration providers in the usual way.
Related
Recently stored our projects connection strings via Azure Key vault and retrieve them with the Azure key vault config builder for our local builds. This lets us get rid of of our connection string in our source control repo. A fellow dev told me I should look into encrypting with ASP.NET IIS_Reg as it's the "de facto standard" for web.config secret encryption. I can't really find any doc that compares these two techniques. Is it possible/ Would it be redundant to try and use both? Can they be used in tandem?
If you are using Azure Key Vault today, then I would continue to do so, as that is a more future-proof approach than encrypting things in web.config. Especially if you later want to migrate to .NET Core, then your can still keep using AKV.
Encrypting things in web.config is just a pain to administrate. With AKV you can version your secrets and you can better control who has access to what.
So long story short, I need to pass in a username and password to a web API in order to receive a JWT giving me access to use the API. I'll need to call the API for both web and console apps, so it will be used a lot.
I obviously don't want to call it using plaintext in the app(s) (them)selves because I don't want the credentials stored in version control. I also don't want to use Secret Manager or Environment Variables, because these apps will be used in production.
The only thing I can think of is storing the username/password (as plaintext) somewhere on the server and letting Windows Authentication handle the security of the data.
Is that a good practice though? I mean I guess it's as secure as the server is and if someone got access into the server we'd have bigger problems, but it just seems like it isn't good practice.
Also, I know Azure Key Vault would be ideal in this scenario, but the company is going through a lot of transitions and finances are up in the air with covid - so we're trying to minimize costs as much as possible for the time being.
Any one have any input?
I'm writing some Firebase Cloud Functions but I have need to hide a private key, including from Firebase project admins.
If I embedded this key into my source code and uploaded the code myself, would it be possible for anyone to retrieve the source code and thus the key? Either via Firebase or Google?
Many thanks
The code for your Cloud Functions is never accessible to users of your app.
It is however accessible for the collaborators on your Firebase project. See Get code from firebase console which I deployed earlier
I don't think there's any way to hide such configuration values from collaborators. Since they can see/deploy code, and the code needs access to this private key, they by definition have access to the key too.
Answering precisely to your question: Yes, they can.
The step by step to achieve that is relatively simple
Go into the GCP Functions page
Select the function you want to inspect
Click on source (From there you should be able to see all the files and the code used by that function), or;
Click on variables (From there you should see all environment variables used by your function)
If people being able to see env variables is problematic to you, here's a way to make things more secure:
You can build on what you already and start encrypting those keys before adding them to the codebase or the environment variables. After that, you can use an encryption service such as KMS to decrypt those keys at runtime. In KMS itself you can have a stricter policy in there, only allowing yourself and the function to access that service.
Another great service from GCP is Google's Secret Manager
Maybe setting an environmental variable:
Oficial Doc
Here at the job, we're working on an ASP.NET MVC application for a proof of concept. Some of the operations that the application performs require transmission of credentials, so we're storing those creds in an encrypted section of the web.config. The difficulty we're having is that when one developer encrypts the data and commits it, the next developer who updates his local copy and tries to use that web.config gets exceptions because their machine can't decrypt the config for use.
How ought we to handle this?
In the past, I've used the machine.config for sensitive credentials i.e. connection strings and such. It's located at C:\Windows\Microsoft.Net\Framework\V4.0.30319\Config
This will allow you to omit the credentials out of commits altogether. Just make sure each developer and/or server has its own machine.config with the required credential settings.
I'm assuming that you are using aspnet_regiis.exe to encrypt the section. If this is the case the reason that you are having problems is that the keys used for encryption/decryption are different on the machines.
You can either use the same keys on all of the machines, from a configuration perspective this would be similar to a farm setup so you can use the information in this SO question.
Alternatively since there's an inherent assumption that the developers have access to the credentials leave it decrypted until the app is deployed to the production server and then encrypt that section. This is a common solution when the username/password are specified in the web.config as part of the connection string for database connections, the connection would be updated to reflect the production DB server as part of the deployment process just prior to encryption.
In first place not sure why you chose this option when there are other much better ways to handle keys secrets in DevOps best practices. That seems classic way. Also during debug time any developer can peek into actual value or spit out in log?
Anyways, if you put entire dilivery life cycle as context to this problem may here what I would do to achieve what you are trying to protect keys secrets:
Do not store anything even encrypted keys secrets which team doesn't need to run locally except dev or local environment.
In web.config have local or remote keys secrets
In release transformation, clean up all keys secrets to accidental use to environmental
Use release time variable replacement pretty common on any deployment tool to choose e.g Azure/TFS DevOps deployment support it with many different ways - deploy definition level, stage level, library variable or even better key valut store with software+hardware encryption options
Hope this helps in your design approach at least.
What are your thoughts about SQL Server's symmetric key functions? Specifically, I have two questions:
Which set of functions is better... EncryptByKey or EncryptByPassPhrase?
Both functions require a passphrase of some kind. In a typical web-application architecture, where should this passphrase be stored? (i.e., hard coded within a stored procedure in the database, or stored as a configuration setting in the web application)
I'm eager to see what the best practice is for these functions.
Encrypting using a passphrase is easier but the advantage of using a key is that the key can be secured using built in SQL sever roles. You can lock down use of the key to only those users that require access to that data.
If you use a certificate then you only need plain text during the initial setup and can store it outside your system. Again, the certificate is a securable object and can be locked down.
Hope this helps.