Created attachment 2497[details]
Adds Com_MD5String() and sv_MD5 to use a MD5 hash instead of clear-text rconPaswsword
Here is a small patch to slightly improve the security by proposing an alternative to sending a clear-text password over the network.
This small patch introduces the possibility to avoid sending a clear-text password over the network by using a MD5 hash instead; the provided code uses this facility with the 'rconPassword'.
The compatibility with legacy clients or servers is also maintained, ie
a MD5-enabled server still allows legacy clients to send a clear-text
'rconPassword' and vice-versa.
Basically, the patch introduces a new function, Com_MD5String(), which
take a string with an optionnal prefix and returns the calculated MD5 hash. A new cvar, 'sv_MD5', is added in the server and propagated through the server infostring to let any clients know about the MD5 availibility.
To avoid sending the password by itself (either in plain-text or its MD5 counterpart), the MD5 hash is created using the 'rconPassword' prefixed by the client's current challenge; 2 clients on the same server will then send 2 different MD5 hashes.
Interesting. This would only give limited security though, because if someone can sniff the password, he can also fake an rcon command coming from a connected client (only as long as it is connected though).
It would also remove the possibility to send rcon commands without being connected.
(In reply to comment #1)
thx for this feedback
> Interesting. This would only give limited security though, because if someone
> can sniff the password, he can also fake an rcon command coming from a
> connected client (only as long as it is connected though).
If the client's challenge really is what it seems to be (a unique identifier for a connected client), I don't think you can spoof an rcon command, but I may be wrong or too confident on the challenge notion here. Adding the qport to the hash may help hardening the hash though.
> It would also remove the possibility to send rcon commands without being
> connected.
yes, in that case, using that kind of MD5 hash isn't possible (although there's always the possibility to send a clear-text password)
I'm sorry, I have decided to not apply this. I'm afraid this will just bloat the feature list of ioquake3. Ioquake3 is not a very secure protocol by design. If you can sniff a client connection, you can use the MD5 password during the session where it is valid (speak: the legitimate client is still connected) to change the rcon password to anything you like.
Created attachment 2497 [details] Adds Com_MD5String() and sv_MD5 to use a MD5 hash instead of clear-text rconPaswsword Here is a small patch to slightly improve the security by proposing an alternative to sending a clear-text password over the network. This small patch introduces the possibility to avoid sending a clear-text password over the network by using a MD5 hash instead; the provided code uses this facility with the 'rconPassword'. The compatibility with legacy clients or servers is also maintained, ie a MD5-enabled server still allows legacy clients to send a clear-text 'rconPassword' and vice-versa. Basically, the patch introduces a new function, Com_MD5String(), which take a string with an optionnal prefix and returns the calculated MD5 hash. A new cvar, 'sv_MD5', is added in the server and propagated through the server infostring to let any clients know about the MD5 availibility. To avoid sending the password by itself (either in plain-text or its MD5 counterpart), the MD5 hash is created using the 'rconPassword' prefixed by the client's current challenge; 2 clients on the same server will then send 2 different MD5 hashes.