[Patch] Save passwords on server through reset - r11502

[sforget]

zDESCRIPTION: This patch will cause a server to save the Company passwords at the same time as the server creates a save, and then reload them when the saved game is restored. This allows servers to be restarted without "opening up" all the companies in the running game.

The passwords are saved to a separate file, which prevents people from obtaining passwords unethically (ie. by dissassembling the saved game file).

KNOWN BUGS:

• Password are loaded even if another save game is loaded on a server - eg. a game with a different map (FIXED)
• Passwords are currently not encrypted, as this is a server side thing, encryption isn't super important as why would an Admin attack his own server?(FIXED)

FIXED BUGS:

• Passwords are stored in separate files for each map, thus allowing multiple password-map combinations
• Passwords are now written in such a way as to not be directly readable by a user

So far bug testing has yielded no bugs and the code is stable and reliable.

My first patch, but hopefully worthwhile.


Edit - Nov 30, 8:35pm MST:

Added 0.5.3 Binaries for Linux & Windows
Added 0.6.0 Beta 1 Binaries for Linux & Windows (See My Next Post below)

[Bilbo]

What about saving passwords aside the savegame? if the save is saved to "xyz.sav", save passwords to "xyz.passwd" and load them from same file (when loading xyz.sav, look for passwords from file xyz.passwd). This way the password file would be linked to the savegame and loaded only when the corresponding save is loaded. Alternatively, save the passwords in different directory under openttd (so you can publish entire savegame directory without revealing the passwords)

Still, some slight "obfuscation" (something very simple like base64 enconding would be enough) maybe could be used to protect against "accidental peeking over shoulder".

[sforget]

I was actually attempting to do the very thing at first, however the "filename" parameter hat I can find contains a complete path, which I don't want.

I've just started with C++ and am still uncertain on many aspects like memory usage and such (I ran into a problem here once already). Very different than PHP, but I am still working at it.

I was planning to incorporate some sort of encoding on the passwords after everything else was sorted out. That way I can keep examining the file until I feel the patch is finished, and then encode it to avoid "prying eyes".


EDIT: Nov 30, 2007 10:04pm MST

Added binaries to this post for 0.6.0 Beta 1 - both Linux and Windows

Added here to keep them on the first page

EDIT: Dec 1st, 2007 - 5:15pm MST

Added Source files for 0.5.3 as required by license. These are the files direct out of my source tree as I don't know how to do patch files without SVN.

[Bilbo]

Well, since the decoding routines would be present in the binary itself (or in openttd source in general) is is useless trying to apply some strong encryption, but some slight "obfuscation" is enough to avoid accidentally revealing the passwords when someone is peekeing over admin's shoulder or such ...

[Sacro]

You should never encode passwords, instead you should salt and hash them, then they cannot easily be found.

[Bilbo]

Yes, that would be good idea, but first such feature must be added to core openttd itself.

But while it is true that admiin won't hack their own server, situation that these password files are read by an attacker is quite likely (admin will accidentally publish the files alongside with saves, config, or someone break into the admin's server, etc ... reading the files is much easier for attacker than intercepting passwords from openttd's memory)

Hashes/salts will make that less feasible (but still crackable, at least for simple passwords)

[sforget]

But while it is true that admiin won't hack their own server, situation that these password files are read by an attacker is quite likely (admin will accidentally publish the files alongside with saves, config, or someone break into the admin's server, etc ... reading the files is much easier for attacker than intercepting passwords from openttd's memory)

That would have to be one determined attacker. To go through all that trouble to cause problems on a small game server is pretty desparate and IMO, not likely to happen. It's not as though we are pretoecting national security or anything even remotely critical.

Yes, hashing or obfuscation will protect against bad-admins but the idea of someone cracking a server just to gain access to an OpenTTD game is pretty extreme.

[Bilbo]

Yes, hashing or obfuscation will protect against bad-admins but the idea of someone cracking a server just to gain access to an OpenTTD game is pretty extreme.

Cracking the server is unlikely, but admin accidentally publishing the passwords alongside with the savegames is IMHO quite likely scenario.... that is where the hashing could be used.

[Korenn]

Passwords are currently not encrypted, as this is a server side thing, encryption isn't super important as why would an Admin attack his own server?

From an admin standpoint, that's not a problem. But from a user standpoint, it is. If you have the habit of using a single password for all of your online ottd games (which most people in my experience do), you don't want that password to be so easily ready by the admin of a server that you're playing on.

You're assuming that admins are good guys. They generally are, but like everywhere else in society, there are those that are not.

[sforget]

First Post Updated: New version of patch



FIXED BUGS:

• Passwords are stored in separate files for each map, thus allowing multiple password-map combinations
• Passwords are now written in such a way as to not be directly readable by a user

[Bilbo]

Passwords are currently not encrypted, as this is a server side thing, encryption isn't super important as why would an Admin attack his own server?

From an admin standpoint, that's not a problem. But from a user standpoint, it is. If you have the habit of using a single password for all of your online ottd games (which most people in my experience do), you don't want that password to be so easily ready by the admin of a server that you're playing on.

You're assuming that admins are good guys. They generally are, but like everywhere else in society, there are those that are not.

Well, what could be done is to use some "automatic password management system" :)

It could work like this:

You set up your personal password in options, which gets stored in openttd config or somewhere alike.

When you connect to server, the server's IP is concatenated with you password and md5 hash of it is made.
This way, you will make unique server-specific password from one master password and nobody can reverse the process and discover master password (or server-specific pasword for another server) from the server-specific password (except by using bruteforce attack, of course)

The "enter password" and "set password" dialog will contain "fill in" button, which will fill in that hash. (optionally, when creating new company, the password would be automatically set, often people forget it :)

Passwords itself remains the same and server admin obtaining one password can't "unhash" it - he can't abuse it on another server :)

Plus, the password would be stored, so you can pick someting more secure, as you won't be typing it over and over.

[rabbit67890]

Passwords are currently not encrypted, as this is a server side thing, encryption isn't super important as why would an Admin attack his own server?

From an admin standpoint, that's not a problem. But from a user standpoint, it is. If you have the habit of using a single password for all of your online ottd games (which most people in my experience do), you don't want that password to be so easily ready by the admin of a server that you're playing on.

You're assuming that admins are good guys. They generally are, but like everywhere else in society, there are those that are not.

Well, what could be done is to use some "automatic password management system"

It could work like this:

You set up your personal password in options, which gets stored in openttd config or somewhere alike.

When you connect to server, the server's IP is concatenated with you password and md5 hash of it is made.
This way, you will make unique server-specific password from one master password and nobody can reverse the process and discover master password (or server-specific pasword for another server) from the server-specific password (except by using bruteforce attack, of course)

The "enter password" and "set password" dialog will contain "fill in" button, which will fill in that hash. (optionally, when creating new company, the password would be automatically set, often people forget it

Passwords itself remains the same and server admin obtaining one password can't "unhash" it - he can't abuse it on another server

Plus, the password would be stored, so you can pick someting more secure, as you won't be typing it over and over.

what if someone finds the password and destroys

[Rubidium]

And what if we ask somebody to post his openttd.cfg because we need to debug something? Do we want to add a disclaimer each and every time that they should remove the password from it? Doesn't sound like a workable scenario to me.

[Bilbo]

Ok, store it not in openttd.cfg but "somewhere alike" .... in same directory as openttd.cfg, but in different file (openttd.passwd?) First few lines of the file would contain some "disclaimer" (like "this is your passwotrd, do not tell it to anybody"), last line would be the password itself

[XeryusTC]

And what if we ask somebody to post his openttd.cfg because we need to debug something? Do we want to add a disclaimer each and every time that they should remove the password from it? Doesn't sound like a workable scenario to me.

SHA-512?

[sforget]

Please stay on topic....

This patch relates to a server saving the passwords for companies in the currently running game. This way a server can be reset without losing passwords for the servers players.

I will update the thread title to better show this.

I will never write this patch so the passwords be saved in the cfg file, nor directly to the saved game. They will always be saved in a separate file to help maintain security. In fact as the current release is stable and reliable, the only thing that will probably change is the directory where the passwords are saved.

[wleader]

Not that I expect you to run right out an change the code, but a common method for hiding passwords from the administrators as well is to store a hash value instead of the password. For the benefit of those that don't understand, here is a brief explanation.

When the initial password is sent the server runs that value through a hashing algorithm like MD5. In theory the resulting hash is just as unique as the original password. This hash value is then stored for later use. (File, Database, RAM, wherever). Later when the client wants to authenticate again the password is hashed again, and the two hash values are compared. If the two hashes match, it is safe to assume that the two passwords also match.

Now this is by no means a bulletproof system, there are still some points where the password is still vulnerable. For example, there will be a time when the plain text password may get transmitted over the network, or is available in RAM (both flaws that exist in the current OTTD AFAIK.) It does however prevent plain text passwords from being stored, which eliminates a very common attack vector.

[Bilbo]

Not that I expect you to run right out an change the code, but a common method for hiding passwords from the administrators as well is to store a hash value instead of the password. For the benefit of those that don't understand, here is a brief explanation.

It will not work against an "evil" administrator. Modifying openttd source code so that plaintext password gets logged to some file is quite trivial. But storing hashes instead of plaintext would work when the pasword file is accidentally published (oops, I shared entire openttd directory including config and all saves ... ), or the server is hacked and the file downloaded (if passwords in memory are also hashed, your only option is to crack the hash or wait for the client to connect again (well, breaking client's connection is easy...) and re-enter the password (so you can sniff it). But if that game no longer runs ... no passwords for hacker)

Hashes can be cracked, but for stronger passwords the effort is far from trivial.

[richk67]

Trivial? Depends. Ive suggested using PKI for this, and then discarding the private key. The server cannot then decrypt the password, and the password is only ever sent encrypted with the public key. Passwords are stored as encrypts on the server, and the client sends the Public Key encrypted password for comparison with it. This would be safe from the evil administrator, and from accident publication.

Somebody complained that it can be cracked. If you throw enough time and computing power at it, sure. But by then the game will be dead and gone. You probably only need 128bit keys... nothing too radical. Lets face it, we're only protecting people hacking into a computer game, not credit card transactions (my day job).

The only problem is that the only module I have that does PKI uses a Windows based .dll, so no good for *nix developers et al.

[DaleStan]

Trivial? Depends. Ive suggested using PKI for this, and then discarding the private key. The server cannot then decrypt the password, and the password is only ever sent encrypted with the public key.

I hope I'm missing something, but it sounds like the server is generating the keys. This provides precisely zero evil-administrator security, as there's nothing preventing the admin from keeping the private key. And if the client is generating the keypairs, why not just use SHA-1, or some other strong hash?

If you're trying to protect against an evil administrator, the solution is simple: never use the same password for two different things.
This way, the evil administrator has a password that allows him to login to his server as you (which he could already do anyway), but doesn't allow him to do anything else.