Jump to content

  • Log In with Google      Sign In   
  • Create Account

Servers and Encryption


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 Xanather   Members   -  Reputation: 712

Like
0Likes
Like

Posted 19 April 2013 - 08:58 PM

Ive not asked a question here for a while, but anyway.

 

My game will have server based multiplayer, players connect to the server, create a account and then play the game with that account on the server.

 

The account data is saved server side (1 file per account in a directory - since I want to allow server owners to transfer accounts to other servers by basically copying the file). Only the password of the account is encrypted in that file.

 

The server software will be available to anyone for free and I wanted idea's on how I could deal with malicious server owners who want try decrypt the passwords? Obviously the encryption key for each server out there would need to be the same so that the passing of account files between servers is compatible.

 

My concern is that I am working with C#, meaning the server assembly could be easily decompiled and the encryption key is easily obtained.

TLDR: Ideas on approaching server owners who want to decrypt player's accounts passwords for malicious activities?

 

I already know how do implement 128-bit AES encryption, but it seems useless if the key can be found

 

All replies are appriciated, thanks.

edit: I'm not concerned about server owners hacking their way into a game account, but rather logging into other websites in which the user may have the same password and/or username.


Edited by Xanather, 19 April 2013 - 09:08 PM.


Sponsor:

#2 Ectara   Crossbones+   -  Reputation: 3055

Like
3Likes
Like

Posted 19 April 2013 - 11:58 PM

The first question that comes to mind is why the password is even stored server-side at all? It is very common to simply store a hash of the password, plus a couple salts, and check if the hash of the password on the client's side matches the one on file. If someone gets your hash, there isn't much that they can do with it; hashing is one-way by nature, so if they get your hash, they can't figure out what the original password is. For this reason, if the user loses their password, a new one must be generated, because the old one can't be retrieved.

So, I feel the question should be less of how do I prevent the inevitability of someone being able to decrypt my password, and more of how do I avoid ever having something that can be stolen?



#3 Xanather   Members   -  Reputation: 712

Like
0Likes
Like

Posted 20 April 2013 - 01:43 AM

That is actually a great idea, I cannot believe I did not think of that. Thank you very much :)



#4 Bacterius   Crossbones+   -  Reputation: 9266

Like
3Likes
Like

Posted 20 April 2013 - 03:51 AM

If the server is going to be freely available then obviously you need to decouple account logic from server logic, unless you want people to register a new account for every server they join. At that point, all the accounts need to be stored in a separate database, upon account creation you must:

 

- have the user generate a random, sufficiently long salt, say 16 bytes

- have the user hash his password using the salt (do not use MD5, SHA256, SHA512, .. use bcrypt, scrypt, or at the very least, PBKDF2, properly configured, this is CRITICAL)

- securely receive the salt, and the hash generated by the user (and his username, too..). This is far from trivial already, since you will need some sort of secure connection to the server, best is probably to do the registration online via an HTTPS form (SSL/TLS), of course if you want to avoid MITM you'll need to purchase an SSL certificate which is.. let's say it's not free, but you can do that later on. If you cannot securely transport the password to the server, you have zero security.

- perform a cheap final hash on the received hash, say SHA256, and store that along with the salt (CRITICAL)

 

Now upon login, you need a secure connection (if you don't, anyone can intercept the stuff you send and impersonate you via a replay attack), and then:

- client sends his username, and asks the server for his salt

- client receives salt, computes the same hash using the salt, and sends it off to the server

- server does the cheap hash on the received hash, and checks if it matches the hash in the database, if it doesn't, access denied

 

This is the basic password authentication protocol. A better approach is to use a protocol called SRP (no, that's not single responsibility principle, it stands for Secure Remote Password) which is considerably better than this, and, in fact, disallows brute force attacks assuming the server can authenticate itself (via an SSL certificate or whatever). Although it's more complicated, harder to deploy, and probably overkill.

 

All in all, you should probably use an existing password storage solution. In fact, if you were storing more sensitive information than just game accounts, say, credit card stuff, you would need to be PCI-DSS certified, but there is no moral reason not to approach game account passwords with the same care. Many people wrongly use the same password everywhere, and you do not want to deal with the legal issues you may end up facing if your account database fails.

 

At this point, there are two points of attack:

- on the password database, this is not a problem if the client properly configured the hash

- during account creation, this doesn't work because all the server gets is a salt and the password hashed using this salt, so unless the password is extremely weak to begin with, he won't be able to brute-force it, especially if you use a slow hash as recommended

 

This will fulfill your original requirement of protecting against unscrupulous server owners, however you MUST be able to set up a secure channel between the server and the client when the hash is sent over the network, because otherwise, your password will be safe, but won't actually protect anything. Anyone can snoop on the hash, and then send it himself at a later time, and boom! he has access to the user's account.


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#5 Xanather   Members   -  Reputation: 712

Like
0Likes
Like

Posted 21 April 2013 - 01:29 AM

Thanks for the reply. My game will be a typical client-server, not something with a giant database with a few hundred/thousand accounts. I just wanted to make sure that people who choose to host a game server, cannot hack into the account files and retrieve the passwords. Hash seems like it will do the job. Anything that happens to the account file I could not really care about, if they want to cheat the game they can as I'm not going to invest time in slowing down hack practices.

 

Your post has given me new secure networking ideas/thoughts though, thanks!






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS