Problems with new authorization system to join multiplayer companies

[Mark0291]

Problems so far encountered on reddit servers with new authorization system:

1. Players can not join the company of people they regularly play with, with no players active in the company at that time (this is the main problem)
2. Players can not join their own companies from a different computer
3. There is no way to un-authorize players
4. Admins using rcon to move themselves or other players to companies does not authorize them, to authorize myself (as admin) for a company I need to myself to that company, join with a different client and then authorize that client...
5. There is no way to make open companies (although admittedly that might be one good thing to come from this)

We greatly appreciate the unpaid voluntary work developers put in, however this feature will negatively impact gameplay for many, can we please have the "old" password system back?

[ChillCore]

can we please have the "old" password system back?

unless you figure out a way to obscure the password properly, while the sourcecode is available to all and thus any way of hashing too ... nope

[Mark0291]

I do not have an answer to your question, but, excuse my ignorance, why has this become a problem now after 20+ years?

[loafdude]

can we please have the "old" password system back?

unless you figure out a way to obscure the password properly, while the sourcecode is available to all and thus any way of hashing too ... nope

I also immediately noticed the significant limitations of the new invite key system.
I took a review of the secure sockets PR and a few others.

Please correct me, but I believe by disallowing passwords the intention is to prevent the server owner from having access to a hashed password table
I don't see any other exposure if using password hashes over secure sockets.

A few points to make,
- Company passwords/invites are not securing anything of real value.
- Server admins don't need company password hashes to enter/modify a company.
- You could warn users that passwords are visible server side and to be careful reusing passwords.
- CO-OP play is one of the best parts of OpenTTD and this has effectively killed it by breaking effective company management.
- OP has outlined 5 significant regressions. These should not be dismissed so apathetically.

[Heresy]

What if the password was randomly generated?
Based on hashing for example Player Name, Server Name, Company Name and for example epoch timestamp of when player joined the session, or company is being created etc.

Anyway, some solution where it would create a random immutable password based on some variables at least avoids the problem of someone storing their real actual passwords.
Someone who really wants to grief can of course reverse engineer things, but it would help alleviate the issues that Mark0291 and others have in terms of the new authorization system.

It would also need some checks to avoid people just changing it to hunter2 via the configuration file.

[uzurpator]

1. Not being able to open a company to public after finishing a game is a problem. Many servers run for hours or days, thus leaving zombie companies when the player is unable to return, or simply won't due to lack of time. One server I sometimes play resets every 24 hours. If I play, I do so in the evening for two-three hours and then leave the company dormant and I would like others to continue building it.

2. Server side, admin administered salt to passwords is a thing. The entire internet, literally, runs on that principle.

[Dogma]

After reading through the OpenTTD GitHub pull requests related to the new multiplayer authorization system, specifically PRs #12326, #12329 and #12337, and the associated discussion (#8420), I think the main issue is now clearer.

The new allow list approach itself is fine, and saving authorized clients in the savegame, as implemented in PR #12337, is a good improvement. Once a player has been authorized for a specific company in a given save, they can rejoin later without problems.

The real issue is the initial authorization workflow.

When a new company is created, or after a server reset or new save, there is currently no way to pre authorize a regular co op team. The company founder must manually invite each team member, which requires everyone to be online at the same time which isn't always practical (for example different time zones, long-running servers, or after a restart), there is no way to get that initial access. The old password system did not have this limitation, knowing the password was enough to join asynchronously.

I can see from the GitHub discussion #8420 that shareable links or tokens are planned for a later phase. Those links or tokens would ideally be automatically generated and shareable, so they can be passed around and used asynchronously, without requiring someone to be online at the same time.

This is not a cryptography or security concern, authentication is already solved. It is a workflow issue, the current system makes the first join synchronous, whereas co op play often is not.

Hopefully this helps emphasise that asynchronous authorization is not a nice to have, but essential to restoring practical co op gameplay.

[robert357]

After years of playing most changes doesn't bothered me as much, because there always was a some kind solution to change them. Not this time however. Basically almost all new features don't have any alternative solution nor different option, and new passwordless system is one of them. Current authorization system is just horrid at this stage of implementation. I don't understand why it was released in half backed state and who decided it was a good idea, because it just ruin the fun for a lot of people. It should be reversed to old system and implemented later when it's finished!

[Slice67]

As Heresy already implied, some kind of shareable token system — whether permanent, time‑limited, or one‑use — would be the best solution in my opinion. As a company founder, I would also like to be able to revoke players and manage these tokens directly. Automatically generating tokens based on the company name and founder name sounds like a great and practical approach, and it would restore the asynchronous workflow that coop play relies on.

[Caralho]

This new system is rubbish, the OP is absolutely right

[loafdude]

I can see from the GitHub discussion #8420 that shareable links or tokens are planned for a later phase. Those links or tokens would ideally be automatically generated and shareable, so they can be passed around and used asynchronously, without requiring someone to be online at the same time.

Sharing tokens, friends lists, cloud based systems all seem overly complicated, cumbersome, possible points of failure, and do not resolve all use cases.

I would propose to let clients request a token from a company using a company password.
Store the salted hash in the save and be done with it.

[Mark0291]

Agree with some of the comments of the above, but honestly the whole token thing just seems overly complicated and will never solve some of the problems inherent with it.

If devs really are worried people are dumb enough to use a password for something important as their company password, why not limit company password length to 4 or 6 characters, and allow only numerical or lowercase? Passwords to anything important these days require 8 characters minimum and a combination of numbers, symbols, so players would never be able to re-use an important password (though I highly doubt they would, anyway)

[wojtron]

From biggest cons this gave is one BIG problem.

It effectively DECREASED total amount of people being able to play on server.


All servers are now way LESS played bcos way less ppl can join bcos of lack of possiblity to invite while afk.


You took possibility to play many ppl in one company. Then make game being possible to create more than 15 companies (which I am sure is way harder than open companies)

Why you think of ppl that they are stupid ? Its ppl problem if they use important password. 99% of company passwords were 123 or sth like that. You are too worried of ppl passwords not stored in hash ? Then add info that server admin can see password (100x less work in code than recent change)>

Effectively decreased possible amount of players on servers. Want to force this ? Then enable more companies at once.

[2TallTyler]

There is now a proposed feature that allows a player to allow anyone to join their company: https://github.com/OpenTTD/OpenTTD/pull/15204

It does not include a way to authorise a player who is not currently online, but it also does not prevent such a feature from being added in the future.

[odisseus]

IMO this is an over-engineered solution to an artificially created problem. Why can't we just revert to the old password system?

[Mark0291]

There is now a proposed feature that allows a player to allow anyone to join their company: https://github.com/OpenTTD/OpenTTD/pull/15204

It does not include a way to authorise a player who is not currently online, but it also does not prevent such a feature from being added in the future.

This only "solves" one of the issues, all other, bigger, issues remain.

The group of friends I usually play with have resorted to sharing their private and public keys from the secrets.cfg, which solves many of the problems, but seems like a crazy solution to a problem that doesnt need to exist...

In case anyone is wondering:
- Go to docs/openttd and find secrets.cfg
- Share the keys saved as client_secret_key and client_public_key (edit secrets.cfg while ottd is not running)
Anyone with these same keys, or the same person playing on a different machine, will now be able to join companies created by anyone using the same keys.