Develop Reference

Verify authenticity of an client

I have the following concern about security in server-client models...
Imagine the following:
I have an C# WinForms client that wants to communicate with a server (PHP GET-POST Requests, Socket or WebSocket in a Console App C# (Net Framework) running on a Debian under Mono, instead of using ASP.NET).
The first problem that arises is that whether the server (written in PHP or C #) must have some kind of control for the anonymous requests that the client generates, for this, we will have to use some type of token generated by the server to every request.
The problem isn't related to the token (my plan is to use HTTPS (PHP) or SSL / TLS + Certificates in WebSockets (C#) for client-server communications at the network level, to avoid Spoofing or MitM).
The problem arises when the server has to give to a "client" (we need to check its validity, that the main concern) a token to allow the client do requests. It would be very easy to any client to give a token from the server (How? Replicating (inverse ingeenering) a client that makes requests to the server to try to obtain valid tokens, at least, as I plan to implement it, hence the need for help).
In what I was thinking, is to generate a md5 or sha hash for the assembly file of the client. So, if anyone tries to replicate those steps, it will be difficult. Because he/she will need to modify the source code of the assembly or make a malicious assembly and obtain the same hash by collision (this is difficult).
I do not know how efficient is this system, so I need you to guide me a bit in this aspect.
I've been looking at OAuth, and I think that this type of implementation is not the one I'm looking for, because this kind of implementations is for the user level (to avoid that another user violates the main user data), not for the client (application).
So if someone can guide on this issue it would be of great help.

You can't authenticate the client, it is not possible. Anything in the client is known to the user (attacker), any secret, anything you have there. The only question is difficulty, but anything you do, it will not be very difficult.
Also in your hashing scheme, what would you do with the hash, send it to the server? Why would a different client have to match the hash, when it can send whatever it wants (ie. the correct hash, as sniffed from the network)?
So again, because the software needs to run on the client machine, anything that runs there or is sent on the network is disclosed to the user, and he can replicate it in a different client. It is not possible to securely prevent this. Also ssl/tls doesn't help here, if you control one of the endpoints (ie.the client).
Imagine if it was possible somehow, software piracy would not be a thing - but it very much is.

Which protocol use for game launcher

I'm currently making a game with my friends. It will be mmorpg so I need a game launcher which will display news, update the game and allow login. All this things needs a connection to take information. At first I thought that I will have to make my custom server with custom protocol. Then I found that for checking the version for update I could use HTML and then download new files from ftp. Then I had an idea in mixing ftp with database such as MySQL which will contain passwords, news and versions of game. The problem of ftp is that it will have to download the database to read it which is very unsafe with passwords. Is there any way to make a server which will contain all those things above (news, password check, game version and update files) and allow users to login safely and fast?

I don't know if this would be an option, but it seems you need to implement a client-server architecture, or, client-server (for authorization and coordination) combined with P2P here (for playing).
You could try to create a web service on a server (WebApi or WCF service hosted on an IIS, for instance or a cheaper PHP on an nginx server) that would handle the login logic and client authorization.
This way, you won't need to download the database, just to synchronize the logic with the players. The server would tell you the connection info of your mates, and you could connect to them via P2P, or relay the communication in case you will be playing behind firewalls.
On the other hand, you may try to implement this solely via P2P.

You shouldn't be downloading passwords. You should be hashing/salting as well as encrypting the password on the client before sending it up to the server.
The client should not even know there is a sql database on the backend.
As for a good encryption solution, check out this: Hash and salt passwords in C#

How Secure is connecting to an SSL encrypted Website?

I am using WebClient to implement a secure account check before a customer can use my application. but what I am worrying about is "does connecting to a website that uses SSL Certificate using HTTPS protocol prevent MATM attack and makes the whole communication encrypted ?".
In another words: will some programs like Wireshark be able to get the requests and responses in plain text as with using normal HTTP requests ? and is there an ability to alter the sent and received packets ? in order to change my application behavior or something.
[NOTE] I am not talking about getting my application pirated as I know that there is no way to get away from that fate.

HTTPS does prevent Man in the middle attack, as long as both sides are implementing the protocol properly and I assume that WebClient is implemented properly.
That means that even wireshark that is installed on your local box won't be able to decrypt the traffic
If someone in the middle would alter packets on their way, the other side won't be able to read them and the communication would break.
Some clarification given our discussion in your comments:
The above holds if your client is not compromised (HTTPS does work), since you are assuming that your clients will compromise themselves and use tools that will cheat your application by adding fake trusted certificates (which requires admin rights), I can suggest you to use two way ssl.
The tools that I know like Fiddler won't be able to decrypt this just by adding their trusted certificates, thus making it more difficult for your clients to attack your application this way, and bring them to use a debugger or patch it, because it is easier than implementing a two way ssl proxy.
You can also do what's described in this post to override the framework's certificate verification with code that expects one specific certificate and ignores the system's trusted certificates, which is compromised by tools like Fiddler (this implements What Mark suggested).

HTTPS encrypts the transmitted data and prevents man in the middle attacks by authenticating the HOST you are connecting to. However, in regards to a desktop application and also a web application, the user can use wireshark or an http proxy to view the contents of the https transmissions on the local host.
A way to mitigate this problem is to hard code the thumb print of your server cert so that you r application can encure that the server it's connecting to is presenting a specific certificate.
An example, would be if you were to install Fiddler on your local box and install the fiddler root certificate. Your application would think it's securely connecting to the server, but fiddler would be in the middle decrypting traffic. If your application code looks for a specific certificate thumbprint, you can throw an exception when a certificate other than the certificate you expect is used to connect, thus preventing the transmission of any data when a local proxy is in use.
Wireshark will always be able to see the packets being transmitted over the network but you won't necessarily be able to see the contents of the transmission unencrypted. However I'm not an expert in using Wireshark, so maybe someone else here can expound on that.
UPDATE
Ok to clarify more.... this question is discussing the encryption of contents being sent from a desktop application to a server.
Let's layout some assumptions:
The user of the desktop application, controls their desktop.
The application installed on the desktop is using a public key to encrypt.
Anyone with the corresponding private key can decrypt.
Since the user controls their desktop they can also run an http proxy on their desktop.
Now the way SSL(HTTPS) works is that your browser starts a secure handshake, at which point the server will return the public certificate, and your browser will attempt to authenticate that certificate with the authority you puchased the certificate from like (godaddy, geotrust, or versign, etc)
Assuming the user installed fiddler and it's root certificate, your desktop application would connect to fiddler, and be served fiddlers public root certificate, which it would validate against the locally certificate store and deem it trusted. Fiddler would then contact the server, which would send it the real public certificate.
Subsequently your http request from the browser is encrypted by the browser using the fiddler root public key, fiddler then decrypts the contents, and then reencrypts it using the public key from your server (mydomain.com) and forwards the request to the server, which then decrypts it and processes it.
Here is more information: http://en.wikipedia.org/wiki/HTTP_Secure
SSL offloading(https://f5.com/glossary/ssl-offloading) is also a feature used in network infrastructure for offloading the SSL load on other devices than web services. This is a form of man in the middle decryption of content. Also, Instrustion Detection systems in enterprise networks can have SSL certificates installed in them allowing these devices to decrypt the contents of requests and inspect them for behaviors indicative of network attacks.

Encrypt TcpStream for Login Server - Necessary?

I'm writing a C# .NET application that requires a secure Login. I've already got the necessary functionality to store passwords securely with a hash and salt in a database, however, I'm now moving from the testing phase. Before during development (the Login wasn't prioritized) I was just connecting to my database directly. I'm aware this is insecure for a production application as you blatantly store your database credentials in the code. Instead, I'm opting to create a simple Asynchronous TCP Socket server that listens for a username, sends the salt from the database back, then the client hashes the entered password (salt is stored locally temporarily) and sends that back to the server. The server then checks if they match; sends back true/false if the user checks out.
I've done some research and looked into encrypting the TCP Connection, however, is this really necessary, since the password will already be hashed? Or is there a better way of doing things in entirety? I'm open to suggestions on how the client/server architecture should work. The Login doesn't play that important of a role in the application as a whole, but it will be production grade and I do not want to put a poorly designed application out there.

then the client hashes the entered password (salt is stored locally temporarily) and sends that back to the server. The server then checks if they match; sends back true/false if the user checks out.
I've done some research and looked into encrypting the TCP Connection, however, is this really necessary, since the password will already be hashed?
It doesn't matter what you call a "password", the only thing that matters is what the server will accept as valid credentials. If you input a password and the server hashes it there (as #Christian Stewart suggested in the comments), then you password is your credential. If you salt and hash the password yourself, and send the result to the server, then this result will be your credential. Intercepting it is as good as intercepting the original password + salt.
So, yes, you must also encrypt your connection, before sending credentials through it. The SslStream Class, seems to be the easiest way to do that (check the example code at the bottom, both for server and client), and it supports both server authentication and optionally client authentication as well (in case you also want to restrict which machines will have access to the Login server).

1) If you are sending sensitive data, the easiest way to protect it is to use SSL. If this is an internal project, you can generate your own certificate. Also, talk to your IT staff about whether this is even a potential problem. If this is going to be deployed in a properly-configured wired intranet situation, users can't see each other's traffic.
2) Your use of salts and hashes is messed up and it no longer solves the problem that it's meant to. Hashing and salting is meant to render the contents of the database unhelpful for an attacker. That's not the case here, since what is stored in the database is what's accepted by the server as an authentication token. Hashing must be done on the server so that the value the server accepts over the wire is irreversibly (hash) and uniquely (salt) transformed into the value that appears in the user store. Now it's true that an attacked can't reverse it to get the user's password (i.e. what they type in to your client) - which is good - but an attacker doesn't need the password if they know the value in the database.
3) Put on your attacker hat. If you watched your authentication exchange take place, would you be able to log in without knowing the secret? Yes, you would just send the last thing the client sent. So this channel should be encrypted.
4) If you can avoid it, don't write your own crypto. Don't even manage users if you can avoid it. People don't want to manage users and groups in every application they use - and I say this as someone who's made this mistake before. Can you use LDAP or domain authentication or something?

There are ways to authenticate an user with the server without ever transmitting the password, using protocols such as the free SRP used by World of Warcraft.
SRP will perform a serie of challenges to authenticate the user based on what each party knows about the password, without ever leaking sensitive information about it to the network.
Still using WoW as reference, there are open source emulators for it such as TrinityCore that give you a solid exemple of SRP in action.

Secure comunication Between a Web Page and the Server

I'm wondering if theres already a combo let say jQuery - Some C# DLL to proive a secure both way communication between ASPX forms with jQuery and a control layer based on ashx files with C# classes...
[From comment below]
Well I see I have to be more specific. The are things like sniffers on simple network analysis tools even like Firebug that let you see the data transfered via POST or GET. The idea to secure a Server Client application is to ensure that data isn't corrupt and compromised, and to achive that you have to make imposible to an atacker to report false info so the best is to have improved some cryptographyc algorithms both on client and server to crypt decrypt encode decode data...

The only way you can ever make web communication secure between a client and a server is by using SSL.

Here is a Javascript AES engine.
However, you really should use SSL instead.