glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[glob2-devel] Encryption, security, and a new glob2 dependancy


From: Bradley Arsenault
Subject: [glob2-devel] Encryption, security, and a new glob2 dependancy
Date: Tue, 1 May 2007 20:22:43 -0400

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]