Pippijn van Steenhoven wrote: > Hi, > > just one thing about SSL streams. I suppose they would be used to transmit > passwords from the client to the server? Well, if the model was changed and > the password would not even be transmitted, there would be no need for such > streams and the entire code would be a lot smaller than it would be with > SSL streams implemented. Look at how public key authentication works. You > just send a hash, the server checks whether that hash equals the one in the > player file and ... and and you get the picture. Public key authentication.
This depends on what why are trying to protect. If the concern is that people are using the same password on crossfire as other services, this works - you can't find out a users common password by looking at crossfire. Pretty much any one way method that obfuscates the password works (one way hash, etc) However, if we are looking to also make the crossfire passwords more secure, this doesn't work so well - one just grabs the hash in the player file (core file, whatever), and just hack the client to send that hash. Now true public key can be used, with the player file storing one key, and the other being transmitted. That helps in the core dump/player analysis (that one key doesn't do any good), but doesn't help out much in the case of people sniffing - you just sniff what the client is sending to the server, and once again, hack your client to send that same byte sequence. My personal thought is that starts to over engineer this - I somehow doubt there are people out their sniffing the network for crossfire passwords. Core dumps/stack traces could be made secure - store the player password in something like <playername>.pw and not in the password file itself. Thus, when a player logs in, password compared with that in that file, but once that is done, we don't need to keep the password in memory anymore. It has to be kept in memory right now so we know what to write out when saving the player. _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
