Safe Storage of Secrets in .NET
-
I'm using .Net core and when I first read of user secrets I thought it was brilliant. That is until I met the powershell command:
dotnet user-secrets list
I'm looking at storing them on the database again, and encrypting them using something like bcrypt to encrypt them. The weakness of this argument is that the key is in the code... Thoughts anyone on secrecy?
Ger
-
I'm using .Net core and when I first read of user secrets I thought it was brilliant. That is until I met the powershell command:
dotnet user-secrets list
I'm looking at storing them on the database again, and encrypting them using something like bcrypt to encrypt them. The weakness of this argument is that the key is in the code... Thoughts anyone on secrecy?
Ger
Who are you trying to keep the secrets secret from?
dotnet user-secrets listwill only list the secrets stored for the current user. And it's intended to keep them out of your source control, not to prevent you from seeing them.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Who are you trying to keep the secrets secret from?
dotnet user-secrets listwill only list the secrets stored for the current user. And it's intended to keep them out of your source control, not to prevent you from seeing them.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
I'm trying to keep them secret from the next person to use the machine. I missed the detail about that list command only applying to the current user. I am much relived.
Ger
-
I'm using .Net core and when I first read of user secrets I thought it was brilliant. That is until I met the powershell command:
dotnet user-secrets list
I'm looking at storing them on the database again, and encrypting them using something like bcrypt to encrypt them. The weakness of this argument is that the key is in the code... Thoughts anyone on secrecy?
Ger
First thing to mention here is, why are you even trying to store the secrets—I am assuming, connection strings, API keys, etc. etc.—in your own machine, unless your web server runs in the same machine. In testing or development environment, you should consider using testing or development credentials, that when exposed can be cleared, rotated and wiped without any panic. I am not sure why you didn't read the documentation for this tool, Microsoft had already made it pretty much clear that this tool is not for "securely storing your credentials", rather "storing your secure credentials". There is a huge difference,
[Secret Manager](https://docs.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-2.2&tabs=windows#secret-manager):
The Secret Manager tool doesn't encrypt the stored secrets and shouldn't be treated as a trusted store. It's for development purposes only. The keys and values are stored in a JSON configuration file in the user profile directory.
So, that was pretty much clear from the documentation that this tool doesn't do anything on its own side and as Richard said, it merely takes the secure information out of your code, to prevent it from being version controlled. If you are using an external hosting service, use their secure vaults (or something similar in technical terms). For example, it is a bad idea of store the security details or credentials in environment variables, or even in the databases that you hold or own. Because as you said,
Quote:
I'm looking at storing them on the database again, and encrypting them using something like bcrypt to encrypt them.
They are merely encrypted, anyone who has access to your machine—since this data is in your machine—has access to that database, which is clearly visible as these values are needed by your apps to function. Thus, anyone can access the keys. The good practice to use nowadays is to use secure vaults, you can check with your hosting providers to check if they do provide any. For example, on Microsoft Azure you should use Azure KeyVault, [Key Vault | Microsoft Azure](https://azure.microsoft.com/en-in/services/key-vault/), which secures your credentials and resists tampering against it.
The shit I complain about It's like there ain't a cloud in the sky and it's raining out - Eminem ~! Firewall !~
-
First thing to mention here is, why are you even trying to store the secrets—I am assuming, connection strings, API keys, etc. etc.—in your own machine, unless your web server runs in the same machine. In testing or development environment, you should consider using testing or development credentials, that when exposed can be cleared, rotated and wiped without any panic. I am not sure why you didn't read the documentation for this tool, Microsoft had already made it pretty much clear that this tool is not for "securely storing your credentials", rather "storing your secure credentials". There is a huge difference,
[Secret Manager](https://docs.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-2.2&tabs=windows#secret-manager):
The Secret Manager tool doesn't encrypt the stored secrets and shouldn't be treated as a trusted store. It's for development purposes only. The keys and values are stored in a JSON configuration file in the user profile directory.
So, that was pretty much clear from the documentation that this tool doesn't do anything on its own side and as Richard said, it merely takes the secure information out of your code, to prevent it from being version controlled. If you are using an external hosting service, use their secure vaults (or something similar in technical terms). For example, it is a bad idea of store the security details or credentials in environment variables, or even in the databases that you hold or own. Because as you said,
Quote:
I'm looking at storing them on the database again, and encrypting them using something like bcrypt to encrypt them.
They are merely encrypted, anyone who has access to your machine—since this data is in your machine—has access to that database, which is clearly visible as these values are needed by your apps to function. Thus, anyone can access the keys. The good practice to use nowadays is to use secure vaults, you can check with your hosting providers to check if they do provide any. For example, on Microsoft Azure you should use Azure KeyVault, [Key Vault | Microsoft Azure](https://azure.microsoft.com/en-in/services/key-vault/), which secures your credentials and resists tampering against it.
The shit I complain about It's like there ain't a cloud in the sky and it's raining out - Eminem ~! Firewall !~
Afzaal Ahmad Zeeshan wrote:
I am not sure why you didn't read the documentation for this tool, Microsoft had already made it pretty much clear that this tool is not for "securely storing your credentials", rather "storing your secure credentials". There is a huge difference,
Chances are I missed it when reading it, although I'm not sure whoose documentation I read on the subject so it might not even have been mentioned. Either way it was lost on me.
Afzaal Ahmad Zeeshan wrote:
They are merely encrypted, anyone who has access to your machine—since this data is in your machine—has access to that database,
This is why I move away from database storage in the first place.
Afzaal Ahmad Zeeshan wrote:
For example, on Microsoft Azure you should use Azure KeyVault
And this is the real value in your response. :thumbsup:
Ger
