hi.

my question in general is: is it better to use something like session id to check data or its better to send and receive important authentication data like username and password or there will be no need to generate session id after authenticating the player or send and receive user pass after player logged in?

im working on a mmo game that data security is very important. first of all i use ssl to send and receive data so i think there will be no problem of understanding and hacking data in the net. there is an idea that when a player logged in there will be made an object of player class that contains player data that needs to be sent and received. after player logged in and query succeed, server generates a random number for session id variable and through data connection that session id will be sent and received and checked for player. another idea is just sending and receiving username and password in every packet and last option is just send and receive gameplay variables after logging the player. each one may have some volunrablities and problems. i want to know which one may you use for this kind of game.

thank you for helping.

The user must send some kind of credentials at least one (username and password is common) so that your system can tell who the user claims to be (username) and whether that's true (password.)
The question then becomes: If there is either not a connection (using UDP,) or if there are multiple connections (moving between servers,) how is this user identified in subsequent packets/connections?
A session ID is often useful to identify not only that you authenticated the user, but which particular authenticated session the user is interacting with (this may be useful if you support logging in more than once at the same time, for example.)

Sending name + password in every packet/session leaves a little more surface area for leaking the data. It is also significantly more work on your servers, which need to look up the user and hash the password for each packet. Especially the hashing is expensive -- you're supposed to use bcrypt() with a load factor of 15 or so, which will take a hundred milliseconds or so (depending on hardware capability.) Meanwhile, a signed, time-limited, session ID / ticket, is much cheaper to verify for a server that receives it.

Sending name + password in every packet/session leaves a little more surface area for leaking the data

thank you for answering my question. im trying to first encrypt my data and after that use hashing. but i think its very expensive for mobile processor to do it in every frame. i use ssl or maybe rsa for cryptography. ssl made some headache to code and still have some problems to work with sslStream but rsa is easy to code but i think its no good for my work. im just making a sample code to see how these cryptography algorithm on every frame. as its an asynch mmo game. i think its better to let server and client work seperately and check at some frames like every 60 frame. i just have to make code not to wait for process to show the frame. just when process of encrypting and decrypting finished just check data in that frame.

so i think as data is encrypted through network its hard to leak. but what you mean about having session id is usefull for support logging in a same time? you mean one user with same username can connect and play in same time with diffrent devices? and it makes distinguish and have diffrent socket connections for one username to change same data on database?

you mean one user with same username can connect and play in same time with diffrent devices?

Many systems support this use case, yes.

diffrent socket connections for one username to change same data on database?

Consider a chess game system. I may actually play multiple games in parallel, against different players. It's not actually changing the same data in the database -- it's changing different data for different games.

Regarding mobile MMO networking: I think SSL is your best bet. If you have trouble getting the SSL stream implementation that already exists and is debugged in the OS to work, I suggest that you're better off figuring out how to make it work right and learning from that, rather than trying to implement your own crypto. Implementing your own crypto is very, very, hard, and you don't know if you got it right or not until you suffer a disaster of some sort.

It also matters what kind of attacks you're trying to defend against. SSL is good at defending the network in the middle (unless you suffer from FREAK sickness,) assuming the client and the server are trustworthy. It turns out, most of the time, the network is very hard to attack, and most attackers attack the client itself, where encryption doesn't help. Some attackers also attack the servers, typically with known security holes, SQL injections, etc.

Finally, SSL doesn't work over UDP. Typically, what you do, is establish a session ID and session key, probably using SSL, separate from the UDP protocol. Then, each UDP packet first contains a random nonce (different each time) as big as the block size, followed by the payload data, all of it encrypted with the session key using a block cipher like AES in cipher block chaining mode or a similar stream mode, used for that particular packet. This will make sure that you don't suffer known-payload attacks on the key uses in the session.