On 10/20/2017 05:22 PM, Preston Crow wrote:
Would it make sense to encrypt the connection between the client and the
server? I'm particularly concerned about the sending of passwords in plaintext,
as they're probably the same as other user passwords in most cases.
It would be fairly simple to wrap the server side with stunnel, but without
built-in client support, this wouldn't do any good.
I've never used openssl or similar libraries, but that would seem like the right
approach. I doubt that the added overhead would cause latency or cpu load issues.
One issues is that most servers are unlikely to get official SSL certificates,
thus having self signed ones, so while encrypted, you'd still have the problem
on a 'non verified' connections.
Also, the way crossfire buffers and sends data may not be ideal (it basically
writes the data to the OS as it is generated, and lets the OS combine the data
into larger packets). That may not be ideal for encryption or compression. And
since non encrypted connections have to be maintained for clients that don't
support it, the number of encrypted connections may not be that high for quite a
As you note, the real issue is with the password. I can't think of much else
in the connection anyone would really care about.
And one issue with the password is that it is stored on the server, plaintext
IIRC. So if the server is compromised, someone could grab the password and if
able to associate with the real person (probably due to server logs) could try
to use it elsewhere.
So what may make sense would be for the client to instead do an md5 hash or
the like of the password before it sends it to the server. This removes the
above problem (server only has the hash). The server actually doesn't really
care - it just cares that the password that the client sends matches what it has
stored away, so the client could encrypt it, hash it, whatever, and as long as
the client is consistent, server is happy.
To deal with legacy (non hashed passwords), the client could try to send the
hashed password first for login. If that fails, send the raw password. If that
works, prompt the user, asking if they want to switch to a more secure password
measure, at which point the client just send the request to change the password.
The only issue here is that once a client switches to a hashed password, you
can't go back to a client that doesn't support it.
This still isn't quite as good as encryption, as if that hash is compromised
(packet capture or server compromise), it would let the person access that
crossfire account. And since people may be likely to use the same password on
other crossfire server, this then gives them access to those others.
One possible way to mitigate that would be that the client add some data to
the hash based on each server, so every server would have a different hash, even
with the same plaintext password. The one issue here is that whatever is used
most be consistent (if you used hostname, and it changed, that wouldn't work).
And while the client could just randomly choose something and store it away, you
have an issue if you are on a different computer, loose that special key, etc.
(btw, with all of the above, I'm not saying that encrypting the connection is
a bad idea, but that still doesn't fix the issue of the server having a copy of
a plaintext password. The server itself could of course md5 hash the passwords
on its own, so that the plaintext is only stored in memory (briefly) during
authentication. Way back when, the server would crypt the passwords, but that
wasn't very secure at some point, as a computer could full decrypt all
combinations in not much time)
crossfire mailing list