Savegames in Multiplayer (Ded. srvr) don't contain passwords
Moderator: OpenTTD Developers
Savegames in Multiplayer (Ded. srvr) don't contain passwords
Hello,
I noticed that when restarting my dedicated server and loading it up (from the commandline) with the latest autosave, works fine, except for one thing: All companies are without a password again, while there was a password before the restart/save.
Is this on purpose?
My first thought is that it's not very convenient, especially with the autoclean and stuff?
Opper
I noticed that when restarting my dedicated server and loading it up (from the commandline) with the latest autosave, works fine, except for one thing: All companies are without a password again, while there was a password before the restart/save.
Is this on purpose?
My first thought is that it's not very convenient, especially with the autoclean and stuff?
Opper
Re: Savegames in Multiplayer (Ded. srvr) don't contain passwords
Yes. Otherwise any client could just save the game and strip the passwords. Even if only the server's games contained the password, this is still a record of them that players might not want to exist.Valentijn wrote:Is this on purpose?
Re: Savegames in Multiplayer (Ded. srvr) don't contain passwords
Why not encrypt the passwords?PikkaBird wrote:Yes. Otherwise any client could just save the game and strip the passwords. Even if only the server's games contained the password, this is still a record of them that players might not want to exist.Valentijn wrote:Is this on purpose?
Re: Savegames in Multiplayer (Ded. srvr) don't contain passwords
How would you then decrypt the passwords? You'd need some key for that, and if you store that key in the savegame it's unsafe again. The config file cannot always be modified so that's no option either.Valentijn wrote:Why not encrypt the passwords?
Re: Savegames in Multiplayer (Ded. srvr) don't contain passwords
The Dedicated server instance could generate a private key to encrypt the passwords, that way only the server admin could decrypt the passwords. Still a small risk (and oppurtunity to distribute the passwords), but I wouldn't expect people to use their email or other important passwords for a openttd company.How would you then decrypt the passwords? You'd need some key for that, and if you store that key in the savegame it's unsafe again. The config file cannot always be modified so that's no option either.
We could offer the option to let the user choose.
Last edited by Valentijn on 05 Jan 2010 16:30, edited 1 time in total.
-
- Engineer
- Posts: 7
- Joined: 05 Jan 2010 00:28
Re: Savegames in Multiplayer (Ded. srvr) don't contain passwords
Simply, you don't!Yexo wrote:How would you then decrypt the passwords? You'd need some key for that, and if you store that key in the savegame it's unsafe again. The config file cannot always be modified so that's no option either.Valentijn wrote:Why not encrypt the passwords?
ANY proper password implementation won't enable you to decrypt the password in any way!
(read: you never use a two-way encyption scheme on a password, always use a one way hashing sheme.)
now, the question is: but how to verify the password?
The answer is simple: you just hash the password the user has given again and compare it to the already (hashed) previously given (server-sided) stored.
In addittion to this, to fully protect users privacy, you can create an random salt when a map is generated, and add this to the password before it is hashed.
This means it is possible to safely store the password on the server, using one-way hashing (SHA-256 or better please.) and the hash will be different between games, even for the same password.
The only (slight) weakness is when the admin (incidently) uses the same password as a player, and compares those hashes manually.
This can be solved by simply adding a unique (per-game) player id to the hash.
the final result will boil down to this:
(pseudocode)
Code: Select all
hash = sha256(password . random_map_id . player_id);
when a player joins agan, the same calculation will be done again, and the new and stored result will be compared
(pseudocode)
Code: Select all
if (hash == stored_hash) {
accept();
} else {
kick();
}
Re: Savegames in Multiplayer (Ded. srvr) don't contain passwords
The salt needs to be stored in the savegame, so the amount of security you get by that is not that big. So once you join you have the salt and the salted passwords, then it's just a simple local brute-force attack. Or, probably even more effective, a dictionary attack on the password.
The player id idea won't really help because multiple players would like to join the same passworded company and how to keep a per-game unique player id? When the client crashes, or just shuts down to drink a cup of tea or go to sleep, the client has to store the player id somehow. Then it must store the player id till infinity because he might rejoin the server with a game he once played; just storing the last is no good. Anyhow, the player id thing won't work because of the multiple clients joining the same company problem.
The player id idea won't really help because multiple players would like to join the same passworded company and how to keep a per-game unique player id? When the client crashes, or just shuts down to drink a cup of tea or go to sleep, the client has to store the player id somehow. Then it must store the player id till infinity because he might rejoin the server with a game he once played; just storing the last is no good. Anyhow, the player id thing won't work because of the multiple clients joining the same company problem.
Re: Savegames in Multiplayer (Ded. srvr) don't contain passwords
Or (depending on the hashing alogithm) use a hash database like http://md5.rednoize.com/Rubidium wrote:The salt needs to be stored in the savegame, so the amount of security you get by that is not that big. So once you join you have the salt and the salted passwords, then it's just a simple local brute-force attack. Or, probably even more effective, a dictionary attack on the password.
What about saving the password along with the Company Id? And save these passwords in a different (serverside only) file, so that clients can not harvest hashes by saving the game.Rubidium wrote: The player id idea won't really help because multiple players would like to join the same passworded company and how to keep a per-game unique player id? When the client crashes, or just shuts down to drink a cup of tea or go to sleep, the client has to store the player id somehow. Then it must store the player id till infinity because he might rejoin the server with a game he once played; just storing the last is no good. Anyhow, the player id thing won't work because of the multiple clients joining the same company problem.
Re: Savegames in Multiplayer (Ded. srvr) don't contain passwords
This has been suggested before; the problems with this method are somewhere to be found on this forum.Valentijn wrote:What about saving the password along with the Company Id? And save these passwords in a different (serverside only) file, so that clients can not harvest hashes by saving the game.
In short: quite a few servers export the save directory, thus also the password file or the password file is in another directory and the password file doesn't get removed when the savegame gets removed (although this also exists if the savegame and password file are put in the same directory).
-
- Engineer
- Posts: 7
- Joined: 05 Jan 2010 00:28
Re: Savegames in Multiplayer (Ded. srvr) don't contain passwords
the salted password can be (relatively) safely stored inside the savegame, if it has been properly salted.
The quickest method of cracking the password is bruteforcing it, which will take a certain amount of time, and will need to be repeated for each company, and each different map.
Creating a single rainbow table for all passwords with up to 5 characters (with the all the different possible salts (length: 40-bit) ) still takes 2327 years using the fastest (hardware) password cracker availble. however, storing this rainbow table, will take up around as much as the amount of particles in the our universe.
bruteforcing a single password, with up to 6 characters, for a single company, for a single game, using an household computer, can be done in just over an hour.
however, when using 8 characters, it can take up to 5 months, and when using 9 characters it will take almost 24 years.
effectively, the only weakness left will be weak passwords, which can't be solved.
Read:
Wikipedia/Password_strength#Time_needed_for_password_searches
Wikipedia/Rainbow_table#Defense_against_rainbow_tables
BTW: Note that i suggest using sha256 or better, which is currently still considered secure (besides bruteforce) on it's own, even without salting.
Code: Select all
hash = sha256(password . map_id . company_id)
Creating a single rainbow table for all passwords with up to 5 characters (with the all the different possible salts (length: 40-bit) ) still takes 2327 years using the fastest (hardware) password cracker availble. however, storing this rainbow table, will take up around as much as the amount of particles in the our universe.
bruteforcing a single password, with up to 6 characters, for a single company, for a single game, using an household computer, can be done in just over an hour.
however, when using 8 characters, it can take up to 5 months, and when using 9 characters it will take almost 24 years.
effectively, the only weakness left will be weak passwords, which can't be solved.
Read:
Wikipedia/Password_strength#Time_needed_for_password_searches
Wikipedia/Rainbow_table#Defense_against_rainbow_tables
BTW: Note that i suggest using sha256 or better, which is currently still considered secure (besides bruteforce) on it's own, even without salting.
Re: Savegames in Multiplayer (Ded. srvr) don't contain passwords
The passwords are already hashed in RAM, so it appears that some dev at some point has thought about saving them. I say this because, when I used to run my Standard Server, I would grab the passwords from RAM with a debugger before saving and restarting a server, then connect to each company in turn, puttin gthe passwords back. This became impossible after one of the new releases, when all of a sudden the passwords were all hashed.
Of course, this doesn't protect players' passwords from malicious admins. Anybody who could have attached a debugger to fish out the passwords could just as easily modify the source code to reveal them on demand (I was just determined not to modify the game). The only other explanation for deciding to hash the passwords is for the purpose of storing them safely. It just seems that it never happened.
Of course, this doesn't protect players' passwords from malicious admins. Anybody who could have attached a debugger to fish out the passwords could just as easily modify the source code to reveal them on demand (I was just determined not to modify the game). The only other explanation for deciding to hash the passwords is for the purpose of storing them safely. It just seems that it never happened.
PGP fingerprint: E66A 9D58 AA10 E967 41A6 474E E41D 10AE 082C F3ED
-
- Engineer
- Posts: 11
- Joined: 18 Jun 2017 14:55
Re: Savegames in Multiplayer (Ded. srvr) don't contain passwords
Is there way to configure that company password will be saving in save file. After restart always I must configure password for all company and for server.
Re: Savegames in Multiplayer (Ded. srvr) don't contain passwords
In the current version of the game, it is not possible.
Who is online
Users browsing this forum: No registered users and 21 guests