Hi Leonid,
We've never had an issue with this functionality before. You made the point "Their display names most likely will match their logins". You could avoid this scenario if you make sure that a userName and displayName are never the same for a user. You can achieve this in Cloud Code. A user should never be in a position where they can easily guess an admins userName and do this. We'll raise this with the dev team for you.
Thanks,
Liam
Hi Leonid,
We understand your point of view on this issue. You can implement your own more complicated password system if you would like to. The system offers basic userName/password registration but you can build upon this if you don't think it suit's your needs. The RegistrationRequest or AuthenticationRequest Cloud Code scripts would be the place to do this. Crude example posted below. Basically we are grabbing the password string submitted by the player during their RegistrationRequest. If it's less than 5 characters we set a custom error and exit the Registration process. In the instances of password being <= to 5 characters a new player won't be created. You can add your own logic here to make sure a newly registering user supplies a password that is secure enough for your requirements.
if(Spark.getData().password.length <= 5){ Spark.setScriptError("error", "password now long enough. player not registered") Spark.exit() }
You could then implement a similar check in the AuthenticationRequest and do the same. If the supplied password doesn't match the format that you enforce your players to use upon registration, then simply exit from the Authentication process, this would help prevent the repeated errors which would lead to an account being locked. Using Social authentication would bypass this issue altogether.
Regards,
Liam
Hi Leonid,
We'll raise this with the dev team for you.
Thanks,
Liam
Any update on this topic?
we need an option in the settings to at least set the time to unlock
Leonid Umanskiy
Automatic player lock after N failed login attempts is a REALLY bad practice, and here is why.
Consider this situation:
- You have your game and in-game admins/moderators that can ban players who violate the rules
- Their display names most likely will match their logins
- Anyone can start trying to log in under their account. One can even set up a bot to do that
- Now, your moderators/admins can't sign in. Even if you unlock them through the cloud code, attacker will keep spamming with incorrect passwords and will keep locking them in.
- Attacker starts anarchy in the game or game chat and you have no moderators to ban them
Can you see the problem?
Locking someones account after N failed attempts is a really bad practice. Password brute-force problem should be solved by enforcing users to make complex passwords.
Player account state should NOT depend on the actions of other players. Golden rule of online game development - if something can be abused, it will be abused.
Back in 2000s, popular forum engines had the same functionality, and people used to troll by abusing it and locking down forum moderators and administrators. Today, most web software don't use this practice and use captcha if IP-address sent too many failed login attempts.
I would suggest that this functionality to be removed. If you can't remove it, at least give us the possibility to turn that off for our games, since player.unlock() is not a solution when someone is using 24/7 bot to spam incorrect passwords.
1 person likes this idea