Posts: 319
Threads: 7
Joined: Jul 2012
Reputation:
0
If a hacker does a brute-force attack, it gets done using the normal OnPlayerConnect callback?
He won't be inputting every password combo by hand, but lets the computer enter it, a few thousand times per second.
If that's the case, then your server will get the salt automatically and hash it 65k times.
The hacker only needs to provide the password itself, salt is not required (the server reads it from the database and appends it automatically)
and he only needs to see "Login successfull" to inform him the password is correct.
If hashing it 65k times is just to increase the time needed to enter the server (wasting the hacker's valuable time), why not just have a 1-second timer or so? Less CPU power wasted and no lag.
Enter password, check if it's correct, start a timer and when the time has passed, either log him in (password correct) or disconnect him (password not correct).
I think hashing a hash 65k times doesn't increase security.
Upon hashing a password, you get a fixed outcome.
Scrambling a fixed outcome 65k times doesn't make it more secure, because that outcome is fixed as well.
It only increases the time required to calculate the hash, allowing less attempts per second because of limited computing power.
And it increases lag on your server, even while no hacker is even trying to guess a password.
Why not just implement a maximum number of login tries, after which the server cuts the connection?
Then the hacker only has 3 tries to guess the password. If he fails, the connection is closed.
You could also implement another feature: a delay.
When the wrong password has been inputted 3 times in a row, a value of 60 seconds could be stored in your database.
If they try to connect again within those 60 seconds, cut connection again before even asking for a password.
This blocks every attempt at even guessing a password.
If they connect after those 60 seconds, and enter the wrong password 3 times again, the delay might increase to 120 seconds.
This value would keep increasing until there are no more faulty passwords for 24 hours or so, or until the user enters the server with the proper password.
This is much less CPU intensive and way more secure, because the server cuts connection after a few failed tries and will keep the connection severed.
So the hacker can try whatever he wants, he just can't connect to guess the password.
And to make sure the real owner of the account can still play, you can add a check for his IP and gpci code.
If both are still the same as the last successfull login, log him in automatically or allow him to enter a password even when the delay time has not passed (when the hacker still gets connection closed after connecting).
