Cheap security for web-based games!

h3. This is new to me, but I imagine true security fiends have already thought about this issue plenty, so I apologize if I’m repeating “news” that’s already been mentioned.

I came across an interesting security mechanism in my quest to automate some “Kingdom of Loathing”: stuff in ruby the other day. Their login system isn’t hosted on a “secure” server, which means that (under normal circumstances) anybody can snoop the network traffic, get your password, and end up stealing your account.

For a web-based game, this isn’t (usually) a big enough reward for the time spent sniffing through network traffic and hacking the account, so most such games haven’t got any security on their login forms (including my web-based games, though I may change this when I’m hugely successful). For online banking, obviously the rewards are much higher, so those sites need to be secure.

But what is it to be a secure web site? At the time of this writing, I’m of the belief that it costs a good deal of money to have essentially public-domain technology applied to a web site in order to get the stupid little “this site is secure” icon that makes people willing to put credit card, social security, and other private data into a web form.

I’m not saying that “VeriSign”: is just in the business to rip people off – they provide a lot of services other than just encryption. My problem is merely that the technology of encrypting sensitive data, and assuring a user that a site is safe, shouldn’t cost an arm and a leg, especially for low-traffic sites such as a niche web game, where annual profit may be as low as one or two thousand dollars.

The technology used for website security is pretty basic, really. I mean, it’s powerful stuff and considered unbreakable, but the same security is available in libraries for dozens of languages for free – it’s just strange to me that these algorithms cost so much money ($500+ per year) to implement on a web server. Which brings us back to “Kingdom of Loathing”:….

I was writing a little script to automate login, trading, and some other minor things in this game. When I reached the login I found a very interesting twist – when you submit the form, your password is not sent to their servers. Instead, your password is processed and altered quite a bit: * The server sends your browser a session-specific “challenge” code, which is essentially a one-time code for encryption (yes, I tried using the same code multiple times with no luck, which makes me think it’s probably stored on the server with your session data). * Your browser uses javascript to first get an MD5 of your password, then an MD5 of that value concatenated with the challenge code. * This final MD5 is what’s sent to the servers.

This system doesn’t provide what VeriSign provides – it is only encrypting data going from the browser to the web page, not an entire area of the site. Incoming data is totally unprotected, which can be problematic in some cases (although I’d bet clever javascript could fix that to some extent by using true two-way encryption). And let’s face it, simply using a couple MD5 hashes and one-time keys isn’t enough to guarantee security. I’d imagine if the reward was high enough, somebody could figure a way to capture the data for a while, analyze it, and eventually work out either a password or else a security hole of some kind.

But it isn’t so much about having 100% security in this case – it’s about having “good enough” security for the situation. If the rewards aren’t worth the time, even a simple “Caesar cipher”: is good enough security. And if we could implement a decent key exchange for a more powerful encryption system (“Diffie-Hellman”: plus “AES / Rijndael”:, for instance), we could ensure that small pieces of a site were 100% secure “for free”. From my minimal research, it does appear that many encryption algorithms do already exist in javascript.

So for all the web game developers out there, or other small-profile sites – if the only security you truly need is a few form passwords here and there, this MD5 solution used by KoL is probably not a bad fit. And if you need more security, a fully javascript solution shouldn’t be discounted, especially if you need high (but not necessarily perfect) security, but don’t have the extra money to pay for it.