We Keep Coding

Where do I store important api keys in a blazor server app?

I have a blazor server app and I need to know here to store some important info for my app, in the appsettings.json, a .resx file? or somewhere else?

Right click the project node in the Solution Explorer and choose Manage User Secrets... The contents of the file that opens will be merged with the app settings so you can use them just like any other app setting, but they are stored securely on your machine, and are not put to e.g. source control. When you deploy the app, the server you deploy to will have its own secure storage strategy for production API keys etc (for example if you're publishing to Azure, Azure has options for safe storage of these kinds of info)
You can read more at https://learn.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-6.0&tabs=windows

Add appsettings.secrets.json file to project for store secrets. After add appsettings.secrets.json file name to .gitignore

ASP.Net core how to secure connection string sensitive data in non Azure hosting

I'm new in ASP.Net core, I try to develop ASP.Net core MVC Web API. I need connect to my database. I no idea where I should put my connection string. I put it in appsettings.json file. But it will expose my database password when i deploy the API to the non Azure hosting. I try secret manager but it seem like just for development stage，not sure I understand right or not. I try to put in Environment variable but it not work when in my IIS hsoting.
May i know how I can secure my sensitive data when deploy to Non Azure hosting. Where should I put?

There is analog of Azure KeyVault it free and open source.You can store there your connection strings and others sensitive data.Also there is client library for .net

Your main choices are:
JSON (unencrypted)
Environment variable (unencrypted)
Azure Key Vault (encrypted)
As you correctly ascertained, JSON will be plain-text and is undesirable as a result, mostly because of source control. If you're working on a closed-source solution, this is less of an issue, though. Once deployed on the server, file permissions can keep the details from prying eyes. User secrets is just JSON. It's better in that it's kept out of your project (so it doesn't get committed to your source control), but it's still stored unencrypted, and yes, it's only for development.
Azure Key Vault is the only built-in option that allows encryption, and thus, is the most secure option. You can use Azure Key Vault whether or not your app is actually hosted in Azure. However, it's not free (though, it's also not very expensive).
Environment variables are what's most commonly used outside of Azure Key Vault. While unencrypted, they're stored on the server (outside your project) and are only visible to users with sufficient privileges on that server. If a malicious actor is able to gain access to an account with privileges to view the environment variables, it could be argued that you have far worse problems than exposing database credentials, already.
If the environment variables are not being seen by your app, there's two things to look at:
Ensure that you've added them as system variables and not user variables. User variables are only accessible by the user logged in while adding them (i.e. you), which is almost assuredly not the same user the web server is running as. Alternatively, you can log in add the web server user to add the variables as user variables. This is common when running under a service account. It adds a questionable degree of extra security as only that one account can see the values, not any admin level account (smaller attack surface).
If using IIS, you must edit the advanced settings of the App Pool, and enable "Load User Profile" from there.

I use "Manage Web secrets" to save db and any other crucial data secret from other developers and team mates
This will help you isolate, various platforms as well
you can read more at
https://learn.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-3.1&tabs=windows

Deploying AWS .NET SDK project failing

I have configured the .NET SDK in Visual Studio to use IAM credentials (which are being encrypted to the app.configs such as is described here: https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/net-dg-setup.html I then wrote a call to my S3 server to get a presigned URL so I could display it in my .NET desktop app. When I run the app from my computer (through VS or by clicking the Executable) the pictures load fine from S3. When I move the bin folder files (I copy the Release directory to the 5 client computers) it doesn't work on those machines!
I've thought about trying to run an install (which has several draw backs that stem from my lack of experience creating installers). The only thing I could see this changing, is if the encryption of the IAM key uses a MAC address and the installer re-requests the IAM credentials, then it would work.
The error I get on the other PC's is: "Failed to retrieve credentials from EC2 Instance Metadata Service."
The machines are on a network whose public IP is white listed to another IAM role with FullS3 Permissions but the Group the Security Key is in also has FullS3 permissions so I wouldn't think that would matter either.
I'm more than happy to answer any other questions people have because I really want to get it going! Thank you!

I found this article about 45 minutes after posting and after reading it about 3 times I finally saw it!
"SDK Store profiles are specific to a particular user on a particular host. They cannot be copied to other hosts or other users. For this reason, SDK Store profiles cannot be used in production applications."
and "Using a Credentials File
You can also store profiles in a credentials file, which can be used by the other AWS SDKs, the AWS CLI, and Tools for Windows PowerShell. To reduce the risk of accidentally exposing credentials, the credentials file should be stored separately from any project files, usually in the user's home folder. Be aware that the profiles in a credentials files are stored in plaintext."
So the answer is I have to provide a plaintext file with the credentials and simply put it somewhere I believe to be "safe" on the clients computer, then specify that location in the app.config file.

Can I retrieve certificate information from ClickOnce deploy files?

I have a ClickOnce application that has been deployed to many users that was signed with a certificate that was located on a previous developer's computer. The certificate has expired since that developer left the company. In order to re-publish the application from another machine we need to be able to find the original certificate and update it with an extension. I have access to the previous developer's computer, but I cannot locate the original .pfx file to copy and update the certificate. I also have access to all of the previously deployed files.
We attempted to deploy the application and received the error:
The deployment identity does not match the subscription.
My best guess is that it is, in fact, the different certificate causing this error based on an MSDN forum question and response, Deployment identity does not match the description. However, it is worth noting that we have both changed the machine from which the code is being deployed and also updated the solution to Visual Studio 2010 (the platform and configuration are the same though).
How do I retrieve the original certificate information from the previous developer's machine or the deploy files? Or are we possibly going down the wrong hole trying to resolve this?

If the physical access to the machine/user account is available, it should not be a problem to retrieve the certificate, provided it was not protected with a custom password at the time of import. The export wizard can be launched from Internet Explorer Options as shown on the picture. Look up the desired certificate in one of the tabs (typically, in Personal tab). Use PFX format to export both private and public keys.
Another way to access the Export wizard is through the MMC snap-in.
[UPDATE] For the answer's completeness sake, it is impossible to retrieve the private key from a signed deployment file as it only contain the public part of the encryption key. Perhaps, in the OP's case the private key is still there, buried somewhere in the file system of the development machine (as .PVK file), although it'd be a bad practice to store it like that. More details about certificate file types can be found here. I would rather expect both private and public keys to be found in the machine's certificate store, as described above.

Best way to save authentication token?

I've been working on implementing an api in c#. The implementation is going well, but I did come across a concern.
When my library has authorized against the api I have a auth_token which I use for consequent queries to the webservice.
The token needs to be kept between program runs as it stays the same for the user (although I do check if it is still valid when the application starts).
For testing purposes I basically just save the token into a text file which is kept in the root directory of the app.
This works fine, but is this the best way?
Not sure the user will appreciate that it gets saved in a cleartext file (even if it is on his own pc).
So, what is general practice for saving tokens like this?

I would use the Windows Data Protection There are numerous examples around on how to use it from C#. It uses a user specific key to encrypt the data. Only the user themselves can decrypt it. Also be sure to secure the data during transmission between the server and the client.

Create a settings file for your project in the project properties, add a AuthToken property to the known settings (probably at the user level), then use:
Properties.Settings.Default.AuthToken = userAuthToken;
If you think they'll want it hidden, encrypt or encode the userAuthToken so it is less obvious.

You can verify if the api is used under asp.net or windows environment ( it's enough to check if Request is null) and on the first case use a cookie, on the latter save it on a registry key.

That may work in a local app or running the CI locally, but if you are in DevOps (Azure) your test app will reside in your VM bin folder. After every deployment your bin folder gets wiped out so the token you saved in your bin files is gone. Perhaps the best way to save it will be encrypted in one of your DevOps environment variables in your release pipeline so you don't loose it. When running locally you can save it anywhere.