[crossfire] encrypting the connection

[Mark Wedel]

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)