Hi,<br><br>just one thing about SSL streams. I suppose they would be used to transmit<br>passwords from the client to the server? Well, if the model was changed and<br>the password would not even be transmitted, there would be no need for such
<br>streams and the entire code would be a lot smaller than it would be with<br>SSL streams implemented. Look at how public key authentication works. You<br>just send a hash, the server checks whether that hash equals the one in the
<br>player file and ... and and you get the picture. Public key authentication.<br><br>I am well aware of the fact that this might break compatibility but for now,<br>Crossfire could as well support both methods using some SetupCmd option..
<br>say &quot;pubkeycmd&quot;. That would certainly get rid of 1) gdb backtraces<br>containing passwords and 2) people sniffing passwords.<br><br>One problem exists and that is player creation. To make player creation<br>
secure, you either do need SSL or have web-based player creation over<br>HTTPS, as suggested by schmorp, but I am not going into further detail on<br>that. Make up your own minds, this is my contribution to the issue.<br>
<br>Pippijn van Steenhoven<br>