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#
Related
I am currently developing a C#/WPF/MVVM/EF6 application that allows multiple users in different physical locations to send and receive SMS messages to mobile phones using a third party API.
The database stores all messages, sent and received, and is either updated directly by the user (sending a message) or by a ASP.NET web hook (receiving a message). Users are using SQL authentication and dynamically created connection strings to connect to the database (i.e. pass in a connection string whenever a new DbContext is created). EF is used to query against and display the data.
I'm now encountering what I believe may be a fundamental security issue with my design. The users all need direct access to the SQL database to use Entity Framework methods. After some research, it appears to be very risky to simply expose the SQL Server to the internet. Most suggestions have been to use a VPN or IP White Listing, but unfortunately, neither of those are options. We will have the SQL Server hosted by a third party that will not provide a VPN, and the users will be in different locations frequently so their IPs will not be static.
Are there any additional options to maintain direct SQL Server access with additional security? The only option I am able to think of is to completely change the architecture by creating an API for the application to query against and refactor the code to pull data using the API instead of Entity Framework. Any input would be highly appreciated.
You could create an API that access directly to the database, the api will be exposed over the internet, and you will only define the methods you want to perform on the database (eg CRUD Operations).
The wpf application will no longer be comunicating directly with the database but it will be communicating to the api instead. The api is the one that holds the connection string and is the only one who will have direct access to the db. That way you're not exposing your entire database over the internet.
You could also add Authentication, that way only logged in user could get/insert/modify data from the database, and could also add Authorization for handling user permissions.
Now you should refactor your application to work with the API. Although if you used something like Repository Pattern it will only require a few changes in the repository itself to work properly.
Now your application design has another layer of abstraction which is the API
WPF application → API → Database
The way I consume APIs in my applications is using the HttpWebRequest class . However there are other ways to handle that and this article explains it really well: A Few Great Ways to Consume RESTful API in C#
I agree with you to create API and act like database adapter with 2 reasons.
Letting all client store connection string is too risk and difficult in case you want to scale your project.
especially Windows application like WPF in your case. So having adapter gain you capability to update and maintain seamlessly.
If clients contact to database directly without IP whitelist meaning you are exposing database to public
An idea that I could imagine is creating a WebAPI and let it dynamically creates SQL user for each clients with limited permissions. Then periodically revoke SQL User every given time (Maybe with Webjob). So client won't have long-lived connection string. And you will need only single endpoint.
What client have to do is asking WebAPI for temporaly connection string. With this solution you will be at least have a chance to validate client's credential, role, ip, version number and etc before give them connection string whenever its connection string was revoked. It still requires API. But client will communicates with database directly with better security in my opinion.
NOTE: Since you are letting clients play with database. Make sure client is always the latest version. I think you can check when client asking for connection string.
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.
I have created a matchmaking service for a 3vs3 UDK game. The teams are formed with a C# Web Api 2 backend, which communicate with UnrealScript's HttpRequestInterface.
When a team is formed, its players are brought into a lobby where they can chat, choose a character and ready up. These communications are achieved with .NET's TcpListener and TcpClient, and UnrealScript talks to the TCP server using its TcpLink class.
I am now having problem concerning both authentication and authorization. I am having problems figuring out how to identify users securely (their credentials are stored in a MySQL database), as UnrealScript TcpLink can not use an SSL stream. Let's suppose the players authenticate through the webservice first, how can I maintain (and keep secure) their identification on that TCP server?
Are there any candidates for that job? (HMAC, token based? Keep in mind that it's extremely low level TCP). If there's none, maybe I could try long polling HTTP instead of TCP sockets? Or should I just scrap the UnrealScript frontend entirely and replace it with a Dll using UnrealScript's DllBind?
I should probably also say that I tried to exercise myself at securing just the webservice, without much success after a lot of research and a lot of trial and error, so any information on that is welcome.
For anyone still wondering I just ended up switching to a long polling server and using JWT tokens through HTTPS. Although it has its long-polling-related-issues, it seems to be a good compromise when your frontend is UDK.
I want to pass certain parameters to a desktop application remotely via the internet. I don't want my application to contact the server repeatedly, because many such applications can bring the server down easily. Is there a way to initiate the connection from the server? How can I identify the applications, as there will many of them running on many computers somewhere around the globe. I don't know where to start - I'm trying to do this in C# and ASP.NET/PHP on the server-side. Please give some advice.
Is there a way to initiate the connection from the server?
No. Not without having the client contact with the server first, informing it with the IP address, port to use etc... Which the server will need to keep for each client, hoping that they don't change (or get updated when they do change).
Long polling by the client is the right solution for what you are doing, even if you don't want to use it.
There are many different ways you could approach this, just thinking out of the box, both your app and the server could utilize a different mechanism for transferring the settings. I'm not recommending any of these methods, please don't shoot me down, they are all just ideas.
As an example, your server could connect out using FTP and output the updated settings to an FTP server on each PC. You could install something like Filezilla on each machine which runs your app. You'd obviously need to configure port forwarding on the router to allow the server FTP access.
You could use email. Setting up an email account where your server can login to send out the settings. Your app could possibly login to the same email account possibly even a single Gmail account to retrieve the settings.
Another idea would be to use a file sharing service like Dropbox, Google Drive or similar and where the settings could be shared. Obviously this would involve learning any API and I'm not sure if there are any restrictions on this approach.
The last idea and probably my preferred approach would be to host a web service and database on a remote server, both your server and the applications would connect to the same service to transfer the settings. This approach is obviously firewall/router friendly as all the clients connect out to the web service to collect the required data.
Hope this helps?
we're working on a peer to peer comm software that would allow a number of grocery stores to sync their inventory with what we call "headquarters".
To so this, we're thinking WCF+WPF, and no IIS and web services. My experience with WCF is basically zero, so my question is whether a TCP comm solution using WCF would work. The data that's being transferred is quite limited, about 2MB for a compressed plain text file (so we're sending binary data!), and this is done once per day only. So bandwidth/load shouldn't be an issue here.
The idea at this point is to have a WCF "server" running at HQ. Stores make themselves known to that server and then send files back and forth (simliliar to a chat application).
What I'm not sure of: does every store need to have a WCF "server" (or endpoint)? How would the server (=HQ) send a file to one of the clients (=stores)? Every store can send a file to any other store, and the HQ, and every store can also "request" a file from any other store/HQ.
Two limitations: None of the machines/computers involved can run Windows server for budget reasons, and as stated before IIS is a no-go.
If you are only sending files back and forth, I might question whether or not WCF even makes any sense. Have you considered just using a file transfer protocol, like scp or sftp?
Every machine will have to accept connections and have a file drop location setup, and then yuor application will have to monitor that location for new files. I love WCF in general, but a file transfer protocol is going to have a leg up if that is all you want to do.
If you direct all of your traffic via the server then there's no reason why you couldn't achieve this with WCF. The server would host WCF services in IIS with the stores having a client that was able to upload and request files. With this method, stores would not be able to directly transfer fiels to each other, but they would have to do it via the main server, which would suit your needs if you don't have the budget for the other scenario.
If all transfers are made once per day, the requests for files would be made with each client requesting what files they require, followed by each client uploading any files that are required by the server or any other client. The final step would be the server distributing the required files to each client. Obviously, this is a simplified view of it, the actual process may require some more thinking.
You don't need to host WCF in IIS, but is there any particular reason you don't want to do that?
You can host WCF in a ServiceHost, but then you need to build, maintain and deploy a lot of server/service features that IIS provides for free, such as application process recycling, activation-based hosting, etc.
In any case, it almost sounds like you need peer to peer networking. You can do that with WCF using the NetPeerTcpBinding.
If you have an opportunity to redesign your application, I suggest you do. You can throw strings around in WCF but if you can create a data contract you can keep all your communication strongly typed.
If you have access to windows server 2008 then the new IIS can host your WCF even if it isn't using tcp. Otherwise you just need to write an application that opens a service host, which you would usually wrap into a windows service. But as #MArk Seemann pointed out, you get lots of freebies by running your service in IIS.
Don't have any experience with the PeerTcpBinding but I can tell you that the NetTcpBinding is nice and fast plus it comes with all sorts of goodies like encryption and authentication if you want it.