Factorio Forums

The file given for --server-settings requires me to enter a plain text password to my account when listing the server for public visibility.

I would much rather prefer not to give the factorio server bin read permission to my password in clear text and would like to suggest you stick to tokens the way you use tokens elsewhere. Imagine a security flaw enabling a malicious user to get the binary to return the contents of that file in its current state =/. I can lock the binary down all I want with chroots and not running it as the root user and still, my personal account would be exposed since the password is stored in plain text.

(while not a bug per say - I was not able to give the matchmaking server my for-this-purpose-setup account on which I did not buy the game, I have to use an account which bought the game and I can see why this is a requirement, just pointing out that I tried with a non-bought game acc as well)

+1

That's really weird, the updater needs to keep the same password and it's not in plaintext there?

The player-data.json looks like this
I assume the password is never stored, but rather directly sent to the factorio servers in exchange for the service token. Ideally the server list would use the same token system.

+1

Well, fine. 0.13.2 will allow token instead of password in server-settings.

Keep in mind, however, that if an attacker gets access to your auth token, it's pretty much the same as if they got to your password. So this really only protects you against password re-use. Keep your tokens safe.

Also, the token may expire at any time, for any reason. So if you don't specify a password in server-settings, the server will have no way to re-authenticate itself and you'll have to give it a new token manually.

Oxyd wrote:Keep in mind, however, that if an attacker gets access to your auth token, it's pretty much the same as if they got to your password. So this really only protects you against password re-use. Keep your tokens safe.

Also, the token may expire at any time, for any reason. So if you don't specify a password in server-settings, the server will have no way to re-authenticate itself and you'll have to give it a new token manually.

Fair points, why not introduce an api token of sorts then? That we can monitor on our account page, like see status and expiry details, I really really do not like trusting any kind of account information to a 3rd party (well, yes I do realize there's a matter of weighing ease of use to security - and yes, I do realize I "give" my password to a 3rd party each time I log in etc... but storing it in a text file like that just feels like it could have been implemented a little "nicer" tbh)

Please understand that I'm not out to moan or complain, I just think our world needs to be more concerned about the little details when it comes to security and privacy - after all, loosing a token would not allow anyone to log in and change my password and or email now would it?

Bisa wrote:

Oxyd wrote:Keep in mind, however, that if an attacker gets access to your auth token, it's pretty much the same as if they got to your password. So this really only protects you against password re-use. Keep your tokens safe.

Also, the token may expire at any time, for any reason. So if you don't specify a password in server-settings, the server will have no way to re-authenticate itself and you'll have to give it a new token manually.

Fair points, why not introduce an api token of sorts then? That we can monitor on our account page, like see status and expiry details, I really really do not like trusting any kind of account information to a 3rd party (well, yes I do realize there's a matter of weighing ease of use to security - and yes, I do realize I "give" my password to a 3rd party each time I log in etc...

Aren't we the 2nd party here? Or am I misunderstanding who you're referring to as the 3rd party?

Bisa wrote:but storing it in a text file like that just feels like it could have been implemented a little "nicer" tbh)

I agree with you, but the question is how. Like I said, using tokens isn't really ideal either.

Oxyd wrote:Aren't we the 2nd party here? Or am I misunderstanding who you're referring to as the 3rd party?

yes, sorry, I dont know where my brain thought of adding a 3rd party - I mean you as the 2nd party =)

Oxyd wrote:I agree with you, but the question is how. Like I said, using tokens isn't really ideal either.

Well, I guess tokens would be the ideal for an api user whereas manually typing passwords is a more end user way of doing this - I depends on if you want the settings.json to behave as a user or as a non-human user like a system or in this case an authorized game client.

Look at how github does for example, I've got ways to hand out api keys associated with my account that have restricted access to what I want that specific token to be able to do (create repos? delete them? etc) - in this case I'd be happy if I could create such a token in the account page and give it a custom name so >I< know what I use it for, with enough permissions to download updates and add servers to the list without allowing whoever got hold of that token to do anything else with my account. (I guess whoever in this case is my aforementioned 3rd party who could get access to the token in a malicious way should the factorio binary - god forbid - present some kind of security hole)

Where can I find my token please?