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 while.

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

Reply via email to