| 02:52.51 | blast007 | I've been thinking about how best to replace our aging token-based authentication system - reason being that it won't work well if we want to have multiple nodes for redundancy, and it will also not work well (or at all) for when we want to support IPv6 (since we do IP checks to prevent token theft) |
| 02:55.45 | blast007 | so I think one solution would be using public key cryptography. Each game server would generate a public/private key pair at startup and pass the public key to the game authentication node, and then the game authentication node and the game server can pass messages back and forth through third parties (like the game client) without those third parties being able to read or alter the information |
| 02:56.10 | blast007 | rough idea of how that would work is here: http://static.bzexcess.com/bzflag_services_documentation/flowchart.png |
| 02:56.52 | blast007 | the top part is showing a game server doing initial startup, and the second part is a client going through the steps to connect to a server |
| 02:57.46 | blast007 | one part I'm not sure how best to implement is our -advertise function on game servers.. since in this current plan, the game authentication node and master server list node are separate pieces |
| 03:00.12 | blast007 | so perhaps splitting the auth and list into separate pieces is overkill. I think I had done that for security reasons (lowering the attack surface of things that handle passwords) |
| 03:01.44 | blast007 | we'd probably want some sort of expiration on the encrypted messages as well so they can't be recorded and used later, and we'd also be encryption the actual communcation between components with HTTPS/TLS or similar |
| 03:02.05 | blast007 | also be encrypting* |
| 03:04.29 | BulletCatcher | It provides much more security than we need, but Kerberos is a mature cross-platform authentication system that I think will meet the other requirements. |
| 03:07.43 | blast007 | kerberos certainly inspired the above. I'm not sure if kerberos can use strong hashing algorithms like bcrypt, though. |
| 03:09.16 | BulletCatcher | Kerberos derives its strength more from encryption than hashing. |
| 03:10.33 | blast007 | right, but I also want to reduce the likelyhood of successful password reverse engineering in the event of a compromise |
| 03:10.47 | BulletCatcher | Compromise of what? |
| 03:10.58 | blast007 | an auth node or the database server |
| 03:11.10 | blast007 | well, probably more the database server |
| 03:11.30 | blast007 | if they get the auth node, plain text passwords will get sent right to them ;) |
| 03:12.29 | blast007 | OpenLDAP only has an experimental plugin for bcrypt and it says not to use it for production |
| 03:19.29 | BulletCatcher | The primary form of protection for the Kerberos pricipal databse is encryption (e.g., using AES). |
| 03:19.30 | BulletCatcher | Passwords are hashed within that, but it is expected that the focus will be on securing the AES key so that there is never an opportunity to brute force the hashes. |
| 03:32.36 | blast007 | encrypting password hashes was also something I came across in my searching (mentioned in http://stackoverflow.com/questions/16891729/best-practices-salting-peppering-passwords/16896216#16896216 ) |
| 03:33.22 | blast007 | kerberos was something I wanted to look into in more detail, though |
| 03:34.31 | BulletCatcher | Microsoft Active Directory is based upon Kerberos, so you may already know about it than you think. :-) |
| 03:36.19 | blast007 | yes, which makes it somewhat difficult to find good information because you're finding a lot of AD based information that may not apply to the normal kerberos |
| 03:37.14 | blast007 | embrace, extend, extinguish ;) |
| 03:37.36 | BulletCatcher | The differences between MIT Kerberos (typically seen on unix systems) and AD Kerberos are fairly minor. |
| 03:38.36 | BulletCatcher | If an AD conroller is already available I would expect it to be satisfactory for our purposes. |
| 03:39.39 | blast007 | installs Windows Server 2003 on the list server |
| 03:46.58 | blast007 | http://web.mit.edu/Kerberos/krb5-1.12/doc/admin/enctypes.html#enctype-compatibility and http://web.mit.edu/Kerberos/krb5-1.12/doc/admin/conf_files/kdc_conf.html#encryption-types are good information about the hashing/encryption that can be used |
| 04:24.00 | *** join/#bzflag rob1n (rob1n@unaffiliated/rob1n) |
| 04:49.14 | *** join/#bzflag Chestal (~thilo@vmax.unix-ag.uni-siegen.de) |
| 04:49.14 | *** mode/#bzflag [+o Chestal] by ChanServ |
| 08:48.16 | *** join/#bzflag contempt (contempt@unaffiliated/contempt) |
| 08:56.49 | *** join/#bzflag contempt (contempt@unaffiliated/contempt) |
| 13:54.37 | *** join/#bzflag Cute_Koa (b2a4a8aa@gateway/web/freenode/ip.178.164.168.170) |
| 14:23.22 | blast007 | I do recall that there was an attempt at one point to implement Kerberos.. probably back in the early 2.0 versions |
| 14:24.54 | blast007 | seems we removed some of the last reminants of it as recently as 2012 :) |
| 14:26.54 | blast007 | but perhaps either Kerberos or a public-key based system are both overkill.. |
| 14:31.44 | *** part/#bzflag Cute_Koa (b2a4a8aa@gateway/web/freenode/ip.178.164.168.170) |
| 14:32.09 | *** join/#bzflag Cute_Koa (b2a4a8aa@gateway/web/freenode/ip.178.164.168.170) |
| 16:06.09 | BulletCatcher | They may be overkill for the level of security we need, but integrating an existing authentication system is likely to be easier than inventing (once again) our own. |
| 16:17.16 | blast007 | possibly |
| 17:36.04 | *** join/#bzflag DTRemenak (~DTRemenak@cpe-76-90-124-134.socal.res.rr.com) |
| 17:36.04 | *** join/#bzflag DTRemenak (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 17:36.04 | *** mode/#bzflag [+v DTRemenak] by ChanServ |
| 20:01.15 | kierra | omw, chatting with sniper 50 on bzflag......long long time |
| 20:01.27 | kierra | Chestal, he asked about you, sends greets |
| 20:32.58 | *** join/#bzflag [Gort] (~gort@unaffiliated/gort/x-9231432) |
| 23:05.48 | *** join/#bzflag Cobra_Fast (~coprah@wtwrp.de) |
| 23:18.56 | *** join/#bzflag AAA_awright (~aaa@2607:5300:60:7d4::1) |
| 23:31.06 | *** join/#bzflag timvishe_ (~tim.vishe@pool-72-92-23-217.phlapa.fios.verizon.net) |
