Joris Bontje wrote: > When reading the cvs mailinglist I noticed that mark disabled the encryption > of passwords for crossfire on FreeBSD. I think this is an extremely bad > thing for security and compatibility reasons. > > I don't understand why this is needed. 2 years ago this item showed up too > and was addressed in the mailinglist see http://mailman.real-time.com/pipermail/crossfire-devel/2000-November/000597.html > > and be sure to check the followups. > > If the solution was to do SHA1 encryption (or MD5) for all platforms by default, > I would have seen the use. But decreasing the security doesnt sound good. I don't consider this as a big deal as it might have been in the long ago past. Putting in some other protection mechanism could be done. But in most cases, the users don't have access to the player files (either because they can't actually log into the system, or the player files have permissions preventing random people from reading the files). Note that if players can read player files at will, this allows some other perhaps less direct means of cheating (hmm. Wonder what this item really does? Let me look at my player file). The reason the change was made was from a bug on sourceforge with the current method not working on freebsd systems without des_crypt. It seemed just as easy to remove that logic all together. Note that the security of crossfire is not that high - the password is sent from the client to server in plain text. For many systems, the password uses standard crypt, which is only 56 bits. Since the password is stored in the player file, it also means that if a user has access to that file, cracking a password probably won't be that difficult. Now it sounds like a better approach for freebsd might to be use des_crypt if available, and if not, use plaintext password. From the bug on sourceforge, that would probably fix the problem.