How to make an insecure protocol "become secure"?

[peq42_]

I've been wondering if there were ways to make insecure protocols(such as HTTP and WS, but mostly WS [websocket]) more safe to deal with. I've came up with an idea to lower the chance of data being stolen, but I don't know how good it is, and would like to ask for more ideas, if someone has any.

My idea consists of the following:
As soon as a player connects, the server will generate a random password, consisting of 50 random letters(Upper case and lower case) and numbers, then will send it to the player and both will save(player will save as a variable, and the server saves as an new object within an object that represents said player connection. Both are deleted upon disconnection. Each player has its own password). After that, all info exchanged between player and server is first encrypted before sent, and then unencrypted locally ( its AES 128bits CTR encryption).

Does that help securing the connection between player and server? Or do hackers usually intercept messages between both since the first interaction? Also, what other things could I do to make communication between both safe, when not using WSS?

I ask all of this because I can't force everyone hosting a server in my game to use WSS protocol, as it requires certificate and a key generated through a process that can be quite complex for some, then I know that most won't do, or won't know how to.

 

[gstv87]

a hacker can still fish for packets at the communication ports themselves.

your safest bet would be a 2-step validation: upon connection, the server would ping the client with a string, the client would run that string through an internal routine and obtain another string, which would then be sent to the server, which would run it through it's own routine and expect a specific result.
basically, the server would have a copy of the client's routine, and run the string twice.
if the client's routine had been modified in any way, the resulting strings would not match, and the server would refuse the connection.

that still doesn't prevent someone from sniffing the ports, but they won't have access to *the key* to decrypt the traffic, which won't be transmitted if the connection is not secured by the server.

of course, that requires hard-coding the routine into the client, securely, which has it's own varying degrees of difficulty.
but, the more layers you add, the less likely somebody would try to brute-force their way through.... and if somebody *can* negotiate all those obstacles, they probably can negotiate *harder* obstacles, and if that's the case, chances are they won't be bothering with hacking a game being able to hack something more valuable.

 

[dulsi]

Network authentication is hard to do right. Unless you know what you are doing, I would stay away from doing it. What you are talking about right now means your game cannot be played offline. When you do things like this it makes a hacked pirated product better than the official product because it can be used regardless of the internet. Additionally it means your game only works as long as your server continues to run the authentication code. If you accidentally break the authentication, will you notice before the bad reviews pile up. What if you screw up switching to a new web host, are you ready for the bad reviews for the day or more until DNS servers update.

 

[Restart]

Rolling your own crypto is generally a bad idea.

 

[peq42_]

Rolling your own crypto is generally a bad idea.

I know, but as said, I can't expect everyone hosting a server to use WSS(which is encrypted, with a much better security system), so I need ways to help those work in a more safe way.

Network authentication is hard to do right. Unless you know what you are doing, I would stay away from doing it. What you are talking about right now means your game cannot be played offline. When you do things like this it makes a hacked pirated product better than the official product because it can be used regardless of the internet. Additionally it means your game only works as long as your server continues to run the authentication code. If you accidentally break the authentication, will you notice before the bad reviews pile up. What if you screw up switching to a new web host, are you ready for the bad reviews for the day or more until DNS servers update.

Well, there isn't only one server, in my projecteveryone can host a server(as it is in games like CS, TF2,etc) so if one server doesn't work, multiple others will still be online and running.

My worries here are how to lower the risk of people grabbing and controling information being received and sent. I know no system is perfect, and that I probably won't achieve something great by myself, but I need to try my best to give at least some level of security.

a hacker can still fish for packets at the communication ports themselves.

your safest bet would be a 2-step validation: upon connection, the server would ping the client with a string, the client would run that string through an internal routine and obtain another string, which would then be sent to the server, which would run it through it's own routine and expect a specific result.
basically, the server would have a copy of the client's routine, and run the string twice.
if the client's routine had been modified in any way, the resulting strings would not match, and the server would refuse the connection.

that still doesn't prevent someone from sniffing the ports, but they won't have access to *the key* to decrypt the traffic, which won't be transmitted if the connection is not secured by the server.

of course, that requires hard-coding the routine into the client, securely, which has it's own varying degrees of difficulty.
but, the more layers you add, the less likely somebody would try to brute-force their way through.... and if somebody *can* negotiate all those obstacles, they probably can negotiate *harder* obstacles, and if that's the case, chances are they won't be bothering with hacking a game being able to hack something more valuable.

This system seems interesting but quite hard. How could I implement something like that?



In anyway, I would like to ask: Does the system I already implemented work for some cases at least? Or is it totally worthless?

 

[gstv87]

How could I implement something like that?

I would say, "in such a way (or with such a code) that it allows you to grab whole procedures as objects", so as to make them comparable and evidencing differences.

the point here, is to ensure that the communication process hasn't been tampered with.
the only way it would be "not-having been tampered with", is when both the client and server share the same procedure for encrypting/decrypting, and for that there must be a way in which the server could test the client's integrity to see whether it has been tampered with.

either by having the server ping the client, or having the client perform a self diagnostic and send a validation token to the server, it should be the server the one ultimately taking whatever comes from the client side and contrasting it with an own, safe, determined value.

 

[ACECORP]

Why not secure it with SSL/TLS Certificates over https? Is there a specific reason why https w/ SSL/TLS Certificates is not an option? It's extremely difficult to swipe data while it's in transmission over https via SSL/TLS unless the end user connects to a hostile wireless access point that actually functions as a man-in-the-middle attacker.

 

[peq42_]

Why not secure it with SSL/TLS Certificates over https? Is there a specific reason why https w/ SSL/TLS Certificates is not an option? It's extremely difficult to swipe data while it's in transmission over https via SSL/TLS unless the end user connects to a hostile wireless access point that actually functions as a man-in-the-middle attacker.

As said in my post, in my game everyone can host a server, and not everyone will know how/want to use those certificates(over WSS in this case). I'm just trying to find ways to do some work around that.