Skip to content

Use salted challenge-auth for login requests

Hanicef requested to merge Hanicef/SRB2:login-challenge-auth into next

This is one of the things I've been wanting to tackle for a long time, but only recently got around to do. In a nutshell, the old login mechanism by hashing and sending the password didn't provide any real security, since it was vulnerable to replay attacks. What this means is that if a malicious actor gets their hand on the hashed password, it could send that hash as-is and authenticate to the server, making it no better than not having any hashing at all.

This patch is a step-up in that it uses challenge-response based authentication method instead. How it works is that every login request gets a random salt that is sent to the client, which is then mashed together with the password to create a unique hash every time a player tries to authenticate. That hash is then sent to the server, in which the server will verify by doing the same process as the client and, if the hashes are the same, the client will authenticate. This works since the salt is unique for every request, so if a malicious actor gets their hand on the hash, sending it as-is to the server will fail authentication since the hash that the server expects is different since it would use a different salt. In addition, a malicious actor will not (in theory) be able to reverse the hash since, well, it's a cryptographic hash, and it doesn't have the password to be able to recreate it.

However, there are still improvements to be made here:

  • MD5 is busted and need to be replaced with at least SHA-256 to be solid.
  • Challenge-auth still doesn't protect against MITM attacks; for that, we would need DTLS.

However, these are things I will tackle in other PRs, since this at least is a significant improvement over the previous implementation.

Merge request reports