I've been working on my long term replacement system for the authentication server. Most of the server side management/login is done.
My ToDo list is as follows:
1) Finalize exactly how this login process initializes with the start of a client's connection. I'm hoping to put the client in a sort of semi-joined "limbo" while the server verifies their key information, with ordinary loading after verification. (Mostly figured out)
2) Complete/Debug an MD5 sum computing function. (About half way done)
3) Complete/Debug the big-integer script. (About a third of the way done)
4) Write the client side account creation wizard, and client logic. (Not started)
5) Write the authentication authority key signing program. (Not started)
6) Write the first (centralized) list server. (Not started)
- Make a public beta release at this point-
7) Start thinking about t-mail, browser, and chat replacements.
So far, the verification workload of the game server is relatively light. The game server needs to preform at most 2 modular exponentiations (using very small exponents). The first is to verify the integrity of the authentication authority signature on the client delivered key. The second is to verify the client has the private key they claim they have.
Maybe we could make it so TCMS can allow people on LAN and people online to play together!
It would be some work, though, since LAN peoples don't have GUIDs...
Maybe we could make it so TCMS can allow people on LAN and people online to play together!
It would be some work, though, since LAN peoples don't have GUIDs...
It would be some work because LAN players can't query or connect to online servers, and I believe it is the same case vice versa.
There would need to be more modification to the T2 executable to remove those checks... and somehow do it without breaking compatibility with unmodified T2 clients.
#4(Thyth's List) Would actually help get more people into tribes who get a copy from others. From there, they could create their own accounts and use the other points thyth mentioned.
It isn't about how long the official servers have been offline... it is about meeting authentication needs for T2 in a permanent manner, not just the stop-gap temporary systems.
Krash's system, while it works, has some pretty serious security flaws. There is no way to achieve perfect forward secrecy using symmetric cryptography (in this case, the secret auth code key), thus, there will always be severe weakpoints in such an authentication system.
If I installed that system on Clockworks, and started logging every use of that command with the corresponding GUID, I could impersonate anyone that logged in using my server.
The more servers that participate in the authentication scheme, the weaker it becomes to tampering.
If I installed that system on Clockworks, and started logging every use of that command with the corresponding GUID, I could impersonate anyone that logged in using my server.
If I installed that system on Clockworks, and started logging every use of that command with the corresponding GUID, I could impersonate anyone that logged in using my server.
The more servers that participate in the authentication scheme, the weaker it becomes to tampering.
I had considered the issue, but as the script wasn't really intended as a permanent solution, it didn't seem quite necessary to go into a more thoroughly secured system.
As it stands, I'd recommend using the code only on servers you'd trust not to make use of it to their own ends, or using the "Reset Auth Code" option in the UserCP if you believe your code may be compromised. It'd usually be limited to one or two resets pre day, but isn't at the moment.
I had considered the issue, but as the script wasn't really intended as a permanent solution, it didn't seem quite necessary to go into a more thoroughly secured system.
Exactly. My system is designed to be a permanent solution.
Comments
My ToDo list is as follows:
1) Finalize exactly how this login process initializes with the start of a client's connection. I'm hoping to put the client in a sort of semi-joined "limbo" while the server verifies their key information, with ordinary loading after verification. (Mostly figured out)
2) Complete/Debug an MD5 sum computing function. (About half way done)
3) Complete/Debug the big-integer script. (About a third of the way done)
4) Write the client side account creation wizard, and client logic. (Not started)
5) Write the authentication authority key signing program. (Not started)
6) Write the first (centralized) list server. (Not started)
- Make a public beta release at this point-
7) Start thinking about t-mail, browser, and chat replacements.
So far, the verification workload of the game server is relatively light. The game server needs to preform at most 2 modular exponentiations (using very small exponents). The first is to verify the integrity of the authentication authority signature on the client delivered key. The second is to verify the client has the private key they claim they have.
Maybe we could make it so TCMS can allow people on LAN and people online to play together!
It would be some work, though, since LAN peoples don't have GUIDs...
I'm making a thread that explains the whole process as we speak, for constructive criticism and such.
There would need to be more modification to the T2 executable to remove those checks... and somehow do it without breaking compatibility with unmodified T2 clients.
Thinking too fast seems less likely to make things that work.
yep...
Krash's system, while it works, has some pretty serious security flaws. There is no way to achieve perfect forward secrecy using symmetric cryptography (in this case, the secret auth code key), thus, there will always be severe weakpoints in such an authentication system.
If I installed that system on Clockworks, and started logging every use of that command with the corresponding GUID, I could impersonate anyone that logged in using my server.
The more servers that participate in the authentication scheme, the weaker it becomes to tampering.
I'll try again and come back in a few to give you the exact message.
I had considered the issue, but as the script wasn't really intended as a permanent solution, it didn't seem quite necessary to go into a more thoroughly secured system.
As it stands, I'd recommend using the code only on servers you'd trust not to make use of it to their own ends, or using the "Reset Auth Code" option in the UserCP if you believe your code may be compromised. It'd usually be limited to one or two resets pre day, but isn't at the moment.