Feedback required: Ingame Authentication

[TrueBrain]

Ever since I implemented the new network protocol, I imagined a centralized login system to know that this "TrueBrain" you are playing with, is really the "TrueBrain" you expect him to be. Many drafts were made, no code was written.


Lately, I have been nagged to help with a Ladder system for OpenTTD. This is not possible in the current form, as you cannot know if the user connected to your server is really who you think he is; let alone over multiple games.


In short, I pushed some dust of old plans, and wrote a new one. It basically became an RFC, and I would like some input on it:

http://devs.openttd.org/~truebrain/auth ... draft4.txt



Some things you have to know about:

- This is not meant to make it 'easier' to ban 'bad' people; they will just sign up for a new account, and be back in seconds. This system is not meant to solve that problem in any shape or form.
- Nothing in this authentication is forced, neither in needing to authenticate, nor needing to do it with OpenTTD's login system. You are free to disable it (default for now), or set your own AS.
- This is a draft; please give feedback for improvement.
- This is my last step in my evil plan to have a SSO for OpenTTD


Implementation wise, gnutls will be used, which will mean OpenTTD will gain 1 more dependance

[Xaroth]

The evil genius is at it again

[bokkie]

*eagerly awaits the chosen name*

[FLHerne]

*eagerly awaits the chosen name*

"Authenticating currently registered operators, never you mind?"

This sounds like it could be a useful feature, I'd use it if available.

[kamnet]

I'll admit that networking and backend stuff is not my forte at all, but from what I did read, the proposal seems easy to understand. I especially appreciate that a 3rd party group can have it's own separate authentication, rather than just being tied to OpenTTD's servers.

*eagerly awaits the chosen name*

As maniacally vain as it sounds, I wouldn't object to calling it "TrueBrain".

[adf88]

Really nice piece of work .

When a client connects to a server that allows (but not require) authentication ... When a client connects to a server that doesn't require authentication...

You meant "doesn't allow authentication" probably.

Client ... Should allow logging in to auth.openttd.org before joining any server. Should
remember username, never password. Every time you start OpenTTD, you have
to enter your password. Optionally, the access-token can be stored and used
to survive restarts, but this has to be reviewed more closely.

Maybe not at once but I think that some day every user action (registration, logging in) should be available through client (through OpenTTD). And "remember me" should be an option.
//EDIT
Why not to store access-token for longer period of time? Are you worrying that someone may steal it? I would not worry so much as long as it's bind to an IP.

[Transportman]

Server Side Changes
===================

New Option:
- Enum, authentication: required, allowed, none

What is the difference going to be between allowed and none?

The serverlist should clearly show the difference, both ingame as on the website.

Maybe I missed it in your draft, but are you planning to also include a way to differentiate between authenticated and non-authenticated users from the player perspective? So that people can still see I'm really Transportman if the server doesn't require authentication.

[adf88]

Unauthenticated username can be shown with a postfix e.g. " (guest)". Or different colours may be used (authenticated - coloured, unauthenticated - white/black).

[TrueBrain]

To keep you all a bit "in the loop", and because I love writing:

Implemented GNUTLS in a proof-of-concept. Connects fine to secure.openttd.org over HTTPS. Certificate validates, and everything seems to be in working order. A few issues:


GNUTLS 3.2 has a few very useful wrappers, which older versions don't have (libgnutls-28). Sadly, Debian stable has 3.0 (-26). It means we either need to supply packages for systems like that with the latest, or make compat code; basically the wrapper functions are exactly that: wrappers, and can be copy/paste from the source (it is LGPL after all). At the moment I will base my work on 3.2 (-28), as it is just a lot cleaner and nicer.


GNUTLS 3.2 DLLs for Windows are a wopping 10 MiB. Let's hope the static compile is smaller


Now for the good news:


After the proof-of-concept it became rather clear how clean the GNUTLS implementation is; I think I can lay it over our whole network framework. Basically this means that it paves the way to make Server <-> Client TLS, and other things like the Admin port, MSU communication, Content downloads, ... Not required, but nice to have. The only part it will be really useful for is the Admin port. Of course it does mean you need a certificate for your server, but okay. Basically, it is very little extra work to immediatly make TLS available for our whole network code, instead of making it only for HTTP.

While working on that, I noticed some quirks in the current network code. tcp.cpp is not a general TCP handler, but handles our own packet system. tcp_connect.cpp implements TCPConnecter, where the headers are in tcp.h, and more of that. Mostly, there is no parent for all TCP objects other than NetworkSocketHandler, which is also used for UDP. So I will have to write an extra layer above that, which handles all TCP connections, so they can all be turned into TLS connections when required/asked for (basically, a file that handles connect, recv, send, and disconnect, which are now called directly by all the TCP handlers).


Lot of talk, not enough coding. I know right.

[xtifr]

Debian stable has 3.0 (-26).

Debian stable also has openttd 1.2.1, and that's not going to change either. Debian itself openly states that stable is primarily intended for servers, and recommends using Debian testing for desktop systems. And anyone who does use stable on the desktop has to know that there are going to be library issues if you want to run more up-to-date versions of particular programs. Either you use apt-pinning or the like (which would allow you to pull in both gnutls and openttd from testing/unstable, and will ensure that any potential conflicts are resolved), or you take your chances on a hand-built version of a library, which may break things that depend on the wrong version. This is normal for anyone who chooses to stick with stable for whatever reason (and is the reason few desktop users do choose to stick with stable).

Debian developers actually usually run unstable, because you have to in order to build up-to-date packages to upload. As a result of which, unstable is actually very stable. I ran it for over a decade, and had only two or three serious problems that whole time. Which is better than the actual releases from some other distros! The name "unstable" is quite misleading. The really experimental stuff goes in experimental, not unstable. I personally recommend that desktop users run unstable instead of testing, because it gets security fixes faster.

Therefore, I really wouldn't worry too much about supporting stable. Add some detailed instructions somewhere on how to do apt-pinning to get openttd and/or gnutls from testing/unstable, without updating your whole system, and move on. Anything more than that is probably more work than it deserves for the tiny handful of people who actually use a Debian stable desktop, despite all the advice to the contrary.

[fonso]

You want to support dedicated openttd servers on stable, though. And you don't want to code against different versions of gnutls depending on it being a dedicated server or a "real" client. So I say just add that wrapper code and some build time logic to find out if you need it, put it in some extra file and in two years when the next debian version is released, remove it again.

[xtifr]

You want to support dedicated openttd servers on stable, though.

As I mentioned, providing instructions on how to do apt-pinning should solve that. If you're running an openttd server, you probably want to have it in a dedicated vm or chroot anyway, since I doubt that openttd has had the sort of hardening that, say, apache has, so conflicts really stop being an issue. Unless you just plain don't care about security at all, in which case you might as well just run unstable (and still end up being pretty darn secure).

And, of course, Debian isn't the only system out there used for servers. RHEL, for example, officially supports older systems than even Debian does. Especially for servers. RHEL4 (2005) is still supported, even though the support is limited to critical/security bug fixes at this point.

Anyway, I'm not saying that creating a wrapper or something is a bad idea. I'm just saying, there are viable alternatives that may require a lot less work. Depends on just how much spare time you have, I guess.

[Eddi]

Am i the only person here that is totally lost on what you're actually trying to say?

1. Compile for Debian
2. ?
3. Profit

[TrueBrain]

He is saying the same as I got told by developers (basically, anyway):

Build your patch for Debian unstable, make it work, don't worry too much about Debian stable, we will tackle that issue when we get there.


My patch won't be in 1.3 anyway, 1.4 is the earliest .. so ... by then stable became old, etc etc. No real issue


Tnx xtifr, good feedback

[krinn]

Well, i would prefer :

username - Generally the username used by the login. Can be email. -> unique and link to account
reservedname -> unique.
ingame username - The name of the user as shown ingame. A user cannot change -> can be anything as long as it's per connection unique (nobody else is using it), and not in reservedname list (nobody has reserved it).

It's nearly like your draft, except you allow Truebrain to connect as "Truebrain's son" or "Truebrain@work"... while still be able to rank/ban... over his "Truebrain" reserverdname


It's never bad to gave anon options, even if it looks not useful at first.

[YNM]

I'd like if we can use our existing OpenTTD Central User Management accounts for this.

[planetmaker]

I'd like if we can use our existing OpenTTD Central User Management accounts for this.

That's the intention.

[YNM]

I'd like if we can use our existing OpenTTD Central User Management accounts for this.

That's the intention.

So it means that everybody who plays OpenTTD could rush in and edit the wiki ?
Or is it our accounts that is ported over ?

Please to moderators to sort this one out the best you can.

[Edit] Removed the color; it makes no sense to make posts non-readable ... -- TrueBrain [/Edit]

[Lord Aro]

That's no different to normal... What's your point?

[WWTBAM]

I'd like if we can use our existing OpenTTD Central User Management accounts for this.

That's the intention.

So it means that everybody who plays OpenTTD could rush in and edit the wiki ?
Or is it our accounts that is ported over ?

It would surely have to be the second way around asthat is the currently secure way as I understand it.