From pc-crossfire06 at crowcastle.net Fri Oct 20 19:22:17 2017 From: pc-crossfire06 at crowcastle.net (Preston Crow) Date: Fri, 20 Oct 2017 20:22:17 -0400 Subject: [crossfire] encrypting the connection Message-ID: 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. From mwedel at sonic.net Sat Oct 21 14:10:10 2017 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 21 Oct 2017 12:10:10 -0700 Subject: [crossfire] encrypting the connection In-Reply-To: References: Message-ID: <17ce9209-69ae-c78a-65d1-4abbe3514dae@sonic.net> 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) From kevinz5000 at gmail.com Sat Oct 21 14:43:55 2017 From: kevinz5000 at gmail.com (Kevin Zheng) Date: Sat, 21 Oct 2017 12:43:55 -0700 Subject: [crossfire] encrypting the connection In-Reply-To: <17ce9209-69ae-c78a-65d1-4abbe3514dae@sonic.net> References: <17ce9209-69ae-c78a-65d1-4abbe3514dae@sonic.net> Message-ID: <17178503-93df-7cbe-4caa-831b5235e117@gmail.com> On 10/21/2017 12:10, Mark Wedel wrote: > 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. It's certainly possible to wrap things in STARTTLS. An implementation for the client and server that can be disabled at compile time would certainly be welcome. > ?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. Currently the passwords are hashed with crypt() on Linux and in plaintext on BSD and Windows (due to a legacy #ifdef). There are eventual plans to get them hashed with scrypt() or bcrypt() on all platforms with a path for migration. -- Kevin Zheng kevinz5000 at gmail.com | kevinz at berkeley.edu | PGP: 0xC22E1090 From ruben at mrbrklyn.com Sun Oct 22 13:59:16 2017 From: ruben at mrbrklyn.com (Ruben Safir) Date: Sun, 22 Oct 2017 14:59:16 -0400 Subject: [crossfire] encrypting the connection In-Reply-To: References: Message-ID: <20171022185916.GA24695@www.mrbrklyn.com> On Fri, Oct 20, 2017 at 08:22:17PM -0400, 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. > Its just a gaim. Don't use your banking password > 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. > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013