Current login sends account password in plain text.

[SilverNexus]

I was having some fun with a bootable Kali Linux USB I set up, and decided to Wireshark my local Crossfire session.

Incidentally, I discovered that the account login sends your account password in plain text over the network to be hashed on the server side. Depending on whether users recycle their passwords, this could be a rather major security flaw in the current communication system.

I currently have a few ideas of ways this could be remedied, and feel this should be discussed among developers to decide which is best for the project.

Solutions:
1. Hash the password on the client side.
Pros: This ensures that the password can't easily be sniffed over the network and used to hijack someone's account (again, this is where password recycling is a huge factor). It also frees up a little extra server time on each login, since its not doing a whole hash on every login.
Cons: The current server implementation uses crypt(3) (or it did last I checked), so any Linux, Mac, or BSD builds of the client shouldn't be too difficult to do. I do not know, however, if there is a good crypt(3) implementation in Windows; such a transition may require the use of a different password hashing library. Additionally, it instead requires the salt for the hash to be sent to the client before the client can hash its password. This makes sniffing the password salt/hash a two-step process, which would then be followed by some password cracking as a third step. This method would not protect against a replay attack, either.

2. Encrypt the packet that contains login information.
Pros: This should be doable from within cURL, so we wouldn't need a new dependency to ensure cross-platform usability.
Cons: There would need to be a way to distinguish the encrypted packet on the same socket; unless we encrypt all the communication (which seems like overkill), we have a single encrypted packet among dozens of plaintext packets. There may not be a way to encrypt the packet without establishing a specifically secure connection.


Anyone else is free to point out advantages, disadvantages, or entire options I overlooked. I'm not a security expert (at least, that's not where my education and training lies), so I may have easily missed and/or misjudged important factors.

[mwedel]

This was somewhat intentional design.

In the first case (hash on client side), it really doesn't do any good. If someone is snooping the network, they just snoop the hashed password and can then modify their client to just send that hashed password to log in as someone else (in a sense, it doesn't matter what the server is comparing against if the client is generating it). The two phase method (client gets salt to use from server) is better, but if someone is actually sniffing passwords and is able to sniff enough of them (seeing the salt and response from client), it perhaps just making hacking a little more difficult.

Note that the password itself has been stored as plaintext for a long time in the player file itself - this was again a simplification, and also made password recovery a lot easier.

I've not looked a lot at curl - to send a separate encrypted packet would require that the server (probably though curl) listens on a different port for the incoming packets. This adds a fair amount of complication to the entire process. Also, one has to be sure that all packets that may contain potential private data (password change requests, party passwords, etc) would be similarly encrypted.

The correct secure approach would just be to use ssl for the entire connection - then the concern about other packets goes away (everything is encrypted), and given modern computers and the amount of data sent, the perf hit for doing that probably isn't that high. As a plus, I think that the SSL handling could also compression to the packets (at least looking at openssl). This probably isn't as daunting as it sounds, because all the socket handling in both the client and server are pretty well isolated, so adding the code for openssl only touches a couple files.

Note that the current insecure method was done for simplicity and the fact crossfire was not seen as something people would likely try and hack into. That isn't really the right approach, but presumably people aren't storing the credit card numbers on the crossfire server. It also goes back somewhat to the original method was just remote X-display, in which case one would just sniff for keypresses, so that was not secure.

However, any change to the method would have to remain backward compatibility for some time (for older clients). It may be that the server prints a message like 'you are using an insecure client - please upgrade'. I also suspect, like the curl method, that the server would probably listen on a different port for the SSL connections.

[SilverNexus]

presumably people aren't storing the credit card numbers on the crossfire server

I realize that. I worry more about people who use the same password for everything; for those people, we aren't doing due diligence to ensure their password stays safe.

In the first case (hash on client side), it really doesn't do any good. If someone is snooping the network, they just snoop the hashed password and can then modify their client to just send that hashed password to log in as someone else (in a sense, it doesn't matter what the server is comparing against if the client is generating it).

That's very much what I feel about that option. But it was early in the morning, and I thought it was viable until I thought more about it. Replay attacks just blow right through that entire concept and snicker at the feebleness of it.

The correct secure approach would just be to use ssl for the entire connection

Looking more closely at this, encrypting all communication would probably be easier and cleaner than encrypting part of it. It would also mitigate the ability of someone to start spoofing commands to the server to convince the server you are doing things you aren't (though not as malicious as stealing your password, its still could be an issue should someone take the time to do it).

Note that the current insecure method was done for simplicity

Ah simplicity. Both the bane and boon of our existence.

[mwedel]

In the case of someone using the same password for a lot of stuff (bank accounts, etc), in that case, hashing on the client does help out. Someone can snoop that hash, but doesn't know the plaintext password.

Still totally insecure as far as someone getting the password to the account.

Going SSL would be the right approach. I'm not sure the state of libssl at the time the client/server was first written - certainly a lot of new libraries and utilities exist now (and in common distribution) than existed at the initial implementation.