You going to redo the map engine, multiplayer games and encryption? I hope this gets completed. It would be a waste to see all that work go down the drain if you get busy.
Anyway, a few things to keep in mind: * A new dependency means more installing, which means less people likely to play it. * A new dependency means Windows build will probably take a while to build (I'll need to build whatever library you decide to use) * Its just a password for a game account. It does not store personal information, or game stats. As far as I'm concerned, you probably dont even need game account passwords. Everyone could just sign it with a username they want, like IRC (when someone hasn't registered). At the end of the day, passwords could be gotten rid of. Anyway, thats my $0.02 On 5/2/07, Bradley Arsenault <[EMAIL PROTECTED]> wrote:
I have talked to a few computer security gurus on IRC, and have learned a little bit about security and how I could achieve it. First of all, the only data that YOG transfers which could be considered sensitive is the password for a user. First of all, storing the password on the harddisk safely: I was informed that I should use a non-reversible transformation on the password, and store the transformed version. I had learned that you could use the password as the key to encrypt a string of spaces. The gurus reccomended SHA1 and/or MD5 and/or other, more difficult algorithms, and or some combination of them. They also reccomend I add salt to the password, to make it a given length. One guy jokingly suggested I use one hash as the salt for another hash, just to "mindfuck" them. Not a bad idea, thinks me. I will likely use some obscure combination of SHA1, MD5, and maybe another hash function to store the password. This is almost trivial to do, and unbreakable to a certain extent. Not that anyone will really be getting into YOG passwords anyhow. Secondly, transfer of passwords over the network: I was told that this can be done safely using an assymetric public/private key system. They suggested RSA as a general purpose system for this. Upon starting the server, it would generate its own RSA key pair (or use a cached and password protected one). When a user connects, the public key is sent down the line, and is used to encrypt the password (with some added salt). Thats really all there is to it. A man could get in the middle, but using key signing would heavily complicate things, I was informed it was not worth it, especially considering YOG stores no private information, being able to access ones username is the only thing gained from cracking ones password. One possible (and simple) solution is to have a developer-secret private key for our metaserver, and distribute public key with the game. For user hosted servers, the public key could be sent at connection, like usual. Thirdly, how are we going to do this: There are a few libraries that I was reccomended to, including OpenSSL, GPGME, and libgcrypt. libgcrypt is the best considering its just low level encryption, without the fancy key signing and web of trust, which is exactly what we need. It is also GPL compatible, unlike OpenSSL. I may try to figure out a way to import the sources, but that is starting to look grim as I examine the code, unless we imported a complete copy of the library, which may be possible. -- Really. I'm not lieing. Bradley Arsenault. _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
-- Kieran.P http://qlwiki.linuxsolutions.co.nz/
_______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
