A simple break down on how usernames were verified in the old Ducktards betas. This method allows servers to guarantee that a player really is who they say they are, without fail!
|
Signing in First, your client needs to prove who you are, so it sends your username and password combination off to the master server. Security Your actual password wasn't sent, don't worry. Instead, a very intensely modified and cropped hash was used. Either way, it was only ever sent to my master server. No one else had access to this data. |
|
Access key
Once confirmed, the master server assigns you a temporary access key, which is sent back. The client then uses that key for future communication rather than sending a username and password every time. No exploits This access key is only valid for 20 minutes or so, and will instantly expire if someone tries to use it from a different location. In future versions, I was going to add a warning message too. |
|
Request You then tell the master what server you'd like to join. Simple. Administration If a server has received a lot of complaints or has been deemed abusive and unsafe, the master server can warn you at this point, or straight up prevent you from joining! On the other side, it can refuse to give the server IP if a user has been disruptive or is banned. |
|
Ticket number If everything goes to plan, the master server will give you a ticket number. This number will be stored on the master server, alongside your username in a database. Expiration It will last for 30 seconds. If it's not used in that time, it will just be deleted and the client will have to request another one (automatically). |
|
Requesting access Your client then hits up your desired server, and passes on the ticket number from the master. Ignored The server can see your IP now. If your IP is on the server's internal blacklist, it won't even respond to your ticket request. |
|
Looking up If the server isn't ignoring a player, it forwards that ticket number back to the master server. Speed Just so you know, this whole process happens in under a fraction of a second, there's no noticeable delay as a result of this. Invalid If the ticket is invalid, the master server will say so. If the master server doesn't respond at all, something has gone horribly wrong. |
|
Identity The master server then sends back all necessary information about that player. Their username, their global ID, any bans they've received, any times they've been muted, etc. Judgement The server can then decide what to do with this information, for instance not allow a player to join if they have more than say four recent bans. |
|
Approval If the server still likes everything it sees, it will then start to talk to the player, and set them up with all the server information. Security Whilst this is an incredibly secure method for verifying users to server hosts, there's still one issue I have. The obvious Aside from the fact that if the master server goes down, there's no way to verify brand new players. Yeah, aside from that, there's an issue I have. |
|
There's absolutely no guarantee that the chat messages you see ingame are from real players. You're completely reliant on what the server tells you. The server can pull messages out of thin air, we're not checking. Illusion of security So, players see a robust login system, that prevents them from accessing anyone else's username, so they assume that all messages will really be from who it says. And that's bad. Instead, I'll be using a system that everyone knows isn't trustable, but still remains just as secure. More info soon! |
Did you enjoy this article?