Develop Reference

c# - hiding a password for an SSH connection on a locally-run application

First of I'd like to say thanks to this community that has gotten me as far as I currently am programming in c#. I'm teaching myself as I go and not really doing any formal training so you guys have been a great help.
I'm writing a small application that is intended to make one of the mundane tasks for upgrading a piece of equipment my company sells a bit easier. Typically these devices are not connected to the internet, and we need to remote in to a customer's computer to accomplish the task of connecting to their device over SSH and running some commands once logged in to do the upgrade. I'm hoping to distribute an app to the customer, and an encrypted key (generated on our side) that has information about the options they are upgrading, and the serial number to ensure the key can only be used on their device.
In my app, I'm using SharpSSH to accomplish to initial SSH connection which is working great. However my concern is that the root password on our device is actually a fairly simple one. The devices themselves have rather limited functionality so not much someone could do if they got on it themselves, however if they got on the device they could upgrade theirs and anyone else's device if they so desired.
So my question is, how could I best 'hide' the password in my script so it's not easily searchable by anyone with a decomplier?
Right now the code is simply,
SshStream ssh = new SshStream(ip, "easytoguessuser", "notsocomplexpassword");
So I'd like to hide the password somewhere, but I can't think of a method that means someone with a decompiler couldn't just open up the exe and look for where the password is, or how I derive it from somtething else...

Like with real world locks you can't keep someone with the right tools out. You only can make it harder.
This can include:
store the password in an encrypted string that is only decrypted shortly before it is used
obfuscate the source code so it is harder to determine where the connection is initialized
This wont make it safe, but it hinders the less determined folks.

iTunes Connect: Contains Encryption?

I want an update pushed out to my game pretty soon, but I'm stuck on this question. I added a small function that essentially uses RNGCryptoServiceProvider() (C# & Unity3D) to generate a small random string that I use to identify the user. It is sent as part of a field in POST data to my mysql server but nothing more.
I want to answer "no" for this question, but I'm scared that apple will somehow detect ("using System.Security.Cryptography" at the top of my C# file) that RNGCryptoServiceProvider() is a part of, and think I'm trying to do something malicious by answering no. Am I being paranoid? Is it safe to answer "no" or should I answer yes? Thanks

Generating random numbers is not using encryption, you are not encryption anything.
See: Cryptography and U.S. Export Compliance.

Winforms licensing specific to machine

Im building a small winforms app using: ayende rhino licensing. The licensing is working fine, I can create licences and distribute them as I choose.
The problem is, How do I make each license work on just one machine? I know there is a class in ayende's project called LicensingService which I believe does something like what I'm trying to do, but I just cant figure it out. I've done quite a bit of searching and couldnt really find any tutorials except this one.
Maybe someone has implemented this, or has some tips on how I could accomplish this? I do have access to a webserver, if that helps.
Any help is much appreciated, as always.

Depends how annoying you want to make it for your users to be honest. You could implement a HWID (see How to fast get Hardware-ID in C#? on how to generate them) which will be unique from system to system, then have your program check if the HWID matches the ID found to the place you store them on-line (usually by using a database).
Needless to say, this will make your application require internet connection in order to run which might be a bit frustrating for your users.
Or you can merge the HWID with the serial and have your application do the same to verify if they match, but that would be easily cracked by the average cracker.
In the end of the day, .net isn't the best as far as security goes since you can easily get the source code and modify the assemblies as needed to patch certain protections. Keep that in mind when deciding what route you want to take to protect your software.

I do not know what exactly is a rhino licensing. To tackle your need generally there are two approaches.
Either give some randomly generated password to the client machine, and maintain a pool of passwords in your server. Each time a password is entered to register the application in a local machine, check if it was already registered elsewhere by connecting to your server via internet.
Or, what we do is, generate a code unique to that machine (perhaps a hash of some unique machine id, say mac id) and get the client sent it to you. You would then rehash the code and send it back using some logic. Now when the client enters this code to his machine do the same thing: fetch the very machine id, do the same rehashing using the same some logicand check if it matches.
I cant think of anything else

Implementing License Validation with RSA

I am about to sell a program I have written in C# and I want to control licenses for it, strictly. That means I want to let the client connect to my server every single time it starts. This also gives me the ability to disable keys (in case of chargebacks on paypal or distribution of the code). Of course this might be a hassle for other users, but it is necessary in this case.
Since I was unable to find any good .NET Licensing systems that are uncracked, I wanted to take the approach of writing a little one myself.
My plan was to do the following:
Generate a key.dat containing 1024 characters that gets shipped with the software (individual to each user)
In the application entrypoint add a httprequest to my server that sends the key.dat + current timestamp, encrypted.
My HTTP server (running PHP) decrypts the request and checks if the key is valid (in my database) and replies with the "access level" (license type). If the key is invalid or disabled it replies with an errorcode. Just like with the request, the reply is being salted with a timestamp, so someone can't validate his program by sending a valid packet to himself. The timestamp is being checked in the client. The reply is encrypted with RSA and a previously generated public key.
Client receives response, decrypts with private key and reacts.
Is RSA the correct approach for this, so I can assure that the packets are sent by me and are not crafted (by noone else having the public key)?
Is there a better approach for solving this problem?

Someone who wants your software bad enough will just decompile it and remove the part of the code that phones home on startup.
If you were to add a checksum to the app that checks whether the code has been altered, someone can just change the checksum the program checks against (or remove the check entirely).
People who want your application enough will find ways around any type of protection you can conceive. You're better off sticking to something simple, having a product that is worth paying for (and easily) and make sure it's worth the price you're asking.
EDIT
Given that protection is important, the fact that the users will have code running on their machines is a risk you can avoid. If the users don't have the code, they can't crack it. They can't copy it and share it.
Now, it might not apply to the application you intend to write, but you should consider writing a web, Flash or Silverlight application instead of a regular client application. That way you don't have to distribute the code to customers. All you have to do is manage credentials into the application, which should be a lot easier than your round-about RSA system.
It's also easier to push out new versions of the software in a centralized model, and you won't have to worry about theft at all. Of course, load will become an issue when it wasn't before. And not all applications can be centralized easily (or at all). I'm just proposing this to make sure you consider it because it is a valid solution to your problem.
A web-based application will have the same issues as your application (i.e. it will be down whenever the user is offline, whenever the network is down, whenever your server is down, etc). So there's no added risk in that regard.

Is RSA the correct approach for this?
I do not think RSA is your best choice.
One of the capabilities of PKE (Public Key Encryption) is that it lets parties talk to each other who previously have never exchanged information before (eg. strangers).
I do not see this applying to your case. Your software knows your server well. They are not "strangers".
Consider instead Shared Secret Key encryption, where each copy of the software you distribute is given a unique secret key, and your server knows each user's secret key as well. The keys are never sent, and must be protected, but can still be used to encrypt, sign, and validate communications.
Edit After considering the comments and other answers.
Anyone who wants your software badly enough will be able to bypass the authentication completely. RSA does nothing to prevent that.
The real question is: Does breaking a single license make all licenses vulnerable/worthless. In both cases, (RSA and Secret Key), the answer is No. Just because one copy of the software got hacked and got its key exposed, or the licenses system bypassed, other copies are no more exposed. PKE and SSE seem equal in that respect to me.
Because Shared Secret Key is easier to implement, and computationally faster to execute, I think it is preferred in this case over RSA/PKE. That is not to say RSA is "wrong". It will accomplish what you are after, to the same degree that SSE will (no more, no less). But I think SSE is the smarter choice.

C# Authorization & Consistent Validation w/ PHP

So I've made a simple C# application and I'm currently using HTTPrequests to login to my phpBB forum, using a custom PHP file to check the post count of the user, and consistently resends HTTPrequests every 30 seconds. Unfortunately, I fear that this can easily be cracked despite the obfusculation. I've heard of serialization, but I don't know what that is.
Any suggestions for consistently validating the post count/login or optimizing it?

Some things that may help:
Are these on the same server or different servers? PHP has solid built in COM support, so there is no reason to use any kind of sockets if they are on the same server.
I can think of two options here: (a) Provide no authentication and make the data such that if someone gets it there is no downside (b) encrypt the data / authentication yourself.
(b) may be easier than you think. PHP has solid built in encryption:
$iv = mcrypt_create_iv (mcrypt_get_iv_size (MCRYPT_RIJNDAEL_128, MCRYPT_MODE_ECB), MCRYPT_RAND);
$key = "ThisIsYourKeyOfDoomAndPower";
$encryptedData = base64_encode(mcrypt_encrypt (MCRYPT_RIJNDAEL_128, $key, $dataToEncode, MCRYPT_MODE_ECB, $iv));
Hopefully this helps you get on the right track...

First of all serialization is not a method to protect your code. You can read more about it on Wikipedia.
The problem you may likely have is that you may pass your forum credentials in insecure way (without SSL/TLS encryption). This way anyone using a HTTP sniffer can get that data with little effort. If you are worried that someone may decompile your app and steal your code then there are some ways of making that harder (like obfluscation that you've mentioned) but you can never be 100% safe.
If I'm missing the point here please provide more details about your app vulnerability.