Password Security
When observing private servers from this year, I noticed some still store passwords in plain text. I wanted to make it clear that Chimera doesn't store passwords at all (not as plaintext or ciphertext). Instead, Chimera securely hashes passwords using multiple key derivation functions upon registration, and uses that verifier to authenticate players. One key derivation function (KDF) in place salts the password using Go's cryptographically-safe random number generator and stores this unique salt in a separate database. These alterations make attacks such as rainbow tables and brute-force infeasible against the database. In addition, the server analyzes traffic and limits validation attempts from users exhibiting malicious behaviour. Chimera also employs SRP6 to securely authenticate users over the network without sending the password directly (rather using hashes).
Server Authentication
A major exploit found in most private servers relates to game server authentication. If done improperly, an adversary could then log into any player's character on the server. In the official server, players were authenticated by using an XOR of 0x4321 on the player's account ID, verified by performing the same XOR on the token to retrieve the account ID on the game server. This is not safe, nor is incrementing a number or encrypting the account ID like most servers currently do.
Chimera solves this security hole currently without any client modifications (this may change in the future). The transfer packet (msgconnectex) allows for a 64-bit token, which can be generated using a cryptographically-safe random number generator. I chose a cryptographically-safe random token rather than a one-time pad on the account id after a KDF since I'm attempting to protect against brute-force, and not a confidentiality breach. It is nearly impossible (or extraordinarily improbable) for this random token to be brute-forced in the amount of time required before the token expires (which is seconds, where a 64-bit integer takes roughly years to brute-force). On top of that, the server begins to reject authentication requests similarly to password verification.
And though this is more than enough to prevent brute-force attacks for such a short timeout period, I am still considering increasing this to a 128-bit token once the client hook is complete (which would take longer than the age of the universe to brute-force rather than years). It's not necessary at this time, so I'll weigh the benefits of implementing such authentication.
Account Access Log
Of course, the security I've mentioned above only functions if your password is secure, which a lot of the time isn't the case. For example, using the same password across multiple insecure websites and private servers. In the event that your account is "hacked" by another player who obtained your login from another server or site, Chimera performs extensive logging. These logs can be used for verifying such cases, but also help prevent them in the future as more security features are implemented before launch.
