[crossfire] Challenge-Response login, proof of concept implementation ready

[AnMaster]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



Mark Wedel wrote:
| AnMaster wrote:
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA512
|>
|> I have locally a proof of concept challenge-response login for use in crossfire
(HMAC-SHA256).
|>
|> However how should it be added to server protocol exactly, setup command? I'd prefer
|> upgrading protocol version.
|
|   Depends on a few things.  Do you expect this change to only be in the trunk,
| or also backport to the stable release?
|
|   If only in the trunk, then perhaps increasing the protocol version, and making
| that the only supported authentication method in fairly short order may be the
| right thing to do.  For the trunk, we are not guaranteeing a lot of backwards
| compatibility.
Yes trunk only, however existing player files need to be supported.
|
|   However, the stable release does guarantee some level of backwards
| compatibility.  The problem with the protocol version (and why setup is often
| used instead) is that with just a number, it is not clear what has changed and
| if in fact and old client can operate on that newer server.
|
|   Also, before committing any changes, the proposed protocol changes should be
| documented (like the current protocol commands - what does the server & client
| send to each other.  That provides more concrete examples of how the changes
| will be implemented, and allows for better/more meaningful conversation.
Agreed it got some issues so I need to rework parts, however I'm on vacation without
internet and without computer for a few days from tomorrow morning (just finished packing,
late night now), so work will continue in a bit.
|
|> Backward compatibility would be supported by plain text login once and then upgrade
|> password in player file to store the "shared secret", then HMAC-SHA256 would be used in
|> future to log in. I feel that it is less of an issue storing an unencrypted shared secret
|> on the server than, as we currently do, sending it in plain text over network.
|
|   Almost certainly true - file access controls on the server itself can still be
| used to prevent unauthorized folks from looking at the player files.  And for
| many systems, the password actually is stored in plain text (look at the #if in
| crypt_string())
Yes, however my freebsd system will use des_crypt it seems. And my linux uses crypt().
|
|
| _______________________________________________
| crossfire mailing list
| crossfire at metalforge.org
| http://mailman.metalforge.org/mailman/listinfo/crossfire
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEAREKAAYFAkhUSbQACgkQWmK6ng/aMNnZPACglgat+bD7fDKNL0a2NVeLKBGK
qDgAoJLuD7bdZUcRc0nUkd+EHvpLo0UQ
=lJ77
-----END PGP SIGNATURE-----