Registration process changes, security model partially upgraded.

I have been doing a bit of improvement work on some aspects of the account management for this game. I have decided to move the initial account registration off of the calculator onto the Web Deck. When this change is complete (it's in progress now), attempting to log in to an account that does not exist will no longer allow you to register from your device, it will prompt you to visit the server's frontend to create your account. This is done to facilitate the follow upgraded security model. Trust me, ya'll don't want to know how bad it was before.

1) Firstly, registration on the Web Deck is now protected by recaptcha. Login does not have it.

2) Secondly, the server generates you a login "key" that will, when used from a calculator, grant it access to your account. This key is generated from your username and hashed password, using PBKDF2 (SHA256 mode), with 1000 iterations and a 16-byte salt (using PHP's built-in hash_pbkdf2() method). That resulting key is then hashed using PHP's password_hash() (bcrypt) which is saved as your "public key", and the private key (output of pbkdf2) is written into a TI application variable, which you can download from the web deck and send to any device you want to allow access to your account.

2b) It so follows that any changes to your account password invalidate any existing key files that you are using.

3) I have...after much experimentation and failure...finally figured out how to prevent Apache from allowing hot links of certain file types. I used this to protect all database files accessed by the website, as well as all .8xv and .bin files from being directly downloaded. As for why I struggled so much with it... let's just say that some of the "this is how to do it" you see on the Internet are so very wrong.

4) I may add some form of obfuscation to exchanging the login key with the server, if I can figure out how to do that.
Edit: For now, the key is exchanged with the Trek server using Blowfish (which I've added to hashlib)
The server generates a secret when you connect and sends it to the client and that is used to create the blowfish key. I may swap that out for something else when I get a bit better at this stuff.
Project Feature Question

Figure I'll put this here and let people sound off.
Regarding TI-Trek's ability to support custom assets players upload, both for terrain and for UI elements, which method of handling this would people prefer?

1) As is -- players can use the Web Deck to upload custom sprites to replace the defaults, then have a replacement graphics appvar generated that they send to their device in place of the default one. This requires end users do much of the work of keeping their graphics up to date.

2) The UI elements are served by the server as binary data and streamed to the client after successful login. Where a user has a custom sprite defined, that is served instead of the default one. Those sprites are cached into an appvar that is retained on the calculator. However, whereas in #1 the appvar would be in convimg's format, this appvar would be in a slightly different format for each sprite ( <sprite_short_name><sprite_data_size><gfx_sprite_t>). Names would correspond to their identifier on the server, allowing individual assets to be updated if need be. Data size would also be included to allow the client to seek to the correct sprite in the file. Users do not need to maintain the graphics files themselves at all, the server and client handshake on each sprite to ensure it is up to date.
Update 0.0.103

Fully automated graphics and client self-updating is now supported. When you connect, first the client version you are using is hashed and that hash is compared with the hash of the binary used by the server. If they differ, your client will be updated to the one hosted by the server. (Aside: this means that if a different server requires an earlier version, you still need to do nothing... it will be downgraded automatically).

Once you log in, the same process occurs for the graphics (this occurs post-login because some users may have custom graphics).

Of course in both cases, the integrity and completeness of the download is verified by hashing it, and if the hash matches, the client is reloaded or the graphics are initialized, otherwise the server is asked to begin the transfer again.

Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 11 of 11
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum