I'm creating a program in VB.Net that heavily interacts with 2 large MSSQL databases. I do not know a ton of vb and I'm fairly new, but I would assume just having the connection strings in the code and releasing the program it would be quite easy for someone to reverse the program and get my connection info? correct me if I'm wrong.
My question is I'm wondering if there is a safer way to use a connection string in my program. Would I just have to encrypt my app? Create a module or dll?
You can encrypt just the portions of the .config file which contain the sensitive material, in this case connection strings.
The answer is aspnet_regiis.exe
The location may vary depending on your system and version of .NET, but a file search should narrow it down.
Let's say you have a program called myapp located in c:\dotnetaps\myapp.
I use the following command to encrypt the "connectionStrings" portion of web.config:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -pef connectionStrings C:\dotnetapps\myapp
Wait a second: web.config is only for web apps, not local ones, right?
aspnet_regiis.exe only works for web.config, but the format is exactly the same as app.config. Therefore, all you need to do is rename app.config to web.config, run the tool, and rename it back. A little awkward, but nothing that can't be automated by a batch file.
# Encrypts connectionStrings in app.config
ren C:\dotnetapps\myapp\app.config web.config
path\to\exe\aspnet_regiis.exe -pef connectionStrings C:\dotnetapps\myapp
ren web.config app.config
Important note: Using literally these commands will encrypt the file against the particular system it is running on. You'll want to do a little reading to get it to encrypt against a key that allows you to distribute your code, but this is the general idea.
You could store it in your resources file (MyFile.resx) as an encrypted string.
Related
I'm working on a C project that makes connections to remote servers. Commonly, this involves using some small terminal macros I've added to my makefile to scp an executable to that remote server. While convenient, the only part of this I've not been able to readily streamline is the part where I need to enter the password.
Additionally, in my code, I'm already using system() calls to accomplish some minor terminal commands (like sort). I'd ALSO like to be able to enter a password if necessary here. For instance, if I wanted to build a string in my code to scp a local file to my remote server, it'd be really nice to have my code pull (and use) a password from somewhere so it can actually access that server.
Does anyone a little more experienced with Make know a way to build passwords into a makefile and/or a system() call in C? Bonus points if I can do it without any third-party software/libraries. I'm trying to keep this as self-contained as possible.
Edit: In reading responses, it's looking like the best strategy is to establish a preexisting ssh key relationship with the server to avoid the login process via something more secure. More work up front for less work in the future, by the sound of it, with additional security.
Thanks for the suggestions, all.
The solution is to not use a password. SSH, and thus SCP, has, among many many others, public key authentication, which is described all over the internet. Use that.
Generally, the problem you're trying to solve is called secret management, and the takeaway is that your authentication tokens (passwords, public keys, API keys…) should not be owned by your application software, but by something instructing the authenticating layer. In other words, the way forward really is that you enable SSH to connect on its own without you entering a password by choosing something that happens to not be an interactive authentication method. So, using a password here is less elegant than just using the generally favorable method of using a public key to authenticate with your server.
Passing passwords as command line option is generally a bad idea – that leaks these passwords into things like process listings, potentially log entries and so on. Don't do it.
Running ssh-keygen to create the keys. Then, adding/appending the local system's (e.g) .ssh/id_rsa.pub file to the remote's .ssh/authorized_keys file is the best way to go.
But, I had remote systems to access without passwords but the file was not installed on the remote (needing ssh-keygen to be run on the remote). Or, the remote .ssh/authorized_keys files did not have the public key from my local system in it.
I wanted a one-time automated/unattended script to add it. A chicken-and-the-egg problem.
I found sshpass
It will work like ssh and provide the password (similar to what expect does).
I installed it once on the local system.
Using this, the script would:
run ssh-keygen on the remote [if necessary]
Append the local .ssh/id_rsa.pub public key file to the remote's .ssh/authorized_keys
Copy back the remote's .ssh/id_rsa.pub file to the local system's .ssh/authorized_keys file [if desired]
Then, ssh etc. worked without any passwords.
UPDATE:
ssh_copy_id is your fried, too.
I had forgotten about that. But, when I was doing this, I had more complex requirements.
The aforementioned script would merge/combine all the public keys and update all the authorized_keys files on all the systems. This would be repeated anytime any new system was added to the mix.
you never need to run ssh-keygen on a remote host, especially not to generate an authorized_keys file. –
Marcus Müller
I think that was inferred but not implied as a requirement [particularly in context]. I hope the answer wasn't -1 for that.
Note that (1) ssh-keygen is needed for (3) copy back the public key.
Ironically, one of the tutorial pages for ssh-copy-id says run ssh-keygen first ...
It's been my exerience when setting up certain types of systems/clusters (e.g. a development host/PC and several remote/target/test ones), if one wants to do local-to-remote actions, invariably one wants to do:
remote-to-local actions -- (e.g.) I'm ssh'ed into a remote system and want to do rcp back to the development system.
The remote system needs to do a git clone/pull from [and, sometimes, git push to] the local git server.
remote-to-remote -- copying/streaming data between target systems.
This requires that each system have a private/public key pair and all systems have an authorized_keys file that has the public keys of all the other systems.
When I've not set up the systems that way it usually comes back to haunt me [usually late at night when I'm tired]. So, I just [axiomatically] set it up that way at the outset.
One of the reasons that I developed the script in the first place. Also, since we didn't want to have to maintain a fork of a given system/distro installer for production systems, we would:
Use the stock/standard distro installer CD/USB
Use the script to add the extra/custom config, S/W, drivers, etc.
I have some .sh files, this file contains my ssh and scp details.
I would like to encrypt the ssh files, upon encryption It should be able to execute/run.
like the background.js ( attachment ) file is encrypted but still executing in the browser
Background:
There is a difference between obfuscation and encryption.
Obfuscation hides the data or makes it hard to read, but it is still theoretically possible to reverse this and get back the original source data.
Encryption actually uses cryptography to make it near-impossible to decrypt without a key.
I believe the image I'm looking at above is "obfuscated" and not "encrypted" based on the details that you've provided.
Answer:
If you're running this file on a machine and not in a browser, I'd recommend looking at compiling it into an executable which will compile it into bytecode. This will likely accomplish your original intent of hiding the source. Nexe is one tool for NodeJS that can do this.
If you're running this in the browser, then you can only really obfuscate it. Terser is a library for this in NodeJS
And lastly, a common pattern for hiding ssh details is to put them into environment variables and have a script reference the environment variables rather than actually putting the credentials in the code.
In JS, that would be process.env.PASSWORD
I have a distributed wpf application that I am trying to find a good way to encrypt the connection string in the app.config. I have tried renaming the app.config to web.config and running the aspnetiis_reg from the command line, that encrypts it but I later found out that only works for the user running the command, I have gotten code online that reads the connection string and encrypts the password and saves the app.config, and when running the application I can run a function that decrypts the password and saves it but that leaves a gaping whole that someone can locate the app.config and see the password when running the application, also you would have to know when the application is closed to go back to encrypt it. Can someone tell me the standard way to encrypt the password and decrypt at runtime with out having to write extra code on a WPF application. To note, I have migrated this application to enterprise library 5.0, the prev version was 1.0 and there was a way of putting the connectionstring in a separate file and encrypting and letting ent library or .net decrypt and not have to worry about it from their. what I was hoping for was a similiar way of just encrypting during build if possible an have .net decrypt without writing extra code for different cases
You can refer to app.config part of this msdn document. There is also code samples there.
I currently have a C# Application that is a distribute, and that multiple people have. I was wondering which approach could I take to hide the app.config file (.exe.config) file that is produced after a build, So that the users cannot see my connectionstrings to my remote server. I read somewhere that If I encrypt the file, It can only be decrypted on the machine It was encrypted on, which means that It would not work for the other computers that the application is on, It would only work on my PC. Which approach could I take so that The config file can be hidden / obfuscated / encrypted, or anything to protect the config file, But without it being specific only to my computer, that can actually work for any one else who has the distributed version?
Any help would be appreciated, Thanks
Do not ever give a credential to someone if you don't want them to be able to use it. It really is that simple. You cannot both give a credential to and withhold a credential from the same entity. Whatever security checks you need to do, do them on your machine. That way, even someone who has the connection strings cannot bypass any security check you care about.
If you are worried about exposing addresses of other machines you might want to consider putting these machine behind a router machine.
This way client machines and their users only know about the proxy and the remote machines would only have to be open to and trust the proxy.
Even if you encrypt the config file:
the machine will need to decrypt the file to use the connection information so the secret is out any way
using a network sniffer the user can always see to what machines his machine is connecting.
I'm creating a regular windows application that will be distributed to several users on my department. I'll need to include some connectivity passwords on the App.config file, and I obviously don't want end-users to just fire up notepad and look at the passwords.
Several articles point on how to encrypt/decrypt configuration sections, but it appears you have to share/ship some keys with the deployable solution.
Is there a simpler way, to just cipher some of the settings so that they are not user-readable, but that don't require extra steps or files when redistributing the program? Great plus would be that accessing the configuration settings is still transparent inside the .NET code. I could always just create a custom method to salt/cipher the string and in my custom code decrypt it, but I'm wondering if there's something simpler.
Any answers or links to articles on how to do this are greatly appreciated. Thanks
If you are trying to encrypt your connection string in your App.Config/Web.Config, you can do so using the Configuration class:
Configuration config = ConfigurationManager. OpenExeConfiguration(ConfigurationUserLevel.None);
ConfigurationSection section = config.GetSection("connectionStrings");
if (section != null)
{
if (!section.IsReadOnly())
{
section.SectionInformation.ProtectSection ("RsaProtectedConfigurationProvider");
section.SectionInformation.ForceSave = true;
config.Save(ConfigurationSaveMode.Full);
}
}
There are two methods: RsaProtectedConfigurationProvider and DPAPIProtectedConfigurationProvider
See this --> http://www.codeproject.com/KB/cs/Configuration_File.aspx and http://msdn.microsoft.com/en-us/library/89211k9b(VS.80).aspx.
In short, cryptography isn't a magic wand that can magically fix an insecure program.
An attacker will try to obtain passwords from memory using a Debugger while the application is running. The passwords will also exist in the binary and these can be easily obtained. The use of any encryption can be bypassed because the password must be in plain text at the time of use. Any time memory is used it can also be observed with a debugger.
The answer lies in anti-debugging: http://www.codeproject.com/KB/security/Intro_To_Win_Anti_Debug.aspx
More advanced windows Anti-Debugging:
http://www.veracode.com/blog/2008/12/anti-debugging-series-part-i/
http://www.veracode.com/blog/2008/12/anti-debugging-series-part-ii/
http://www.veracode.com/blog/2009/01/anti-debugging-series-part-iii/
http://www.veracode.com/blog/2009/02/anti-debugging-series-part-iv/
Either way, the encryption and decryption of the application configuration file is pointless as the .EXE can be examined by Reflector!
Sure you can obfuscate the code but that will make debugging a nightmare in a production environment where a strange unknown/undiscovered bug crept in as you would not be able to tell what/where/why/how to monitor for a strange bug that will only show up in release as the stacktrace and error messages would be obfuscated also...
That is something to bear in mind about and a potential pitfall...the user may not be tech savvy, but sure they could in theory, ask a friend/relative/partner to hack/break it without your knowledge..This answer is not meant to put you off, and hope you don't feel offended by my answer...
Hope this helps,
Best regards,
Tom.