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.
Related
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 a chat SignalR server, the chat support group chatting.
I also have a server which actually creates the groups and other group managment tools.
Whenever a user leaves a group (via http post ) to server, I want the chat service to trigger some methods, such as LeaveGroup and some other logictics.
I bound the connectionId to userId so I got the parsing request covered.
QUESTION IS: What is the best practice of communication between server/service and the signalr server.
Taking in mind, I dont want to compormise on scalability on each of my servers/services.
My idea is more or less host a web api server inside the SignalR server, but I can't seem to find any topics suggesting that could damage the performance.
Ideas?
Thanks alot.
p.s
I know that there is no code involved in here. but it seems irrelevant. I have self hosted web api in a window service I have, so the code is pretty much the same.
I would love to provide more data/information if thats neccesary
It seems like this documentation is most applicable to what you're trying to do: https://www.asp.net/signalr/overview/getting-started/tutorial-server-broadcast-with-signalr
It speaks specifically about how to communicate from your server/service application to the signalr clients. Communicating from the client to the server/service could be done either through the signalr hub, or with other web API.
From a best practice perspective, the documentation specifically states (https://www.asp.net/signalr/overview/guide-to-the-api/hubs-api-guide-server#callfromoutsidehub):
If you need to use the context multiple-times in a long-lived object,
get the reference once and save it rather than getting it again each
time. Getting the context once ensures that SignalR sends messages to
clients in the same sequence in which your Hub methods make client
method invocations. For a tutorial that shows how to use the SignalR
context for a Hub, see Server Broadcast with ASP.NET SignalR.
If you're really into scalability, you might want to look into integrating your signalr communications into some other message queueing system, but that's probably overkill for most circumstances.
I have been looking but cannot find a good answer that can help me in my case. To explain the situation, I am creating a Unity3D game which will have a multiplayer system. In order to keep the player data as secure as possible (so people doesn't cheat easily), I decided to implement a Web API 2 service that connects to a SQL Server database. I designed the Web service in such a way that only if the request contains specific data the request is processed. What I am now having problem is to design a solution that will let me send/retrieve data from the web service. I implemented SHA-512 to send the password so packet sniffers wouldn't get it in plain text, and I am planning to implement HTTPS but Unity classes makes it very hard. I thought of implementing RijdnaelManaged as a more secure algorithm for the accounts but in Unity the code is easily reverse-engineered.
Would this model be secure enough to stop script kiddies from hacking player accounts?
HTTPS
I implemented SHA-512 to send the password so packet sniffers wouldn't get it in plain text,
That's not helping for as far as your webservice goes, it now uses the hash as its password, so anybody sniffing it will still capture it.
Use https, not http to get it right.
If you really cannot: build a system where the service first issues a challenge, and where the client then "signs" that challenge and sends the signature back. That's still by far not as good as https, but it'll prevent a few things (but not e.g. a man-in-the-middle attack).
Security
If you look at analyzing the risks, you need to take care to address users of your game as well as 3rd parties.
The 3rd parties, with good passwords (good luck with that) or proper 2 factor authentication, https etc. you can cover the bases rather well. Add in some security in the webservices and you should be a good way along the path.
But you also have to deal with users of the game. And that's harder than it might seem as they could run your game in a debugger and figure out how the game communicates with the server and what it sends when, what the effects are of that etc. Nw if you have a multi-player game typically that involves virtual goods and/or currency that can be obtained and/or traded. Devious players will try to get it the easy way, so you need to protect somehow against that as well.
The easiest to do that is to move the game logic into the server and use the client only for visualizing things - but that obviously means you make much more use of server resources ...
Trusting your client is running, unmodified, and you're talking to it: you can't ...
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#
Want to have a ssl C# server that will only send and receive small JSON strings.
The clients can be anything from mobile devices or computers.
Need some feedback what to chose since some clients maybe have ssl limitations or other limitations.
Should i create an (openssl)ssl ftp socket server?
Should i create an HTTPs server?
should i create something else????
The HTTPS looks like easiest because of it's long history and width usage.
any feedback would be grate
Give a chance to WCF.
It has a very strong customizable stack, with externalizable configuration files, for both server and client side.
Moreover, it can publish services over multiples wires. This may help you to address a maximum of situations like "simple" https encryption to certificate validation.
You can even define your own channel for ultra specific contexts.
A last word from a developer perspective: the idea of WCF is to decouple the service from its connectivity. In today world, it's a huge advantage.
HTTPS is HTTP over SSL/TLS: you first establish an SSL/TLS connection and then you exchange HTTP requests and responses on top of it (as if it was a plain TCP connection).
Since you want to use SSL/TLS in both cases, what you seem to be asking is whether you should design your own protocol or use an existing one.
Should i create an (openssl)ssl ftp socket server?
There are multiple ways of securing FTP with SSL/TLS. It's certainly not the easiest way to go.
Should i create an HTTPs server? should i create something else????
Designing your own protocol means that you'll have to provide an implementation for each device yourself. HTTPS has the advantage of being widely supported. You shouldn't even have to use much of the underlying SSL/TLS API yourself (no need to learn the OpenSSL API). The only requirements might be to learn about some SSL/TLS configuration, such as setting up certificates.
Even if you're thinking of reducing the overhead due to the HTTP headers, your protocol will still have to perform similar payload management one way or another, at least to know where the requests and responses start and end.
It's unclear what your requirements are, but unless you really notice problems with HTTPS, exchanging JSON strings with HTTPS with an existing library (e.g. WCF) makes more sense than your other suggestions.