[crossfire] Steam Protocol Proposal

Pippijn van Steenhoven pip88nl at gmail.com
Mon May 8 13:08:58 CDT 2006


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.

I am well aware of the fact that this might break compatibility but for now,
Crossfire could as well support both methods using some SetupCmd option..
say "pubkeycmd". That would certainly get rid of 1) gdb backtraces
containing passwords and 2) people sniffing passwords.

One problem exists and that is player creation. To make player creation
secure, you either do need SSL or have web-based player creation over
HTTPS, as suggested by schmorp, but I am not going into further detail on
that. Make up your own minds, this is my contribution to the issue.

Pippijn van Steenhoven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.metalforge.org/pipermail/crossfire/attachments/20060508/247a2d42/attachment-0001.htm 

More information about the crossfire mailing list