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 kevinz5...@gmail.com | kev...@berkeley.edu | PGP: 0xC22E1090 _______________________________________________ crossfire mailing list firstname.lastname@example.org http://mailman.metalforge.org/mailman/listinfo/crossfire