Skip to content

Network Improvements (read: no more passwords!) #8420

TrueBrain started this conversation in Features
Network Improvements (read: no more passwords!) #8420
Dec 23, 2020 · 12 comments · 40 replies

TrueBrain
Dec 23, 2020
Maintainer

With #8391, @Milek7 has shown we can with little code start our way to deprecating passwords for Multiplayer games.

Passwords in Multiplayer games always have been a bit of an issue, as people are crazy enough to use real passwords they use for other accounts too. Passwords in OpenTTD are not secure; they are send plain-text over the network, and server owners can easily read them from memory.

For a long time, people requested passwords are stored in savegames (#8303 as example); because we know people use passwords in OpenTTD they use for things like Facebook etc, we have always been against that.
Additionally, lately we have seen people getting into other people's company, most likely by brute-forcing the password. (#8339 as example).

With #8391, we are shown a way forward that completely removes the use of user-created passwords. This last week we have been talking back and forth to come to a small roadmap how we could introduce this. Before we continue to implement this, we would like to have your input on the matter.

Below are 5 phases we think can be walked in order to achieve this goal. Phase 1 is important, the other phases are both optional and can be done out-of-order. What I would like is to know if you see any problems with our ideas, or that for example with small changes we can make it more powerful to you and your use-case. Please either use the emoticons to us know what you think, or write a reply to explain your use-case and how you think we could improve the implementation

I am mostly looking at server-owners, as they might most benefit from this implementation.

Please let us know what you think! Really looking forward to feedback :)

Replies

12 comments
·
40 replies

TrueBrain
Dec 23, 2020
Maintainer Author

Phase 1 - Add crypto

  • Add crypto library to OpenTTD
  • Generate a single crypto-based unique identifier on clients
  • On joining the server, the client gives the server his crypto-based unique identifier
  • The server challenges the client to validate he is the owner of this crypto-based unique identifier
  • On creating a new company, the server adds the unique identifier to the access list of the company
  • On joining a company, before a password is asked, the server checks if you are on the access list of the company, and lets you in passwordless if you are
  • The crypto-based unique identifiers who have access to companies are stored in the savegame
    • Reloading a savegame on the same server keeps the access list intact

This will be enabled by default, but servers can opt-out via a setting.

Pros and cons

  • clients can authenticate without password
  • clients remain anonymous (it is not attached to any identity)
  • simple cross-platform implementation
  • requires no centralized infrastructure to track players
  • no need for sign-up, passwords, or anything like that
  • if a client loses his secret key, he lost access to his company (solved by Phase 5)
  • cannot join your own company on another device (solved by Phase 5)
  • friends still have to join with passwords (solved by Phase 3)
  • server access is still public or via password (solved by Phase 3)
  • you can be tracked over multiple servers (solved by Phase 2)
2 replies
@TrueBrain

TrueBrain Dec 23, 2020
Maintainer Author

Technical info

  • We use libhydrogen to add crypto to OpenTTD
  • This library generates a single public/secret key; the secret will only be known to the client
  • On joining the server:
    • the client sends his public key to the server
    • the server sends a challenge to the client
    • the client signs the challenge, and returns this to the server
    • the server validates the signed challenge
    • this ensures the server the client in fact has access to the secret key, and is therefor the owner of the public key
  • On creating a new company, the server stores the public key to the company
  • On joining a company, the server first checks if the public key is that of the company
  • Server owner needs a way to reset public key of company
  • Server owners need to be able to list public keys of clients, like via console/rcon etc

Public keys are stored in the savegame, so reloading works.

@erenes

A key would identify a player, not a company I think? In the case of coop gameplay, a company should be associated with a list of keys instead of a single key.

TrueBrain
Dec 23, 2020
Maintainer Author

Phase 2 - Multiple identities

  • Extend the client to allow creating more than one identity
    • You can use this to make sure you cannot be globally tracked over multiple servers
    • This can be as extreme as a new identity for each server
  • Each identity has a predefined username; you can still rename ingame, but this will be the name you use when joining

Pros and cons

  • you take privacy in your own control
1 reply
@TrueBrain

TrueBrain Dec 23, 2020
Maintainer Author

Technical info

  • Exactly what it says: a client can, in a dropdown or what-ever, pick the identity to use on server join.

TrueBrain
Dec 23, 2020
Maintainer Author

Phase 3 - Access lists

  • Servers get an (optional) whitelist
    • On this whitelist are the crypto-based unique identifiers of clients who have access to the server
    • A server-owner can generate an invite code
      • When joining a server in whitelist-mode, this invite code allows you access
      • After joining, your crypto-based unique identifier is added to the whitelist
  • Companies get an access list with roles
    • The first client to join a company is owner
    • The owner can add members to the company based on the crypto-based unique identifier
      • Members that are already in-game, for example as spectator, can be added immediately
      • Invite code can be generated, similar as with the server whitelist
    • The owner can promote members to owner, and owners to member
    • The owner can make his company public, allowing anyone to join
  • Password-based authorization will be completely removed at this point in time

The invite codes and access lists replaces passwords; the first can be considered a "temporary" password with the big difference that they are generated.

Pros and cons

  • removes the need for passwords
  • requires clear instructions for server and company owners how to manage their access list
2 replies
@TrueBrain

TrueBrain Dec 23, 2020
Maintainer Author

Technical info

  • This is mostly UI work; the code mostly speaks for itself
  • Invite codes should only be valid for a (short) period of time, possibly configurable
  • Invite codes could have a limit on the amount of uses
  • Such invite code can be integrated in openttd: protocol
  • Server owner needs a way to change public keys of companies
@TrueBrain

TrueBrain Dec 24, 2020
Maintainer Author

@Tintinfan noted:

In phase 3, you say 'A server-owner can gereate an invite code'. I would like to see the option for both one-time codes and codes that can be re-used like Discord server invites. It would save the effort of generating a code for each new member - allowing say 3-4 members to join with one code that can whitelist them on server setup or afterwards.

Also in phase 3 'The owner can make his company public, allowing anyone to join'. As a co-op server owner, I preferably would rather have the option to disable the "Companies get an access list with roles" or have them public by default as they are - or as a hidden .cfg option server-side. However, I can - thinking about the majority of servers - see that having access lists in this fashion locked down by default for company would be great to prevent greifing/takeovers etc.

TrueBrain
Dec 23, 2020
Maintainer Author

Phase 4 - Friends list

  • You can add people you play with to your personal friends-list
    • This is based on the crypto-based unique identifier
    • The last known in-game name is remembered for each friend
  • A server can be queried for the public keys that are active on the server
  • The in-game server-list will show servers where your friends are playing

Otherwise, you can only see if a player is active on the server you saw him on.

Pros and cons

  • you can see who is playing where
  • you cannot prevent someone adding you to his friendlist, so people can stalk you
4 replies
@TrueBrain

TrueBrain Dec 23, 2020
Maintainer Author

Technical info

  • Friendlist stores public keys in openttd.cfg on the client (base64 encoded)
  • Server can be queried via UDP for the current active public keys
    • This most likely in a similar way as the NewGRFs can be queried
  • Clients, after receiving the server-list from the master-server, query every server one by one
    • For each server it will now do two queries:
      • The server information
      • The active public keys
    • The client can now indicate on which server friends are playing (possibly by a filter)
  • Possibly we can also make the master-server query who is online where, so a client can have the option to only fetch servers friends are on. This would heavily reduce the amount of servers being sent to the client.
@frosch123

frosch123 Dec 24, 2020
Maintainer

The stalking bit can be solved by having 3 keys:

  • public key for the server
  • private key for the person (can be validated with public key)
  • friend key for friends (can be validated with public key, but cannot be used as private key)
    • implementation: the public key has two parts, one to validate the private key, one to validate the friend key.
    • con: you cannot revoke friendship, once someone has your friend key, they remain friends, unless you reset all friends by resetting the friend-public key. (probably can be solved in phase 5)

I am not sure how an interface for "add friend" would look like.

  • You would have to meet someone on a server to get in contact. (this is the weird part)
  • Then some e2e encrypted friend-key-exchange between the clients, routed over the server.
  • Or you exchange keys outside of OpenTTD.
@TrueBrain

TrueBrain Dec 24, 2020
Maintainer Author

Yesterday I found out that people can add you on Steam too, without you being able to do anything against it. You do get a notification, so there is that. But, it is the notification that the person added you to his friendlist. Not asking :D So although it is still true people can stalk you, I have been wondering if it is a problem that needs a solution :P

@Olionkey

So the way that steam works. It is not that they add you on their friends list its more like they send you a request to be friends. you can either deny or accept it. Though there is a follow mechanic where you can follow people and see when they post and stuff, with out being friends.

TrueBrain
Dec 23, 2020
Maintainer Author

Phase 5 - Store identity in the cloud (Optional)

  • Your crypto-based unique identifier can be stored encrypted in the cloud (can, as in, opt-in)
    • You need to remember your username and password
    • The crypto-based unique identifier is encrypted before it leaves the client
    • The password never leaves the client; it is only used locally to encrypt/decrypt
  • On other devices you can retrieve, based on the username and password, the crypto-based unique identifier

Pros and cons

  • allows the same user to play cross devices
  • on local data-loss, access to the company can be recovered
  • if user forgets his password, all information is lost
7 replies
@TrueBrain

TrueBrain Dec 23, 2020
Maintainer Author

I was thinking the same, so I am considering optionally allowing a email, for recovery. This needs some more refinement, honestly.

@Milek7

Currently, a forgotten company password could be reset by a server admin via some support channel (discord or whatever).

This could still happen, as server admin will be able to add another pubkey to company using server commands.

@frosch123

If you store an email, you do not need a password anymore.

  • Add a button "send invite code to email".
  • Enter the invite code into OpenTTD.
  • OpenTTD creates a new public/private key pair, and registers it with the cloud account.
@Vrakfall

I must say, seeing the title scared me a little but then I saw the fact it would be encrypted, which is ok but I'm still a scaredy cat when it comes to the private clouds. If we really go the full cloud path, it would be nice to include solutions like Nextcloud et. al. as, on top of that, that one can be extended with an addon app just for openttd.

Another possibility is to streamline this with password managers like KeePass (e.g. KeePassXC, but there are other variants using the same format) which should be fairly extendable. This one requires the user to be responsible of managing AND doing backups of their password database but some other, more privately owned, solutions offer it for the user, thus removing the need for openttd devs to ensure the account can't be lost.
(But then, there could always be an option for an admin to reset a company ownership to a new public key if they're quite sure the user requesting help is legitimately the actual company owner who somehow lost his password.)

Also, password managers remove the need to actually create a password as the private key can just be stored in an encrypted fashion within the password database (using either a master password the user uses more often which was probably already created before, a key file or both).

@Vrakfall

Oh and I forgot that this could also be made available through a server owned by openttd devs like bananas or something like, that way it can include password recovery through email address.

rcon passwords are currently sent completely in the clear, not even lightly MD5 hashed like company passwords, this is probably more important than company passwords, as the whole server being compromised is much more significant than a company being compromised.
Using public keys for rcon access instead of passwords in a similar manner as described above for company passwords would seem like a sensible security improvement.

Server passwords are also sent completely in the clear, but these tend to be fairly public anyway.

Purely for informational purposes, I've already made some changes to password handling in my branch:

  • rcon, server and another access mechanism (settings access) passwords currently use a challenge/response system where the salt to use is unique to each client connection and is sent to the client in the welcome packet. This is still MD5, so a bit flimsy, but prevents trivially hoovering up and replaying the passwords.
9 replies
@Olionkey

Wouldn't it be possible to create it from the computer hardware? and System setup?

@Milek7

That would be very weird and potentially insecure.

@Olionkey

That's true, but would probably be better then storying it the config file. Unless you created a file just for the key that was also encrypted?
But one that solution that could fix all of this would just do accounts for the game. Which would then also sync up with the purposed cloud saves that was mentioned in the live stream.
Then you wouldn't really need a public key you could go off of the account name.
But with that, it comes up with a whole another pile of problems I feel.

@glx22

I think private key can be stored in a binary file, with some encryption (or at least obfuscation), as binary formats are usually harder to read.

@TrueBrain

TrueBrain Dec 24, 2020
Maintainer Author

Few things to note here, hopefully preventing we will invent a gold-plated bike-shed :D

Storing public-keys, for access-lists, server-whitelisting or RCON, does not need any form of protection. They are public information, and can be shared freely with anyone.

Doing this in openttd.cfg is debatable a good or bad idea. Currently we also store ban-lists in here, with IPs. They are comparable with public-keys in terms of information they release .. so either we should also move the ban-list out, or we can safely store the rcon public-keys in there too :) It is one or the other, not both ;) Worst case if we store it in openttd.cfg and someone puts it on pastebin, that someone else can give a random client access to his RCON .. I mean, I do not think this really is a problem :D (but I can be wrong; please let me know if I am!)

Secrets of course is another story; but remember: servers are not storing secrets, only clients are. In the current PR this is correctly done in a separate file. It does not need obfuscation or encryption or any of that kind, as it is important to remember these secrets are not used for encryption or anything. They are used to proof someones identity. So from a risk model, we have to ask: what is the worst that can happen if a criminal gets his hands on your secret .. well .. he can play online as you, joining your company .. I doubt there will ever be any malware doing that. Or, in case of RCON, they can login to a server and manipulate the server .. again .. I doubt any malware would ever target that ;) So adding any other additional layer of protection is generally just counter-productive, increases complexity with no added value.

You see similar solutions with for example SSH, where private keys are just stored on disk. Sure, you can add a passphrase to them, but that covers a completely different risk-model than we have to consider here :)

If we would use secrets for encryption, it would be a bit different. But if we would do that, and given we can just use a DH encryption, we can generate secrets on-the-fly and encrypt any channel with that; no need at all to store this information on disk (like with TLS).

In short: let's not go overboard here; keep it simple ;)

Regarding centralised accounts: we kinda want to avoid that. It is not only a lot of infra to setup and maintain, there is also a lot of support that has to be done for it, and we have to ensure information is stored securely, which is also not an easy job. If we can avoid it, I prefer that :) But in the end we have to be real about the complexity we add one way or the other. So far, this decentralized plan we show here, seems to cover all our bases, and as such would be preferred over a centralized solution. But, we can be convinced otherwise, ofc :)

If removing passwords solves the problem that when ever the server restarts and all companies loose the passwords. Then I am all for it.

2 replies
@JGRennison

Incidentally you can largely work around this now in my branch by using the 'company_pw_hashes' and 'company_pw_hash' commands on the server, before and after restarting respectively.

@Olionkey

But that takes effort. /s

It would gonna be like OpenRCT2's current state when this comes true and furthermore authorizations for joining server/companies might be automated via server's community website.
I'm so dying to wait this! Cheers up 👍

0 replies

Hello,

Thanks for doing the stream yesterday - and showing off GitHub. I hope I can get involved with the feedback you asked for where I can in the future. :)

As I've run a server for over 5 years now, I feel this is a great place to start. We mainly place in a co-operative style, with a password to join the server but no password on companies.

Overall I love this idea. But there are a few areas I wanted to give feedback on - as you asked for!

In phase 3, you say 'A server-owner can gereate an invite code'. I would like to see the option for both one-time codes and codes that can be re-used like Discord server invites. It would save the effort of generating a code for each new member - allowing say 3-4 members to join with one code that can whitelist them on server setup or afterwards.

Also in phase 3 'The owner can make his company public, allowing anyone to join'. As a co-op server owner, I preferably would rather have the option to disable the "Companies get an access list with roles" or have them public by default as they are - or as a hidden .cfg option server-side. However, I can - thinking about the majority of servers - see that having access lists in this fashion locked down by default for company would be great to prevent greifing/takeovers etc.

Moving on from that, phase 3 sounds very much like a UI task to give server admins a control panel of sorts. I'd like to ask that the ability to promote a user to a server admin is added as part of this. I host using the dedicated server command line option and I think many others do as well. If there is a new UI with all these fancy features - I'm not sure just using "rcon " will be enough!

Lastly, I've moved server host/computer about 3-4 times in the past few years. At the moment, I just copy over the .cfg - with passwords stored inside and host away. With the new accesslists - can a server host PC change be done just as easy?

Sorry for all the spam feedback but I hope this helps the greater good! Love the idea now and looking forward to where it will go. 👍

1 reply
@TrueBrain

TrueBrain Dec 24, 2020
Maintainer Author

Thank you so much for the feedback, really appreciated :) I am going to copy/paste your comments in the described phases, so who-ever implements it can keep those use-cases in mind! In general, I think in our heads we planned most of them already :D

Lastly, I've moved server host/computer about 3-4 times in the past few years. At the moment, I just copy over the .cfg - with passwords stored inside and host away. With the new accesslists - can a server host PC change be done just as easy?

OpenTTD always aims to be mobile, as in: that you can just copy your OpenTTD folder, and start it somewhere else. I do not see a reason this would change. But we will keep it in mind when creating the PRs and reviewing them :D

Tnx again! If you have anything else, let us know!

Maybe I don't understand something, but this idea doesn't seem quite cool and I don't think it will solve any of the problems relevant to me - it will rather dig some holes even more. I am writing from the player's point of view.
On the one hand, the title says: "No more passwords!" Hurrah! Although... the passwords don't bother me at all. But you keep writing about the necessity to remember the password and the procedure of its recovery ... No, it's an exaggeration for me. After all, this is just a game where I can now easily change my password or come up with a new one in 3 seconds, without any >discouraging< procedures. I don't care if someone breaks into my company. I have played almost exclusively online for the last 5 years. Although I had banal passwords like "4RFV", no one ever entered my company uninvited (except for one guy who impersonated an admin). Using more difficult passwords, let alone important passwords, I find ironically funny in this game. I don't understand why play with such security and whole password recovery procedures. Maybe for servers with a password it would be useful? I don't know.

However, I do have some concerns.
(Warning: I can write some tosh - don't get irritated / don't laugh too loud)
1. What will it be look to invite someone to your company?
Currently, it is enough to give someone the password via private message. Will it be, for example, the ability to invite someone through the players list window? I hope it will not be the option to request to join - malicious or stupid players could spam the requests. Unless there would be a certain interval between possible requests - increasing with subsequent refusals.
1b. Will the player be able to remove another player from his own company?
If a player were to invite others by invitation in the client list window, the wrong person could also be invited. It would be good if the player who founded the company had the opportunity to remove unwanted people from it.
1c. What will it be like to hand over the company to another player?
Will a player once invited always have access to the company? The game should remember who has superior rights in the company. The change of the owner could be done in the company window by changing the name of the owner or adding a partner.
2. How the company "with" or "without" a password will be deleted?
This is a big question mark. Some servers must use the automatic removal of companies. How will it work when there are no passwords? Currently, the removal mechanism is not working perfectly and some changes would be useful here. The problem is that removing companies is not always necessary. For example, if one person stays overnight on a popular during the day server, the others players companies will be removed from the game because they haven't logged in... in the middle of the night (the need to log in every less than 5 hours). As a result, in the morning one of the seven or more companies remained on the server. Once I talked with Milek7 on this subject. He even created a small patch to remove companies based on the number of vehicles in the game (game drag) and the number of free slots for new companies. There have been some plans to make a full version of it with precision conditioning.
3. Will the password make it difficult to remove trolls from the game?
I would prefer a password to be assigned to a copy of the game, so that admins can block unwanted people more effectively.
The solution could also be the optional requirement by server for something like an official password, i.e. a kind of player registration - the player would be able to register one or even several official profiles with unique nicknames (white label as opposed to gray label for an unregistered player).
4. What about situations when one person plays on the server under several nicknames at the same time?
It would be good if the server could prohibit the same player from entering the game under several nicknames at the same time. I am also thinking of spamming invitations (see point 1).
5. Will client with administrator status be or can be credibly marked?
Currently, anyone can easily impersonate the admin (unless he writes an appropriate script). It is not easy to recognize it in all situations. Requesting an authentication doesn't always seem appropriate. Sometimes it can create distrust between players.

4 replies
@TrueBrain

TrueBrain Jan 11, 2021
Maintainer Author

Maybe I don't understand something, but this idea doesn't seem quite cool and I don't think it will solve any of the problems relevant to me - it will rather dig some holes even more. I am writing from the player's point of view.
On the one hand, the title says: "No more passwords!" Hurrah! Although... the passwords don't bother me at all. But you keep writing about the necessity to remember the password and the procedure of its recovery ... No, it's an exaggeration for me. After all, this is just a game where I can now easily change my password or come up with a new one in 3 seconds, without any >discouraging< procedures. I don't care if someone breaks into my company. I have played almost exclusively online for the last 5 years. Although I had banal passwords like "4RFV", no one ever entered my company uninvited (except for one guy who impersonated an admin). Using more difficult passwords, let alone important passwords, I find ironically funny in this game. I don't understand why play with such security and whole password recovery procedures. Maybe for servers with a password it would be useful? I don't know.

Just as a kind reminder, please tune down the way you word things if you don't mind ;) I am sure it is not meant this way, but words on the Internet miss subtext; I would almost formulate this as a rant, and I do not see how it is constructive to do so :) It kinda invalidates your (otherwise legit) questions following, just because you set a tone here. It really is not needed, and please remember on the other side of the line are humans doing this in their free time. Be nice to them .. feed them bananas, not rocks :) We read your reply no matter what, no worries :) Tnx!

@TrueBrain

TrueBrain Jan 11, 2021
Maintainer Author

1. What will it be look to invite someone to your company?
Currently, it is enough to give someone the password via private message. Will it be, for example, the ability to invite someone through the players list window? I hope it will not be the option to request to join - malicious or stupid players could spam the requests. Unless there would be a certain interval between possible requests - increasing with subsequent refusals.

As mentioned in the draft, invites will generate a code you can give to your friends. So it is nearly identical to passwords, just .. we generate the password, not you :) That avoids people using passwords they shouldn't be using :P

1b. Will the player be able to remove another player from his own company?
If a player were to invite others by invitation in the client list window, the wrong person could also be invited. It would be good if the player who founded the company had the opportunity to remove unwanted people from it.

As mentioned in the draft, there will be different roles, one of which is "owner" of a company. He can invite (and most likely kick) people from the company. Not someone who just got invited. Of course if the "owner" gives him "owner" roles, he can.. but if you shoot yourself in the foot, it hurt.

1c. What will it be like to hand over the company to another player?
Will a player once invited always have access to the company? The game should remember who has superior rights in the company. The change of the owner could be done in the company window by changing the name of the owner or adding a partner.

See earlier.

2. How the company "with" or "without" a password will be deleted?
This is a big question mark. Some servers must use the automatic removal of companies. How will it work when there are no passwords? Currently, the removal mechanism is not working perfectly and some changes would be useful here. The problem is that removing companies is not always necessary. For example, if one person stays overnight on a popular during the day server, the others players companies will be removed from the game because they haven't logged in... in the middle of the night (the need to log in every less than 5 hours). As a result, in the morning one of the seven or more companies remained on the server. Once I talked with Milek7 on this subject. He even created a small patch to remove companies based on the number of vehicles in the game (game drag) and the number of free slots for new companies. There have been some plans to make a full version of it with precision conditioning.

All companies, by default, will be "password protected". So this changes for the better. Either way, this whole system you mention needs a revamp, but that is really something for another time :D

3. Will the password make it difficult to remove trolls from the game?
I would prefer a password to be assigned to a copy of the game, so that admins can block unwanted people more effectively.
The solution could also be the optional requirement by server for something like an official password, i.e. a kind of player registration - the player would be able to register one or even several official profiles with unique nicknames (white label as opposed to gray label for an unregistered player).

We do not want a centralized account system, and as such this solution doesn't provide any real mitigation for this. They can just change their key and join back in. There is not really a lot we can do about this with this draft, but further extension can approve on it. I hear you, I know what you mean, but for now it is out of scope :) That is to say, this doesn't make it easier nor harder for trolls to be removed, but neither for them to enter; not really anyway.

4. What about situations when one person plays on the server under several nicknames at the same time?
It would be good if the server could prohibit the same player from entering the game under several nicknames at the same time. I am also thinking of spamming invitations (see point 1).

Similar to 3, I fully get what you mean, but there won't be a central solution for this. There will, however, be a possibility for server-owners to solve this. This will be an extension after this is done, so not in scope currently, but really something we should take care of, and will take care of over time :) Stay tuned, I would say ;)

5. Will client with administrator status be or can be credibly marked?
Currently, anyone can easily impersonate the admin (unless he writes an appropriate script). It is not easy to recognize it in all situations. Requesting an authentication doesn't always seem appropriate. Sometimes it can create distrust between players.

This draft fully allows to grant clients administrator rights, which can clearly been show. The fundamentals as chosen by @Milek7 are as such that it is (crypto-wise) possible to proof a client is really who he says he is (give or take someone stealing his secrets from his computer, of course), so we can make huge improvements on this. This is somewhat in scope, but currently not really :)

Thank you for these questions; I like to read the issues people deal with in a day-to-day, so this really helps to understand that this is in fact a good solution and we should move forward with this, as this resolves a ton of these issues, and others can be resolved in the future.

Regarding "recovery", that part is about "cloud" storage, and has nothing to do really with a single server. That is more about someone reinstalling their client and want to recover their secrets. That needs a method of "recovery". Not a single server access :) That would be silly :P So your normal workflow is not changing in those respects, the main thing that changes that if you login, you don't have to enter any password, while we can still assign you roles from your last visit, to put it in very basic terms :)

If you have any more questions (or if I failed to answer one properly), please do let us know! Tnx!

@LC-Zorg

Just as a kind reminder, please tune down the way you word things if you don't mind ;) ...

I don't see the possibility to write back the prv, so I'll just write briefly.

I don't know if I am writing too bluntly. I try to write as constructively as possible and I certainly do not want to offend anyone. Perhaps what I write sounds different in English and in my native language. It's a bit of a problem, because my English is just poor and maybe in some places I'm not exactly writing what I want to write. I also admit that it's hard for me to write sometimes completely without emotions. Especially when I have reasonable concerns that some changes may be introduce to the game, from my point of view, not entirely good, and maybe sometimes bad. Anyway I am writing here to be able to add something from myself. :)

1. What will it be look to invite someone to your company?

(...) invites will generate a code you can give to your friends. (...)

You write about friends. What about regular players who are not my friends and would like to join the company? Another thing is that I don't always have to want my friend to be able to enter my business (competition-based games, want to play alone) - joining a company should require consent and should not be general, default consent. I just don't play with a close circle of friends. My concern is the way other players will be invited to the company. Maybe I don't understand this method, but I don't want to mess with emailing passwords (crap? :) to anyone who wants to join my business. The same applies to the opposite situation if I wanted to join someone. I am not just writing about myself - such cooperation and inviting new, unknown players on many servers to companies is very popular.

Stories of the use of such passwords sound truly surreal. By the way, changing the system in one rather not very popular game won't fix the world. These players will continue to use these passwords in all other places. Did you watch the movie Madagascar and the scene with music Louis Armstrong "What a Wonderful World"? https://www.youtube.com/watch?v=4zxQ9_axkGo That duck, these are these players. ;) Contrary to appearances, the current state, i.e. the information that the entered password can be read by someone, meets the educational form and may cause more positive effects than replacing this method with an automatic one.

2. How the company "with" or "without" a password will be deleted?

All companies, by default, will be "password protected". So this changes for the better. Either way, this whole system you mention needs a revamp, but that is really something for another time :D

No, it is not good. Companies without a password are removed much faster. It is necessary with the current mechanism due to the 5 minute players who buy, for example, one bus, let it go and leave the game. A few such players will appear and no one else can start their own company.
I believe that some changes to the deletion of companies will be needed. Perhaps it would be worth considering introducing conditional removal of companies. Below is a link to a short description (in Polish) and to the code created by Milek7.
-Link to the assumptions of the simplified version of conditioning (post # 10): https://openttd-polska.pl/Thread-w%C5%82amywacze?pid=20170#pid20170
-Code link (post # 14): https://openttd-polska.pl/Thread-w%C5%82amywacze?pid=20182#pid20182

3. Will the password make it difficult to remove trolls from the game?

We do not want a centralized account system, and as such this solution doesn't provide any real mitigation for this. They can just change their key and join back in. (...)

Yes, that's true, but the verification could also be based on the add-ons (ID + download date) - it's hard to change. The idea is that the servers could restrict access by unwanted people (only players who have the game and add-ons for a certain period of time could enter). I suppose it might be difficult and the demand is not that great.
Perhaps the solution would then be to automatically kick a player from the server in certain situations? Eg Someone will cause some railroad accidents = warn > kick > ban

4. What about situations when one person plays on the server under several nicknames at the same time?
5. Will client with administrator status be or can be credibly marked?

Here, just like with point 3, I mentioned it to possibly draw attention to the problem, so that the introduction of a new system would not hinder the solution of other problems, and if possible, that it should be designed to solve them.

@TrueBrain

TrueBrain Jan 12, 2021
Maintainer Author

I don't know if I am writing too bluntly. I try to write as constructively as possible and I certainly do not want to offend anyone. Perhaps what I write sounds different in English and in my native language. It's a bit of a problem, because my English is just poor and maybe in some places I'm not exactly writing what I want to write. I also admit that it's hard for me to write sometimes completely without emotions. Especially when I have reasonable concerns that some changes may be introduce to the game, from my point of view, not entirely good, and maybe sometimes bad. Anyway I am writing here to be able to add something from myself. :)

Just wanted to bring your attention to it, all is good :)

You write about friends. What about regular players who are not my friends and would like to join the company?

Good question; we will have to work this out a bit. Not all possible problems are solved in this draft, some will be solved on PR level. We will take your words into consideration while building!

Another thing is that I don't always have to want my friend to be able to enter my business (competition-based games, want to play alone) - joining a company should require consent and should not be general, default consent. I just don't play with a close circle of friends. My concern is the way other players will be invited to the company. Maybe I don't understand this method, but I don't want to mess with emailing passwords (crap? :) to anyone who wants to join my business. The same applies to the opposite situation if I wanted to join someone. I am not just writing about myself - such cooperation and inviting new, unknown players on many servers to companies is very popular.

I read what you write, but this will be okay. You have to trust us a bit that we do the right thing here, but the workflow you currently have won't increase in complexity, basically. And we have been very clear in wording that a company is not public by default, so no, they cannot just join because they are your friend :) But when this hit PR state, you have ample of time to test it out and react on it too. I do like the input, and we will take it with us :)

Stories of the use of such passwords sound truly surreal. By the way, changing the system in one rather not very popular game won't fix the world. These players will continue to use these passwords in all other places. Did you watch the movie Madagascar and the scene with music Louis Armstrong "What a Wonderful World"? https://www.youtube.com/watch?v=4zxQ9_axkGo That duck, these are these players. ;) Contrary to appearances, the current state, i.e. the information that the entered password can be read by someone, meets the educational form and may cause more positive effects than replacing this method with an automatic one.

"not very popular", oof, you make a wrong judgement there I am afraid :) It is also a bit of a weird argument to make: other games will continue to use passwords, so we should too? :D OpenTTD has always been a bit on the front when it comes to things like security, innovation, etc. For example, OpenTTD had full IPv6 support in 2007, when people were telling us: THIS IS UNNEEDED, and blabla. We had 5+% players playing IPv6 only since that time. So don't hold back innovation because others refuse to do so :D We are not trying to fix the world; we are just making OpenTTD an easier and better place. As with this, many more things become possible .. like an invite link you can put on your website to join your server, for server owners. Ala Discord. Just to name one of the possibilities this will give :)

No, it is not good. Companies without a password are removed much faster. It is necessary with the current mechanism due to the 5 minute players who buy, for example, one bus, let it go and leave the game. A few such players will appear and no one else can start their own company.
I believe that some changes to the deletion of companies will be needed. Perhaps it would be worth considering introducing conditional removal of companies. Below is a link to a short description (in Polish) and to the code created by Milek7.
-Link to the assumptions of the simplified version of conditioning (post # 10): https://openttd-polska.pl/Thread-w%C5%82amywacze?pid=20170#pid20170
-Code link (post # 14): https://openttd-polska.pl/Thread-w%C5%82amywacze?pid=20182#pid20182

I don't disagree with you there. This won't be part of this draft for sure, but it does need addressing. As @Milek7 is doing most of this implementation and wrote that patch, I believe this will work out just fine :)

Yes, that's true, but the verification could also be based on the add-ons (ID + download date) - it's hard to change.

No it is not :) And if it was, a custom client would be made instantly to bypass that. Being Open Source doesn't allow for many of the traditional ways of protecting like this, sadly. Always a bit of a thing to consider.

The idea is that the servers could restrict access by unwanted people (only players who have the game and add-ons for a certain period of time could enter). I suppose it might be difficult and the demand is not that great.
Perhaps the solution would then be to automatically kick a player from the server in certain situations? Eg Someone will cause some railroad accidents = warn > kick > ban

For sure we could work on a better system to keep bad people out. It is not in scope of this draft, to be perfectly clear, but it is something someone could pick up to figure out, yes :)

Here, just like with point 3, I mentioned it to possibly draw attention to the problem, so that the introduction of a new system would not hinder the solution of other problems, and if possible, that it should be designed to solve them.

And I read it as such, and we will take it with us :) Again, tnx for the feedback, it really is appreciated :) You notice I mostly scope to set expectations, and making sure the current design doesn't hinder future extensions. So we are all good here, I think :D Again, if you have more of these points, do let us know so we can check if everything fits together :D Tnx again!

Maybe it will be better to use something like OpenTTD account? With registration by email and password. Like in other games. And if server admin bans player by IP and OpenTTD account, this player will not be able to easy reconnect by using VPN/Proxy. In that case player needs to create new account and join it in game.

1 reply
@BrinzaBezrukoff

Ok, I saw answers about u dont want centralized accounts system.

And here we are, a year later and still discussing.
The truth is that the good old password system works. The only problem is that every reboot of the server will clear them.

  • I'm a public server owner, I don't have contact with my guests so the "share a server key manually" thing doesn't work for me.
  • The paranoia of passwords being hacked is here from the beginning. With the eternal "we don't want hacking" dilemma, addressing this is being delayed forever; truth is the companies are being left without password after a reboot which leaves them at the will of everyone. This happened to me recently, someone joined and cleaned ALL companies from a 700+ years game leaving a "heh heh heh" comment behind. I've seen the forums, and the "high ones" (devs, admins) always say that "that'a a feature" and sent people to code themselves; yeah.. rude. so please don't ask me to "tune down".
  • "people use their real passwords for the game" this may be true (I don't know) BUT to access someone private services you need more than that. Facebook being the example almost all the time will require knowing the victim's email. Even knowing this, facebook and almost ALL services out there have security measures to stop logins from different ip addresses/locations. This issue is no longer valid as it was before.
  • "people could hack a savegame to extract the password" in real world, 1 out of 100 people are going to try that, mostly because they don't know how to do it and some because it doesn't really make any sense to waste time doing this. However, this being repeated over and over again will be more than an incentive to make it happen. What is needed is to save the passwords encrypted; not techie here, so I must leave that to the ones that know how to do it.
  • "we don't want anyone to hack passwords and do evil things in the game" - This IS HAPPENING right now anyway. I understand that there are kids out there that have nothing to do but make other people's lives impossible. What we need is an effective way of banning people, be it by IP, username, mac address or something. Maybe now that OpenTTD is on the Steam platform, banning could be done using Steam services (username maybe? I don't know). But we also need encrypted passwords in savegames OR encrypted and saved in a separate file that only the server admin has access (or not, but it has to be in the server so troll players don't get access to it).

The game cannot be perfect guys, accept it. All games out there are hackable, starting with AAA titles.

Sorry if my message seems "toned up" but this comes back from 2007. It can be read in the forums of OTTD.

regards.

On a side note:
We have a paradox here that seems to be happening on all free software.
The devs make a software for free and share it, but it has usability flaws. Some make it really difficult to use, some are core breaking, some are minor.
People consume it, and realize the problems thus demand that the devs fix the core issues, others just complain for minor things.
The devs get offended and the paradox starts:

Devs: "I've given you this for free, you have no right to demand anything"
Consumer: "I've lost my time with your free software, why do you release something that is broken like this, make me waste my time and then refuse to fix it?"

Remember: Time is the only thing that's really yours in life. In fact, that's life. You exchange it for money at your job, you spend it even if you don't do anything meaningful with it. Time is the most precious-expensive thing, because it goes on and on, do what you do, it will flow and never come back. That makes it expensive.

Both have their reasons, both are right in a way.

7 replies
@andythenorth

This comment was marked as off-topic.

@elcosomalo1

This comment was marked as off-topic.

@andythenorth

This comment was marked as off-topic.

@LordAro

Elsewhere, please.

@andythenorth

Any further paradox discussion here - thanks in advance andythenorth/test#2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
Features
Labels
None yet