You've no real way to provide any guarantees about what is on the client machine. I could take your client executable, modify it so that it directs logins through a server I provide, and then distribute it myself. The best you can usually do is to post hash values of the client executables on your website. The problem is that 97% of users don't know what a hash is, and even the few technical people might not be inclined to check them.
You obviously then need to secure your website too so that someone doesn't swap the executables and hash values for their own.
The main risk for you is sending the user's name and password (which they may use for multiple service) in the clear, or otherwise writing your program such that it is easy to compromise an account. Securing the client's machine is really beyond your control. The server is something you can control though. The likelihood of an attack on your server infrastructure is roughly proportional to the popularity of your game/service.
bcrypt usage
Author
OK, so I'll not worry about the client then, but just in case to add a layer of security I'll bcrypt the username/pw before encrypting and sending. That way even if someone was able to redirect the login server and change the public key to their own for encrypting on the client side the data will still be bcrypted adding that extra layer.
What kind of liability really exists for companies that require a username and pw? Clearly if stuff was leaked the company probably wouldn't survive because of losing customers but are there any legal issues around this or is that something you put in the ToC to clear yourself? Because honestly you could splash everywhere for people NOT to use a username and pw that they use for other important things, but I'm sure most people just ignore this warning.
What kind of liability really exists for companies that require a username and pw? Clearly if stuff was leaked the company probably wouldn't survive because of losing customers but are there any legal issues around this or is that something you put in the ToC to clear yourself? Because honestly you could splash everywhere for people NOT to use a username and pw that they use for other important things, but I'm sure most people just ignore this warning.
From what I can tell, most companies disclaim all liability they can using the EULA or TOS. However I am certainly not a lawyer so you'll have to talk to one if you want to discover what liabilities you have, which you cannot disclaim under your state/countries laws and the exact wording of such an agreement.
Because honestly you could splash everywhere for people NOT to use a username and pw that they use for other important things, but I'm sure most people just ignore this warning.
[/quote]
But of course.
Author
What I'm finding interesting about this is that it would seem using Asymmetric encrypting is sort of used only for the initial login AND so the client can send it's Key and IV for symmetric encryption which once the server knows those values that were randomly picked from the client, the entire conversation is now encrypted both ways so nobody would know what's up. That's interesting. In .NET it's made pretty easy. So here is some test code that I'll use for the initial Asymmetric encrypting where the client has the public key hardcoded.
Then on the server side it'll use the private key to decrypt the username, pw, & key/iv.
1) Bcrypt the pw to test vs what's in DB (client would also have done this when it sent)
2) If there is a match, create a RijndaelManaged object for this client using the key/iv sent by the client for this session for this client
3) Send back login success or failure using RijndaelManaged (symmetric) encryption which the client can read because they have the same key/iv
4) All communications now happen using RijndaelManaged encryption
That's pretty slick! It's pretty fun learning about this stuff
class Program
{
static string pubKey = "<RSAKeyValue><Modulus>mDAvLYFX5ZFEYlMsCLeKJ61D+8XYTiqjTUrVVSKlHGWFhuxFT/AgDltT/Um2QgMnC8T6TlRam7tgCK2qbbSz+ZFJYY2a4+4rqqMdMaa7U3gF48DrpO9kyFYCRjN61tSnxrCZkFj3SVxCC7GlhpgyhKi6nLPn4HQW9FIUndSUlkk=</Modulus><Exponent>AQAB</Exponent></RSAKeyValue>";
static void Main(string[] args)
{
UnicodeEncoding ByteConverter = new UnicodeEncoding();
byte[] dataToEncrypt = ByteConverter.GetBytes("client username, pw, along with symmetric key & iv");
byte[] enc = Encrypt(dataToEncrypt);
string e = Convert.ToBase64String(enc);
SendToServer(e);
}
static byte[] Encrypt(byte[] data)
{
UnicodeEncoding ByteConverter = new UnicodeEncoding();
RSACryptoServiceProvider encrypt = new RSACryptoServiceProvider();
encrypt.FromXmlString(pubKey);
byte[] encryptedData = encrypt.Encrypt(data, false);
return encryptedData;
}
}
Then on the server side it'll use the private key to decrypt the username, pw, & key/iv.
1) Bcrypt the pw to test vs what's in DB (client would also have done this when it sent)
2) If there is a match, create a RijndaelManaged object for this client using the key/iv sent by the client for this session for this client
3) Send back login success or failure using RijndaelManaged (symmetric) encryption which the client can read because they have the same key/iv
4) All communications now happen using RijndaelManaged encryption
That's pretty slick! It's pretty fun learning about this stuff
Author
Actually I think I'll change this slightly.
When the client gets connected to the server the first thing it'll do is send a random key/iv for symmetric encryption via asymmetric encryption from the public key hardcoded on the client. Then the server will send back a session ID via this clients symmetric encryption, which the client will use as the salt to bcrypt their pw. Then they'll send back their username/bcrypt'd pw via their symmetric encryption and from then on all communication will be via symmetric encryption between client/server where each key/iv is unique per client.
So this way the server can give the client it's encrypted session id as the salt to add that extra layer of security. That should be good! I guess I could bcrypt all data going back and forth to if I was paranoid enough.
When the client gets connected to the server the first thing it'll do is send a random key/iv for symmetric encryption via asymmetric encryption from the public key hardcoded on the client. Then the server will send back a session ID via this clients symmetric encryption, which the client will use as the salt to bcrypt their pw. Then they'll send back their username/bcrypt'd pw via their symmetric encryption and from then on all communication will be via symmetric encryption between client/server where each key/iv is unique per client.
So this way the server can give the client it's encrypted session id as the salt to add that extra layer of security. That should be good! I guess I could bcrypt all data going back and forth to if I was paranoid enough.
In your case, the simplest out-of-band solution is to bundle a particular public key with your application (hoping you never lose your private key or have it stolen).
Yeah I was thinking about this more. I originally was going to have the server send this public key but realized the man in the middle could intercept the server msg and send his own public key. They they could intercept the reply and decrypt with their private key and get the information. So like you said I think I'll add the key information to the client. Of course if they ever get some software on the client machine I'm sure they could alter that key to do the same thing but at least that would be harder. I suppose if the private key is compromised I'd have to give a new exe. To avoid this I was thinking of putting the public key in a text file, but again that might be "easier" for a hacker to change to his own public key on another persons PC so he could decrypt the information. I would think this is all true for SSL also but it's all pending getting something on the users PC which is just out of my control and doesn't seem like there is much you can do there anyway. I suppose if they did get something on the users PC it would be easier to just have it be a keylogger.
[/quote]
You do realize the cleartext of your communications is available on the client, right? Anyone can attach with the right kernel APIs and just read your RAM.
Men in the middle cannot insert themselves in an SSL stream, because they cannot decrypt what the client sends to the server, and they cannot properly sign what the server sends to the client. All the cilent has to do is to verify that the message from the server is properly signed/encrypted by the private key, and then any tampering will be recognized.
Your use case is exactly what SSL was designed for. Use it. Not using it is a bit like saying "I'm going to build the SAFEST CAR EVER and drive it on the freeway!" Probably not a good idea in real life.
Author
Current SSL implementations seem to not work all that well with my networking library. I'd prefer not to switch my networking library. I need straight text to be encrypted and then I send it over my networking library but SSL doesn't seem to be working that way really. It seems it's to much integrated with TcpClient/TcpServer and sockets, and I'd just prefer to not use those directly but via this library for simplicity sake. That really is the biggest key for me with all of this. I want the encrypted data so I can send it myself any which way I want.
You do realize the cleartext of your communications is available on the client, right? Anyone can attach with the right kernel APIs and just read your RAM.
[/quote]
Yeah, but that would be the client that is compromised and not a ton I can do about that. Having such a tool installed on the client would make any security implementation compromised anyway right? Everything starts as clear text on the client somewhere before getting encrypted right? Doesn't really matter if you're using SSL or not in that situation.
Yeah, but that would be the client that is compromised and not a ton I can do about that. Having such a tool installed on the client would make any security implementation compromised anyway right? Everything starts as clear text on the client somewhere before getting encrypted right? Doesn't really matter if you're using SSL or not in that situation.
Yet, compromised clients are > 100x more common than man-in-the-middle attacks. I would go out on a limb and say that man-in-the-middle attacks against SSL don't occur in real life, whereas compromised clients is where all the action is. So, which threat do you really want to design against and spend the most time on?
Author
If a username/password are typed into a textbox, that can be read from memory. It would seem client side attacks would/could just get the data before it is even encrypted. I play World of Warcraft and the big issue is keyloggers which is a client side compromise but that's not Blizzards obligation and there isn't much they can do about it and the stuff they can/try are client side installs that bring up invasion of privacy issues. The way I see it a developer can't be responsible for the clients PC when it comes to this sort of thing. The line has to be drawn somewhere. Me storing a Key/IV value for symmetric encryption would be no different than a textbox storing a username & password. If I was a hacker with free access to a client machine I know which one I'd go after. I'd hook into the "Connect" button's click event so I could read the data stored in the username and password textbox's before it even gets encrypted.
So I guess I'm confused as to what you mean given the above.
From my readings what I'm doing is what SSL is doing. Asymmetric to send the key/iv to the server for symmetric encryption between the 2. That key/iv is stored both on the client and the server somewhere. If either machines are compromised then not much we can do about it right?
So I guess I'm confused as to what you mean given the above.
From my readings what I'm doing is what SSL is doing. Asymmetric to send the key/iv to the server for symmetric encryption between the 2. That key/iv is stored both on the client and the server somewhere. If either machines are compromised then not much we can do about it right?
From my readings what I'm doing is what SSL is doing. Asymmetric to send the key/iv to the server for symmetric encryption between the 2. That key/iv is stored both on the client and the server somewhere. If either machines are compromised then not much we can do about it right?
I am saying two things:
1) If what you're doing is what SSL is doing, you should use an existing SSL library, because chances are that your own implementation will have bugs or weaknesses that aren't in the SSL library.
2) You should not be spending your very precious time on this problem. Use SSL, and spend your time designing a game that people want to play, and then designing game systems that help you mitigate the impact of cheaters and client hackers.
This leads to a third conclusion:
3) If you think that SSL is not a good fit for you right now for whatever reason, just go unencrypted until you know that you have a game that's actually worth protecting.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
