Board index FlightGear Development New features

MP user authentication (was Re: EDDF-Triangle)

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Re: MP user authentication (was Re: EDDF-Triangle)

Postby Johan G » Mon May 03, 2021 12:26 pm

Just a quick note about passwords: Never ever transfer or store plain text or encrypted passwords. Transfer and store hashes of passwords.

See also How NOT to Store Passwords! - Computerphile (9 min YouTube video), and the Wikipedia article Password (permalink).
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: MP user authentication (was Re: EDDF-Triangle)

Postby geed » Mon May 03, 2021 4:17 pm

Agreed, Johan.

That's why you are using something like an OTP or let's call it a token.

I guess, I should have named it token from the beginning on.

The token is handled out at the backend to the server as well as to the user/client software. The password is only used on the backend via some sort of HTML UI or Web API over an SSL encrypted HTTP stream of course. The token is created and handed over to the server on a separate secured channel.
The user will try his login using the token (the software can do the transfer of the token after the login process has been done)
The user is logged in after the user submitted token is the same the server has stored after the user login on the backend.

But benih is right with saying that the whole mp protocol should be send via an SSL encrypted channel.

Otherwise someone could if course start a man in the middle attack to gain access to access tokens.

In the end you are talking about the amount of work you want to put into this.

How likely is it that someone will in fact start a man in the middle against someone else on an mp server to gain his access tokens to take over his username to troll the server?
geed
 
Posts: 89
Joined: Fri Apr 18, 2014 1:53 pm
Location: in between
Callsign: G-EED
Version: 2017.3.1
OS: OSX, Win8.1

Re: MP user authentication (was Re: EDDF-Triangle)

Postby merspieler » Tue May 04, 2021 9:55 pm

geed wrote in Mon May 03, 2021 8:54 am:Free means, pick any callsign and if you pick someone's callsign that has been registered, you will get an error.


Actually, registering a callsign would be a hughe problem... You'd have to fight mass registration.

Even without mass registration, it can cause further frustration (and in turn provoking negative reactions).

There are users who use a realistic callsign for the route they are flying.
So for KSFO -> EDDF: LH454, YBCS -> YBBN: JST935 and KCLT -> KDCA: AA545

Now if our dear friend AAL545 has registered this callsign, noone can fly this route with a realistic AAL callsign.

The only way to mitigate that (and also kinda mass registration) would be to set a rather low expiration time of them (not longer than a day, as even the longest flights aren't that long).
So the callsign is tied to you for your flight and then it gets released, for others to use.

If you really want to limit access to MP, you shouldn't tie it to a callsign. This would still allow us to ban users while allowing flexibility when picking your callsign.
Nia (you&, she/her)

Please use gender neutral terms when referring to a group of people!

Be the change you wish to see in the world, be an ally to all!

Join the official matrix space
merspieler
 
Posts: 2241
Joined: Thu Oct 26, 2017 11:43 am
Location: Wish to be in YBCS
Pronouns: you&, she/her
Callsign: you&, she/her
IRC name: merspieler
Version: next
OS: NixOS

Re: MP user authentication (was Re: EDDF-Triangle)

Postby wkitty42 » Tue May 04, 2021 10:06 pm

my understanding is that there are two or three call signs in use IRL... the personal one for each pilot, the one for the craft, and one for the flight...

pilot call signs could be registered and protected... the call signs for the flight and craft would only be restricted to being used one at a time... all three would be used in the MP data packets... this way the pilots/ATC would be protected and the flight/craft would be protected during that flight's duration or the craft's current usage...

granted, this would mean that only one person could fly a specific craft and a specific flight during a session... since FG doesn't have any actual scheduled flights, this should be OK and as close to IRL as we could get...

just an idea from the sidelines...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: MP user authentication (was Re: EDDF-Triangle)

Postby Johan G » Wed May 05, 2021 1:54 pm

merspieler wrote in Tue May 04, 2021 9:55 pm:The only way to mitigate that (and also kinda mass registration) would be to set a rather low expiration time of them (not longer than a day, as even the longest flights aren't that long).
[...]
If you really want to limit access to MP, you shouldn't tie it to a callsign. This would still allow us to ban users while allowing flexibility when picking your callsign.

Good points. :)
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: MP user authentication (was Re: EDDF-Triangle)

Postby WoodSTokk » Mon May 17, 2021 9:54 pm

benih wrote in Mon May 03, 2021 11:45 am:When receiving a new pilot, the MP-Server:
1. query the SQL db if the callsign is claimed (additionally check against last login or something like that, so long-time-unused callsignes can be reclaimed)
2a. If no, let the pilot proceed
2b. If yes, check the supplied password against the DB, and if succeeding, proceed.


Point 2b has a vulnerability. FGclient and MPserver dont have a encrypted connection.
Transmitting password over this connection is realy bad.

A possible way will be tokens:

1 ) if the user want to connect to a MPserver, FG will show a dialog to enter the Callsign and a checkbox for 'registered user'.
2 ) if the user uncheck the box, FG will try to connect the MPserver with 'callsign=FOOO/token=null'
3 ) if the user checks the box, he/she should enter (Forum)'username' and 'password',
FG open a secure connection to the DB and request a token for this credential
4 ) if the credencials are correct, the DB generate a token and send the token back to the FGclient
if the credencials are not correct, the DB answers with a failure (or 'token=null') and the FGclient will show it inside the dialog
5 ) if FGclient receive a valid token, it connects to the MPserver with 'callsign' and 'token'
6 ) the MPserver send the 'callsign' to the DB
7 ) the DB answers with the valid 'token'
8 ) if the token is correct, the user is registered and can use this callsign

On the MPserver side:
if the server receive a connection with a 'callsign' but empty token ('token=null'), its allowed as long as no other user use this callsign
if the server receive a connection with a 'callsign' and 'token', it will check it against the DB
- if it is correct, the user can use this callsign ... if another user use this callsign allready, it will be kicked
- if it is not correct, it will drop the connection
This way, the MPserver know who is registered and who is not ... it can also display it on the map with colored callsigns or the callsign from unregistered users are in parentheses or brackets.

This way we need a encrypted connection only to the DB.
The DB need 2 new requests:
1 ) a 'create-token' for the FGclients, respond with the new token (valid if correct credencials are received, otherwise a invalid token '0000…')
2 ) a 'check-callsign' for the MPserver, respond with the token (valid if there is a valid token, otherwise a invalid token '0000…')
The token can be valid for some minutes, because we need it only to verify the user and between the 'create-token' from FGclient and 'check-callsign' from MPserver will not elapse so much time.
WoodSTokk
 
Posts: 1077
Joined: Tue Oct 17, 2017 3:30 pm
Location: Milky Way/Sol/Earth/Europe
Callsign: SX-W57
IRC name: WoodSTokk
Version: 2020.4.0
OS: Debian Bullseye

Previous

Return to New features

Who is online

Users browsing this forum: No registered users and 5 guests