So basically, I have a game client and a game server.
A game clients connects to the server, sending its Steam ID to the server.
The game server sees that this is a new Steam ID, so it makes a row and adds the players info (ip, name, steam id) to the players table.
The game server is able to ban players by their Steam ID. So the next time a player connects, the server checks their Steam ID with one in the table. If it found one and that Steam ID is banned, disconnect the player.
The only way for the game server to know the Steam ID of a player is to have the player use the Steam API and retrieve his Steam ID via the session made with Steam and then send it as a string to the Game Server.
However, I have a problem. Just sending the Steam ID alone is not secure as a player who has been banned can simply modify the packet going out to the server to another Steam ID, thus "unbanning" them.
What is a secure way I can send something like a Steam ID string to my game server, and having the server tell whether or not it was modified or if it was sent as it was intended from the game client?
My game client uses Game Maker: Studio and my game server uses C++.
PS: I made a question before but I wasn't descriptive enough so I made a new one.
Without knowing the exacts of what you are asking, here's a psuedo bit of thinking...
I would have the client first do a 'handshake' with the server where it receives the 'salt-of-the-day' (a 32-byte hash that is generated daily). The Client would then take that salt, encrypt the steam_id that is on the client, and transmit that data do the server, where the server would then de-crypt it and verify it against your plaintext database.
But remember, for as much encrypting that you actually do, someone somewhere will eventually crack your code and be able to thwart your best security defenses.
EDIT
Here's a LINK W/ SOURCE CODE that describes a simple encryption for strings. Now the code is in C#, but I'm sure it can be studied to convert it to C++ just as easily.
The way integrity of data is checked is usually by using one-way hash functions. These are functions that given some input (data, in this case a steam ID) produces a hash value. Given this output it is nearly impossible to decrypt it back to the original message. This is the way passwords are encoded. The password is encrypted using a one way hash function. Afterwards if for example an attacker gets this encrypted password, he can't decrypt it to the real password. However if the user wants to connect you can use the hash function and check if the result is the same as what is stored in the database.
So with this you can achieve integrity of data, given the data you can pass it through the one-way hash function and send the data together with the hash value. On the other side when the data is received you can compute the hash value using the same hash function. If it is the same as the hash value received with the message, you can be sure nobody changed the message on it's way. This is how data integrity is achieved in for example distributed systems.
Notice that it is nearly impossible to come up with a value that hashes to the same value (because one-way hash functions have to be very sensitive to it's input, changing just one bit should change the output totally).
I couldn't figure out from your question but if in your case it's the user himself who is sending you his steam ID, you can't be sure it wasn't changed. Because he will compute the hash value himself...
You can find a good explanation here.
Related
Here is what I am trying to do.
I have a game and a server executable. The clients connect to the server to play.
The concern I currently have is that someone might use telnet or something to simulate a client.
Currently, the user only sends a simply hello string after they are connected and if it is correct I accept data from them.
I have tried to use certificates / ssl without success so I am trying to figure out an effective way to know if a game client is really a client.
Simply put, what would be an effective way to validate the client?
I am not concerned with a man in the middle attack since the users do not login nor provide passwords, just a session name.
I have thought of the possibility of the server sending a fixed length random string, then the client modifies this string with an algorithm, then sends it back.
I am wondering if there are better more clever ways than that.
I do actually have a certificate for my server, it is a pfx, if that helps.
Thanks
Its intrinsically difficult as a problem. Certainly there is no software you can write, that could run on a foriegn machine, that can proves its the program you wrote in an un-tampered form.
Still, there is some simple challenge response stuff you ca do to improve things.
Lets assume your client and your server share a secret (your writing it, so they can, though being software it wont be very secret.) Lets also assume you have ahandy crypt or hashing library (for things like a SHA-1 hash) Then:
Server send challenge, including a nonce (eg the time + random number).
Client sends a response, which includes a secure hash of (nonce + secret)
Server know the nonce and the secret, so they can check the hash received is correct, and thus can confirm the "client" also knows the secret.
This is a basic symmetric validation scheme.
I'm implementing a login/authentication system for my little server-client program. I'm wondering how to go about this, and I was hoping to get some great tips/advice from Stack Overflow as always. This is how I imagine I'll do it.
Client connects to the server.
Server sends a 'token' to the Client (based on time probably and whatever)
Client returns the username and a sha1 encrypted password, along with the token.
Server receives them and authenticates the user to the credentials in the server-side database.
The token is now verified and the user is signed in with the token.
Is this at all a secure way of doing it? I figured the client also sends a serial key or some such to form a serial / token pair, so that another client cannot fake the same token (though the token is generated by the server-side).
Implementation details aren't required, as I am capable of doing the implementation.
My question would, rather, two questions:
What ways are there to achieve a login/authentication system with sockets
What ways are there to secure my client-to-server connection
EDIT: I forgot to ask, as this is a C++ question, are there any libraries that can assist in encryption/authentication?
Security is an issue for me, so I want to be sure I do it right.
Maybe some background information. It's a game server, a person logs in with his account and is taken to a 'Lobby', where he can pick a 'World Server' to play on. The world server is a separate process running (possibly) on a different machine in the same network.
For that reason, I want to have a concept of a session in this, the user logs in and a session is generated, the login server relays the session to the world server the user picks, so that world server knows that the user is actually logged in.
I reckon the client will have to confirm the session to the world server and all that, but I'll worry about that later.
Sincerely,
Jesse
You generally do not want to send the password over the link at all, not even with encryption. The usual method is a challenge-response protocol.
The client connects to the server, sending in the user-name (but not password)
The server responds by sending out unique random number
The client encrypts that random number using the hash of their password as the key
The client sends the encrypted random number to the server
The server encrypts the random number with the correct hash of the user's password
The server compares the two encrypted random numbers
This has a couple of advantages. First, it means the password never goes over the link in any form. Second, it's immune to a replay attack -- if an attacker records the conversation, they can't replay the client's replies later to log in, because the random number will have changed.
Securing the connection (i.e., encrypting the content) is a little simpler. Typically, one of the two (doesn't really matter much which) picks a random number, encrypts it with the other's public key, and sends it to the other. The other decrypts it, and they encrypt the rest of the session using that as a key for symmetric encryption.
Libraries: Beecrypt and OpenSSL are a couple of obvious ones. Unless you have a fairly specific reason to do otherwise, TLS is what you probably want to use (it does quite a bit more than what I've outlined above, including two-way authentication, so not only does the server know who the client is, but the client also knows who the server is, so it's reasonably verified that it's not connected to somebody else who might just collect his credit card number and run with it).
Edit:
To authenticate each packet without the overhead of encrypting everything, you could do something like this:
The server sends its public key with the challenge
The client generates a random number, encrypts it with the server's public key, and sends it back with its response
The number is the first number used for counter-mode encryption
The client includes one counter-mode result with each packet it sends
Counter mode means you just generate consecutive numbers, and encrypt each in turn, using the right key. In this case, the key would be the hash of the client's password. What this means is that each packet will contain a unique random number that both the client and the server can generate, but nobody else can. By using the counter-mode encryption, each packet will have a unique random number. By starting from a random number, each session will have a unique sequence of random numbers.
To minimize overhead, you could send just a part of the result with each packet -- e.g., if you use AES in counter mode, it'll generate 16 bytes of result for each number you encrypt. Include only (say) two bytes of that with each packet, so you only have to encrypt a number once every 8 packets. In theory, this cuts security -- an attacker could just try all 65536 possible values for a packet, but if you assume the connection has been compromised after (say) two bad attempts, the chances of an attacker getting the right value become pretty small (and, of course, you can pretty much pick the chances you're willing to live with by controlling the number of bad attempts you allow and the size of authentication you include in each packet).
If security is a big issue for you, don't roll your own. You want a secure socket library. Something like OpenSSL.
After many headaches and people advising to stop, I finally managed to get my Server/Client App to work with this API and create the required keys, i.e. Session and Exchange.
When I send the public key to the client, it successfully imports the key and will also encrypt a message using that key, but when I pass it back to the server; it decrypts the message using the session key but the message is returned as garbage (hmm.. private key is needed!). Now this could be due to way I am passing the encrypted message back via rpc, but something tells me it is something else. Ideally what I need is a clear and plain explanation of what it is I should be doing with all these keys, because the information I am currently getting is quite confused.
Do I pass the exchange public key to the client so it can encrypt a message and return for decryption.
Or:
Should I actually be encrypting the clients session key with the servers public key and then return that? (This doesn't sound right to me, but I am all ears!!!)
Please leave out comments to move to another API, or copy pasties from MSDN (I have already read all that). I am working with the Crypto API and just need a clear explanation of what keys the server should pass to the client, and then what the client should do and pass back so I can finally move on...
Sounds like you are on the right track if you really are determined to stick with that API :)
There are two distinct families of encryption algorithms in cryptography. 1) Ones that use symmetric keys and 2) those that use asymmetric keys. Symmetric key algorithms (e.g. AES, DES...) are very fast and should be used as long as there's a safe way to make sure both client and server have the same key (i.e. session key) and no one else can gain access to that key. On the other hand, asymmetric key algorithms (e.g. RSA...), which are also known private/public key algorithms, are much more computationally expensive. They have one key which can only be used to encrypt data and a second key which can only be used to decrypt data. These algorithms, as you found out, are perfect for the initial handshake and session key exchange. The server creates public/private key pair and sends the client the public key. Anyone can intercept it, but when the client encodes the session key and sends that back, pbulic key is useless if an eavesdropper wants to find out the session key. Only the server can decode the message as it is the only entity that is holding the private key. So your initial problem was that when the message came back, instead of using the private key from the pair, you were using synchronous session key and thus were getting garbage.
Essentially you've just implemented the basic handshake that SSL does (and you could easily do with very few lines of code if using OpenSSL library).
Once the handshake is performed you now have a secure channel between the client and the server. The only problem you might have is, what if someone piggy backs on your server's IP address and starts pretending like they are the real server? Your client will think he is talking to the real server, it'll do the key exchange and will start sending secure information, but that information might all end up in malicious hands if an attacker's PC happens to be on the other end.
This is where SSL's use of certificates comes in. Certificates are another example of where public/private keys are used. A trusted authority uses private key to sign certificates hash code and anyone can verify that certificate is valid by using it's attach public key against certificates identity data. This way even if attacker takes over your server's IP address, it won't be able to spoof your server's certificate.
I am building a client/server application in C++ and need each client to provide a password. Obviously I want this to be secure during transport so I have been looking into a way of encrypting the password; so that only the server application can decrypt it again.
The problem I am having is not necessarily getting the functions to work, but rather understanding what it is I need to do in order to relate that into code. I am trying to understand and have read MSDN (feels like it) but still I am only learning so really need some clear and accurate guidance on my implementation.
Does this sound right?
I aquire a context to the CSP on both server and client.
I generate a key on the server, or load one (whatever).
and then I
export a public key from the server and send it to the client, the client imports the key and then encrypts the password and returns it so that only the server can decrypt it again.
(Fails when I try).
OR, do I then
export a session key, or an exchange key pair ( single public) which is encrypted with the exchange key pair?
Oh I am so lost, I cannot even explain clearly.
Please help me to understand this...
It really depends on what sort of authentication solution you want to be based one. The options are varied.
You could, for example, rely on the underlying OS authentication. You wouldn't need to manage passwords at all. But this requires a somewhat tighter integration with the domain in which your application is running.
Another option is to use HTTPS and simple authentication. It basically uses SSL to encrypt communication and then sends a username/password pair. Pretty simple, and supported by all web servers. You could probably find C++ code quite easily that takes care of this for you (search StackOverflow for such a question) if you don't want to rely on an existing web server like IIS being installed.
If you do not need the encrypted Communication for other things like data transfer, you can use Challenge-Response for password verification. The Password does not need to be transferred over the network and there is no risk of a replay attack in wich a third party just resends some packets. On the downside, a man in the middle (MITM) attack is possible.
If you need protection from MITM or need an encrypted channel for other communication, you should use TLS with certificates or Public-Key-Encryption with two keypairs.
Do not do anything.
This is very important. Do not implement this yourself.
Repeat do not do anything you will get it wrong.
You should use what is already available. Simply open a connection to an SSL socket and the content of the stream will be automatically encrypted and de-crypted at the other end.
Your application should simply take a username/password tupple and validate if they are correct. Do not attempt to implement the cryptographic part.
I am producing a web service which will allow any third party "device" to communicate with it. Each device has a reasonably unusual string to identify itself and uses the web service to store data against this id. However, this allows someone who wishes to game the service to scan through and guess device ids and store malicious data against them.
The device itself using this web service is relatively "dumb" and doesn't offer a suitable interface for data entry, so a password or any form of entry on the client is not available.
As this web service is open for anyone who wishes to produce a device of this nature to use, I can't increase security with the use a private key as this would be publicly defined in a specification. Also due to the simplistic nature of the device and it's IP/HTTP stack, HTTPS is unsuitable for this implementation.
To the best of my knowledge I can't see a way of using a privately shared key in this operation. To this extent, I believe it be impossible to secure a system of this nature, but I am wondering if some other methods which I've yet to find may help me secure this system somewhat?
Is there a reason you can't use a public/private key pair?
You could publish the server's public key with the specification, and require each device to generate a random public/private key pair for itself. The device could encrypt its public key with the server's public key and send it to the server. The server could use its private key to decrypt the device's public key, and then assume that nobody else could decrypt any message that the server encrypts using that public key. The server therefore registers that public key as the device's ID.
If you set up some kind of session, the server can retain the device's public key associated with that session. If not, some defined portion of any message sent from the device to the server must include the device's public key encrypted this way, so that the server can know which device sent the message.
Any message sent to the server will be encrypted with both the client's private key (so the server knows this device sent it) and the server's public key (so only the server can read it). Messages sent to the device will be encrypted with the server's private key (so the client knows the server sent it) and the client's public key (so only the client can read it). Only you know your private key, and only they know their private key, so everything's secure as long as you (and they) use good seeding and encryption algorithms.
Does that make sense?
You could try some simple challenge-response system, where the server sends a random string of bytes to the device. The device uses some known ID (ideally not the public one) and some hash like algorithm to produce a response.
This will only protect you from people without access to your devices, though.
If "guessing" device IDs is your only concern, make the device IDs unguessable? For instance, use the result of HMAC-SHA256 with a vendor-private key and serial number as the payload. Not even you would need a copy of the vendor's key.
That wouldn't be terribly useful though, as the device's network connection is probably sniffable thus its ID could be trivially captured over the wire. A secret key element must be present on the device, therefore. But this is where I get slightly confused - your concern over using a shared private key seems to be logistical, rather than whether the device can actually support it (implying that it does have some crypto) - yet you can't use HTTPS? What kind of limitations does the device have (memory/CPU/storage)?
Two things come to mind.
First, use a non-guessable device id. Something as simple as a base64 encoded guid would work.
Second you should require that the data being passed to your web service is encrypted using a public key. Your private key would then be required to decrypt the data.
This would ensure that even if they have a listener watching the data come across, they wouldn't be able to grab a different device id. Also, with a non-guessable ID they wouldn't be able to affect other device accounts.