Security against database hack

Need help with SmartFoxServer? You didn't find an answer in our documentation? Please, post your questions here!

Moderators: Lapo, Bax

User avatar
Posts: 1698
Joined: 25 Feb 2008, 19:26
Location: New Zealand

Security against database hack

Postby BigFIsh » 12 Jun 2012, 17:01

A must read: and ... _passwords

Procedure for SFS1.x:
1. At registration, generate a strong salt and encrypt the password using registration_encrypted_password = Hash(user_raw_password + salt). Encrypting the password using MD5 alone is not good enough. It is possible for hackers to 'intercept' the password from the data using a packet sniffing tool. Send both encrypted password and salt. The purpose of the 'salt' is to make the password much harder to crack. See link above to understand the purpose of the 'salt'. It is recommend to shows a 'password strength' indicator in the registration phrase or to enforce a strong password policy. Obviously, a more complicated and difficult password is harder to crack than a simple one. A password, even with the salt can be cracked using the brute force method. It is good to use a CAPTCHA system - this will protect against automatic registration.
2. After validating the registration data, store the new encrypted password as well as the salt into the database.
3. At login, after getting the sfsRandomKey from the server, login as a temporary user by sending a sfc.login("$temp", "", zone_name) command or something like that. This request will be handled by the login internal event. You need to intercept this '$temp' command. i.e. if username == '$temp' then do the following: Have the server generate a random temporary user name, login the user in, and join that user into a limbo room. Note - 'custom login' needs to be enabled.
4. After the client receives the Limbo room (via a custom room list), and the join event. Show the 'username' + 'password' input fields.
5. After the user hits the 'Login' button, first send the login name (no password yet) using sendXtMessage
6. Server responses with the salt from the database (for that username).
7. Encrypt the password on client side using login_encrypted_password = Hash(Hash(Hash(user_raw_password) + salt) + sfsRandomKey);
8. Then send the newly encrypted password back to the server and then validate it against what is stored into the database. i.e. login_encrypted_password vs Hash(database_encrypted_password + sfsRandomkey).
9. If successful, log out from temporary user and log in as the actual user (maybe there's a better way to do this). Otherwise, send back a 'fail' message but don't log out the temporary user yet.

This is a longer login process than the standard login, but it will protect your users as well as your database in case of a breach.. Encrypting the password using MD5 or similar alone is not sufficient, as it is possible to decode them. See link @ top for more info on how the password can be decoded.

This kind of login process can also protect against brute force attack - where the hacker could send multiple login attempts using different password or username combination using an automatic script. Simply have a 'counter' on server side to keep track of how many logins done. i.e. If login attempts > 5, do such and such (i.e. CAPTCHA, or locking the username for 5 minutes, or whatever works with your design). However, hackers may work around this, but it will make the brute force method harder and much slower. You could even add a 'pause' between each login attempts.

If you want to take the password security a step further, you could create your own 'secret salt constant' and store this static (unchangeable) value on both client side and server side. And add this constant value in the initial password encryption. i.e. Hash(raw_password + salt + secret_salt_constant). Hackers would need to crack your code to get the 'secret_salt_constant'.

In case of a password recovery scenario - generate a new password for the client and then provide a 'password change' form where the user enters the existing password, and then the new one. Make sure to validate the user first! Provide a system at registration phase to identify the user (such as security question(s))

Rule of thumb: Never never store the raw password in the database nor send it to client email account. Email accounts can be compromised by a number of reasons, such as having 'automatic login' enabled on a public computer. Not everyone is that smart. If you received an email with your 'raw password' from a site or a game at registration or during a password recovery, then they probably have stored your password in their database in raw format. If that's the case, change the password to something else if it's not one of your commonly used password.

Furthermore, always use prepared statements. i.e. do not generate the sql statement on client side. The prepared statements should be on server side. This is to protect against sql-injection. SmartFoxServer already have some protection against this by preventing writing out the stack dump in case of an error. This is why you will only get a 'false' (executeCommand) or null (exceuteQuery) in case of an error or failure. SFS also provides the escapeQuotes command. SQL-Injection can happen even with prepared statements. Clients can manipulate data and add the ' quote following by their custom sql command. For example, flash application sends such data to server (for database update, such as add gold) Client could easily intercept the package (using a tool), modify the raw data and add the following data: ' AND DELETE * WHERE 1 = 1. Such command can wipe out your table, because 'WHERE 1 = 1' will always return true. escapeQuotes protects against this. Backup your database periodically.. (this can be automatic).

Rule of toe - don't rely on client code to validate all the data.
Smartfox's forum is my daily newspaper.
User avatar
Posts: 2813
Joined: 19 Apr 2009, 11:31
Location: Lisbon, Portugal

Re: Security against database hack

Postby rjgtav » 12 Jun 2012, 21:56

Hey BigFIsh :)
Nice to see you here. And providing nice tips, as usual ;)
Skills: SFS Pro, SFS2X, AS2.0/AS3.0, Java, HTML5/CSS3/JS, C#
SFS Tutorials: - Discontinued. Some examples may be bugged.
Posts: 1
Joined: 02 Oct 2017, 08:22

Re: Security against database hack

Postby negredo » 02 Oct 2017, 08:48


Thanks for the helpful links.

Return to “SmartFoxServer 1.x Discussions and Help”

Who is online

Users browsing this forum: No registered users and 39 guests