How to: Login

Can someone explain how a login system could achieved?

You basically need a login server and a database.

User enters username/password, client sends these to the login server, then login server checks if username exists in db. if it does, server checks if password in db matches with the password the user entered. If it does, you log your user in, if it does not you show a warning.

more info here:
http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=189253&page=2

not %100 correct, but it should give you some ideas.

But i will need PHP isn´t it?

no you wont, if you do not want to. login server can still be written in gamestudio.

In fact you don't even need a mature database solution. That's only the best practical way to do that.

So my Database could also be basically a text file?

Yup. I just added to the message above.

As i added there, a db solution like mysql handles security and scalability for you. In a real world scenario you need security and stability, so a db comes in handy.

and a database in mysql can me as large as you want, cause you can handle and request each item/id/Username/Password..etc by simple htp_post request to a php script ^^

Textfiles are unsecure and as far as i remember, the readout lenght is limited..

Also, make sure you don't save the users passwords in plan text. Also, don't save them in a weak encryption with the key stored somewhere in your system.
If your server gets hacked and the passwords get released, your user will get very angry.

Instead, store and send only a (salted) hash of the passwords. Nearly every serious login systems use that.
Whenever a users logs in, he only transfers the hash of his password to the server which is compared to the hash saved there.

Thanks you for your kind help people!
I read the whole day about login and password security and so on.
And now it isn´t that hard now
My only question now is, how can gamestudio get the data?

mysql plugin, note that you connect to db only from the server and not the clients.

If you are using files instead of db it's standart file / read write operation.

If you are asking how it's suuposed get login details from clients, it's standart gs multiplayer mechanism.

Thanks! I will look into this

Can someone please enlighten me why a text file is supposed to be unsafer than a database? Its slower, okay, but less secure? Why?

you can put a password on a database. with a text file its all there and accessable if somone knows the direct path to said text file(s).

also with a database you can control which user has access to which part of the database etc.

Through .htaccess you can lock a directory from veeing accessable through the internet.
But I guess that it's easier to hack the textfile than hacking the db server.

I would suggest to use php between gamestudio and db serber. Through http post you can talk with the php scripts. This way you can define an explicit interface how the db server can be accessed.

Through .htaccess you can lock a directory from veeing accessable through the internet.
But I guess that it's easier to hack the textfile than hacking the db server.

I would suggest to use php between gamestudio and db serber. Through http post you can talk with the php scripts. This way you can define an explicit interface how the db server can be accessed.

Yes, i´m doing it like this Gstudio<->PHP<->Encryption<-> Database

Better would be: Gamestudio<>Encryption<>Php<>DB

You´re right..

With http requests and php you need a good authentication logic and encryption. Players can easily check your http requests and responses and may reroute some requests to other places(local http server) and return a response from there to make it look like they have been authenticated as a player that is non-existent or a different one. Using same methods they can also fake stats. That is also possible with packets used between gamestuio client and gs server but that's a lot harder.

Sounds like you can't handle a server. With the right settings there is no security risk whatsoever, beside maybe bugs in the server software, but they are usually well tested (especially Apache and Nginx).
Btw, its also possible to fail to secure a database so that everyone has access to it. For example by not validating any input.


Why would I want to have user access? Normally everything is routed through a webservice which has access to the database.

Anyway, about encryption, usually you want to use HTTPS instead of HTTP, and before trusting the HTTPS connection (hey, man in the middle attacks work there too), you should validate the certificate, the CA of the certificate and if the certificate was revoked (something most HTTPS implementations never do). You don't need to encrypt what you put into the database, however, don't even dare to put passwords in plain text into it. Always save a salted hash of the user passwords and try to make the salt as random as possible. You also should consider SHA256 as hashing algorithm because MD5 and SHA1 are considered more or less broken by now.