Open cmdkeen opened 1 year ago
Worth saying happy to potentially help with a PR, but wanted to check in principle first.
I didn't see a reason for why you need this?
Thanks for replying @davidfowl - for scenarios where (sadly) credentials being used for local development provide access that could be considered more sensitive. For example databases that are clones of production data. There are other ways to achieve this using password managers with CLIs e.g. 1Password or Keeper.
I think these are the docs: https://learn.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-7.0&tabs=windows
Don't write code that depends on the location or format of data saved with the Secret Manager tool. These implementation details may change. For example, the secret values aren't encrypted, but could be in the future.
To me, this reads more as "don't assume you can parse this file" than "we think we might encrypt this in the future".
Even if we did encrypt the contents of the user secrets we would need to decrypt them. So all we've done is moved the work of someone trying to get the secrets from reading a file, the launching an executable.
Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
No response
Describe the solution you'd like
The dotnet user-secrets docs helpfully make very clear the secrets being stored are stored in plain text. Later on they state "the secret values aren't encrypted, but could be in the future."
This is a request to add support for encrypting the stored secrets. For our purposes the Windows specific DPAPI would be sufficient, I'm no expert but aware it is more complex for other operating systems.
Handily the code is already making an OS check on the save side.
Additional context
No response