I understand that i'm never going to be completely safe ... but paypal documentation seems to stress that I should never plain-text store the API credentials in my code (ie, web.config or in some C#).
1) What is a reasonable way to protect it... without going OVERBOARD?
2) If I encrypt the keys in my web.config... where do I store the encryption key... in the database, right? But then... the connection strings to my database are also visible in the web.config... so I don't understand why this is considered safety...
My website is an ecommerce store and will probably be on Arvixe business shared server.
I would encrypt the Paypal credentials and store this encrypted information in the web.config. Do the decryption in a separate DLL and obfuscate this DLL. You could also protect this DLL with an external protection system but we have had issues in the past where protected libraries don't always work correctly in shared web environments.
Related
I am developing .Net Core Web API 2.2 project and trying to protect it best I can. This application will be connected to SQL database plus it will be sending emails from the server, and therefore I would like to figure out what is the good way of protecting my sensitive data (such as connection string, database password or even email password for SMTP account).
I have read that it is bad practice storing your passwords in a plain text in your file somewhere and one of the best practices is to use some Microsoft Azure functionality (where you provide some key and it returns you the actual password) that I have not yet used. Furthermore I do not have any subscription with Azure, and for the time being I would like not to go that direction.
Another method proposed by some of you guys was to store all the password to Environmental Variables and simply reference it in the application. I am currently exploring this option, as my app will be hosted on a 'virtual windows server' where I do not have direct access to, and thus it's difficult (without direct access) to get there and set up environmental variables (not even sure if that would be possible).
Finally, so far the best option (in case it will not be possible to use the variables mentioned above), was to actually store connections and passwords directly to appsettings.json file, but to hash them and decrypt on run-time. This option for me is surely feasible; however I wanted to ask (even though this might be quite subjective) you guys, whether this is a correct approach or there is something I have missed that could help me better to protect my application from external threats.
Any suggestions or advices would be more than appreciated as I do not really know now how to proceed.
P.S. I am using VSTS repository to store all the application code, which might be probably (I am guessing) the reason why people suggest to at least hash your passwords when storing them in appsettings.json
The appsettings.json file should never be used for secrets simply because it's committed to source control. That alone makes it a bad choice. However, there is also no capability to encrypt anything in appsettings.json. You could, I suppose, encrypt your secrets via some other means and merely place the ciphertext in appsettings.json manually after the fact, but then you would need some facility to decrypt the secret later, when then means exposing your means of encryption (i.e. your private key), which kind of defeats the entire point. Long and short, don't use appsettings.json.
Environment variables are a compromise solution. Since you manually set them on the server (not in your source control) and they can be made to only be accessible to certain users (restricted access), you get a modicum of security. However, they are also stored plaintext, which means if someone is able access the server to view them, all security is out the window. Environment variables can also be set as part of your CI\D pipeline in DevOps (formerly VSTS), so direct access to the server is not necessarily a prerequisite as long as the service account doing the deploy has the necessary access.
Azure Key Vault is the recommended approach because it's the only built-in config provider that supports encryption, meaning your secrets are encrypted at rest and pretty much secure end-to-end. However, there's nothing uniquely special about Azure Key Vault other than its ready availability. You can conceivably use any type of service that lets store secrets securely; you may just have to write your own config provider to target it.
I have a C# application that comes with an app.config file. The application is built on a build server and deployed to multiple users.
I'd like to encrypt the app.config, but I'm not sure about when to do so: If I do it straight after the build, won't the encryption depend on the build server credentials? How can the application decrypt on other machines? If I do the encryption on the users machine, won't this leave time when the app.config is unprotected?
Thanks
Edit:
I was considering using DPAPI. It uses the user's credentials to encrypt and decrypt. This is why I think I might have a problem delivering an encrypted file to the users.
I just read the addition to your post, and I don't think you actually need encryption at all...
You say that you intended to use a system that would encrypt/decrypt based on the user's credentials. That means two things:
You don't encrypt during build; you can't use this sort of system during build, for the reasons yoy noted.
You seem to be OK with the users having access to the data. In that case, you should not be using configuration at all, but you should be prompting them for login info (perhaps saving it securely afterward to reuse) or just using their Windows/domain logins.
Either way, you don't need to encrypt the file to protect it... you simply need to store the login info, or other config info, as user settings, rather than configuration, which is readable to all users.
Given that C# can be decompiled incredibly easily, exposing all set variables as well as functionality, is there a way I can fully protect the API Secret that Facebook provides for creating an App?
Thanks
A general rule of software design is to not trust the client. Whatever the client can do, anyone can do. You can try some security by obscurity and have a method that does something to "generate" the secret or you can hide it away in a seemingly unrelated class, but at the end of the day, anyone with a little bit of time can just look at the outgoing packets and extract the key from that.
If you want real security, route all your networking through your server. Have the client send commands to your server, which will interpret the commands and use the Facebook API with your secret to send the client back the proper data.
One possible solution to this problem is to store these credentials in your app.config file and then encrypting the section containing these credentials using DPAPI.
http://msdn.microsoft.com/en-us/library/ff647398.aspx
Decrypting config values is transparent and can still be done through the ConfigurationManager class.
I have an asp.net application, accessed by people over the internet using web browsers. It runs on a web server and it talks to a backend database.
Some of the users would like to use the application to store some private data. The requirements of this are:
1) Only the user who stored the data should be able to see it.
2) The developers/dbas should not be able to see the data.
3) If the web server and database server were compromised a hacker must not be able to decrypt the data.
So, it's obvious I'm going to have to encrypt this data. If I encrypt it there will be a key somewhere and probably a salt/IV. The question is where do I store the data which is used to perform the decryption? If I store it in the database or the web server then a developer, dba or hacker can access it and decrypt the data.
I think my ideal solution to this would be for the private key to be on the clients machine, that way they are entirely responsible for it. But I'm not sure of how to go about this with an asp.net web application.
I believe I can create a certificate which also stores a private key (PFX). The client companies could use group policy to deploy the certificate to their domain. But it is possible that the ASP.Net application can request the web browser to send the private key to it so that it can perform the decryption? Decrypting on the client would be best but other than creating something in javascript I don't see how this is possible.
Any advice welcome.
Store the key in the mind of the user. Use any password/passphrase based key derivation algorithm you like. The standard is PBKDF2. The optimum choice of algorithm will depend on precisely what your security requirements and threat mode is. Ideally, that decision and the implementation should at least be reviewed by a security expert.
Is it possible that you deploy a ClickOnce application as a part of your solution? The ClickOnce could easily access the cert store on a local machine thus allowing you to perform client-side encryption.
In many Application's i had Cases where i should write Username and Password's in my Application inside the Class ,like HTTP Authentication ,FTP Authentication MSSQL Server Connection String also Provides Authentication Information's ,so which is the Best way to protect these Information's because someone could Decompile my Application easily maybe using Reflector and get these Information's which can be useful for some Attack's or something like that .
Bests
Can you explain more specifically what your general goal is? Usually there's better designs than hard coding passwords and authentication tokens.
There's really nothing you can do to protect those secrets if you are distributing your application. Even encrypting your config files, the application still needs the key to decrypt, so your attacker has all they need.
You can choose other designs though, such as prompting a user for their own unique password, and then making database calls against a web service, rather than distributing an application that connects directly to a central database. But you'd have to explain the scenario for a better recommendation.