Talk:Miscellaneous suggestions/Centralised authentication
Solving MitM attack
To solve the Man in the Middle attack, some additions are required:
- The Auth-server keeps the user-IP with the sessionID
- The Game-server sends the user-IP together with the R1 and sessionID and username to the Auth-server
If those two numbers don't match, I would suggest disallowing access. This avoids the MitM attack, as a server who sits in between, gives the wrong user-IP for the given sessionID. The other way around can be added too, where the user gives the server-IP to the Auth-server, and only that IP can request the session-validations.
This all of course assumes the MitM attacker doesn't spoof his IP address, which still is possible, but it requires for that person to be on the local network of either side.
Also, such addition makes the R1 value useless. The user-IP is 'random' enough (and over the Internet, almost impossible to spoof without hacking into the local network of either side), and takes over the value of the R1. That said, it would not hurt anyone to keep R1 as extra extra security measure.
Just my 2 cents -- TrueLight
Perhaps a bit over the edge, but how about connecting with GPG/PGP?
Send authentication challenge encrypted with user's public key and signed with server's private key to user, user makes use of private key to decrypt, then, the reverse is done, user signs with private key and encrypts with server public key, and the authentication is complete. I would guess that this kind of scheme would be a hard nut to crack. Additionally, this truly prevents the server owner from getting his hands on the password, as none is needed. The server simply needs to make up some random string, send this to the user, and get the same string back, just signed and encrypted from the user. And since you will need the private key and its password for this, it's rather safe, I'd say. —The preceding 188.8.131.52 (talk • contribs).comment was added by
- That would ensure login security, no doubt, but you would need a keypair per user. I assume the client software (i.e. OpenTTD) would be the software to generate these keypairs and then the public keys would have to be stored somewhere central (i.e. "The" central authentication server). This has a number of advantages - it ensures the user's password doesn't get sniffed in transit (or at the server end), it ensures the user is who he says he is etc. However, it's a lot of coding, even if you are pulling in GPG libraries (of which a quick google reveals not only none, but also statements from the GPG team that they don't WANT people using it in library form) etc. Plus, you then "have to" update it every time GPG updates (users will demand it), it's quite a big CPU hit for initial key creation (but that will be absorbed by user's clients, I assume, when they first try to sign up for an account) and I'm not sure how much CPU it would take for a multiplayer server to do all this authentication, taking account of things like people deliberately trying to DoS via authentication (not that much, I would think - with proper rate-limiting, coding, etc.). It solves all the problems for central authentication, but at the cost of a huge amount of development time to ensure it's done correctly. --184.108.40.206 12:12, 21 March 2007 (CET)
- I Guess it would not be too complicated to code. Libary-usage is discourraged, because GPG is a command line program, which means, you can easyly start it from OpenTTD and interact with it via standard streams. Of course, this means the user has to have a standalone installation of GPG or PGP. All the key creation stuff is done inside GPGP, and the user would do this before he even starts OpenTTD. There already is a server network for key distribution, or you distribute them on a floppy or USB Drive. After the keys are exchanged, this authentication can be used in a LAN without internet access. But while it is easy to code, and easy to use by evere user who already has PGPG experience, it would be a big pain for all the first time users. As you said, it would be over the edge, but still an interesting coding project. --220.127.116.11 02:07, 3 December 2007 (CET)
- By the way, your wiki tells me that i included new external links in my post, but there are none that I know of.
How to play co-op? Some sort of invite system? Currently co-op is frequently abused.
Can server admins allow unauthenticated clients? If so, do we indicate them somehow to other players?
Perhaps authenticated players could vote against unauthenticated players. Indicate them with a prefix. --> "[unauthenticated] Bill" --moewe2
Why not just mark a server as authenticated-only or unauthenticated-allowed in login window? So everybody can decide if he want to play against unauthenticated players. These should be marked in the game (in chat as well as the Company name). —The preceding 18.104.22.168 (talk • contribs).comment was added by
Should the client store the default username/password locally? If so, where?
How does this affect LAN based play, without access to an authentication server?
Will not affect, if it is possbile to operate without c.a. --moewe2
What if a server admin wishes to completely opt out of centralised authentication?
Operating without centralised authentication have to be possible at any time. Using a server with c.a. is very attractive for experienced players, but not for newbies or visitors. --moewe2
The bad side of registration.
Registration never helps in blocking offending clients if they got nothing to lose from getting banned (like getting banned from a mmorpg so you lose your character) since a client can allways make another account and there is absolutely no way to prevent him from doing that if he has a dynamic ip and in the end it will just burden legit clients and slow down a bit the bad ones, the only way to block a bad client is a active admin on the server. there is one thing that can help in filtring bad clients that is the admin behing asked to permit or deny a client connection. the only problem with this is doing it for a dedicated server... and there can also be added encryption to passwords sent to protect against sniffers. --22.214.171.124 21:40, 8 November 2007 (CET)
- Yes, it is true - I removed "* To prevent abuse by repeat offenders" part Kogut 05:01, 10 December 2011 (UTC)