FOSS gamedev and creative worlds

I think the current password handling (viewed from clientside) is confusing and potentionally insecure.
It's confusing because a lot of stuff happens in the background, stuff the player should be aware of but is never told.
It is insecure because it is very convenient to use the same password everywhere.

A couple of servers enforce a password, so you are technically forced to create an account on these. But it is a problem on servers which do not enforce this as well.

What the player is NOT told is the following:

• The first time the player logs in into a server with a password, an account with this name and password is automatically created
• The next time the player wants to log in this password must be provided.

This is very bad, because: If the player ever changes the password and did not remember it, the player has successfully locked out himself/herself of the server and does not even know why. The account name has been “burned”.

The player is only notified if the access has been denied because of false login data, but then it is already too late. For correct login data, the client is of course silent.

What should be done instead:
The first time the player connects to a server with a password, the server should give some sort of special response which triggers a dialog in the client.
This dialog should show name and (censored?) password (should only say: “has been set”) and explicitly ask the player: “You provided a password and this server has no account for the name ‘<name’> yet. Do you want to create an account with the name ‘<name>’ and your provided password on the server ‘<hostname>’? You will need this data the next time you want to login. [Yes] [No]”.
If the player clicks “Yes”, the server is notified and gives another response on success. If this response arrived, the client gives a confirmation dialog: “An account with the name ‘<name>’ has been successfully created on the server ‘<hostname>’. Do you want to connect now? [Yes] [No]”.
There should also a dialog if the account creation is unsuccessful or a timeout happens.



The second issue is that password handling is pretty insecure IMO. It is very easy to simply use the same password everywhere, if I recall correctly, the password field is not even cleared automatically.

So I suppose there are probably a lot of accounts on the servers lying around, all with passwords which are identical on every server.

Here is a simple way to collect many passwords without any hacking:

• Just start a server with enforced passwords
• Publicly announce this server as good as you can
• Wait for players to connect
• Run your server for some time

Bam! You now have a lot of default passwords which you can now abuse to login on other servers and do all kinds of stuff. What this means for players: Never ever use the same password on every server. It just takes a single (!) malicous server operator to pwn all accounts.

I have currently no real idea how to fix the second problem, but I want to point out that there is a problem at least.

~
Are the passwords not salted then hashed?

It's already SHA1'd in Base64.

It is hashed, but you can use that hash to connect to other servers where they have the same password. I'm not sure how the salting works.

The hashing and salting is done client side.

No password is also "kind" of a password. If you login with no password you can't change it afterwards.

You can change passwords on the pause menu.

There is no salt

Wuzzy wrote:It is insecure because it is very convenient to use the same password everywhere.

Should we disallow humans to use Minetest or what do you suggest to solve this?

Zeno wrote:There is no salt

Incorrect, the password is salted with the username.

The hashing and salting is done client side.

This is a basic secure concept, and I would be surprised if Minetest does it differently.

newuser:
1. Make a secure connection SSL or some form of encryption.
2. Send username and password via secure connection.
3. The server then salts(appends a secret key) to the password.
4. The server then hashes the password and saves it in a database.
5. The server saves the username as plain text in a database.

login:
1. Make a secure connection SSL or some form of encryption.
2. Send username and password via secure connection.
3. The server then salts(appends a secret key) to the password.
4. The server then compares the sent username and salted-hashed password to the saved ones.

So the database only stores a salted hashed copy of the password, and this hashed password is useless by its self. Every sever could possible have its own secret key for salting a password, However the above is quite secure as is. All that being said if a server admin really wanted your password they could modify and build the source-code and broadcast your username and password to world wide web every time you logged in.

Yes, I'm aware of how it is usually done on websites. The point of doing it client side is so that the server doesn't get the plain text password.

Yes, I'm aware of how it is usually done on websites. The point of doing it client side is so that the server doesn't get the plain text password.

Then yes that would be insecure, you could make a client the removes the salting&hashing and instead send saved password that you have collected from your minetest server.

And how would you get the hash from the server? It really doesn't matter. They don't store bank details.

I didn't design it. I would have salted and hashed on both sides.

And how would you get the hash from the server?

Here is a simple way to collect many passwords without any hacking:

Just start a server with enforced passwords
Publicly announce this server as good as you can
Wait for players to connect
Run your server for some time

Bam! You now have a lot of default passwords which you can now abuse to login on other servers and do all kinds of stuff. What this means for players: Never ever use the same password on every server. It just takes a single (!) malicous server operator to pwn all accounts.

It really doesn't matter. They don't store bank details.

I agree it doesn't matter.

sfan5 wrote:

Wuzzy wrote:It is insecure because it is very convenient to use the same password everywhere.

Should we disallow humans to use Minetest or what do you suggest to solve this?

lol
Of course not. As I have said, I don't know what's the alternative. I am just concerned. But I do know that keeping the password field filled unless the user clears it manually is a strong motivator to use the same password everywhere. So least clearing this field automatically might be a bit better. Still not the best option, I have no better ideas right now, this is part of the reason why I opened this thread in the first place.


Sorry, I don't understand it right now: Is my claim that a malicious server operator can use the stored passwords on his/her server to try to login on other servers, assuming some people use the same username/password combination on different servers, true? Is it also possible without even changing the source code?


But the security wasn't my only concern. I want to remember you about my first concern, that one about usability. Any comments about how easy it is for a newbie to lock himself/herself out of a server because of the silent creation of user accounts?

Sorry, I don't understand it right now: Is my claim that a malicious server operator can use the stored passwords on his/her server to try to login on other servers, assuming some people use the same username/password combination on different servers, true? Is it also possible without even changing the source code?

From my understand of this thread, I have not looked at the source code. The passwords are secure, and you would not be able just to collect them and use them to log-in without modifying source code.

But the security wasn't my only concern. I want to remember you about my first concern, that one about usability. Any comments about how easy it is for a newbie to lock himself/herself out of a server because of the silent creation of user accounts?

The best option in my opinion would be change the source code to use email log-in, and in the game console /nickname=ezraanderson (or a username field), then allow forgot my password. However that is a lot modifications.

edit: not sure if there are PHP scripts for minetest, but you could probably make a web-portal to recover/change passwords, then maybe in the minetest gui use shell to web-browers

Wuzzy wrote:Is my claim that a malicious server operator can use the stored passwords on his/her server to try to login on other servers, assuming some people use the same username/password combination on different servers, true? Is it also possible without even changing the source code?

Yes, it's correct. You need to modify the source code of the client to do this though.

sfan5 wrote:

Wuzzy wrote:Is my claim that a malicious server operator can use the stored passwords on his/her server to try to login on other servers, assuming some people use the same username/password combination on different servers, true? Is it also possible without even changing the source code?

Yes, it's correct. You need to modify the source code of the client to do this though.

They could also modify the server code to store the passwords in plaintext, or use a tool like wireshark to pull them out of the network traffic. It may be difficult to manually interpret minetest data packets though.

EDIT: Disregard this. I misunderstood.

ArguablySane wrote:

sfan5 wrote:

Wuzzy wrote:Is my claim that a malicious server operator can use the stored passwords on his/her server to try to login on other servers, assuming some people use the same username/password combination on different servers, true? Is it also possible without even changing the source code?

Yes, it's correct. You need to modify the source code of the client to do this though.

They could also modify the server code to store the passwords in plaintext, or use a tool like wireshark to pull them out of the network traffic. It may be difficult to manually interpret minetest data packets though.

The client doesn't send the password in plaintext.

The problem is that you can't create a unique salt or hash for a server, as what happens if the server address changes, for example from an IP to an actual hostname? Also, you can't base it on a random salt, as you need to be able to connect from multiple clients.

So hashing server side would only protect against people getting all the hashes of the users, and won't stop the setting up a server.

The only thing you can do is use different passwords. Or use a centralized login system (bad).

We've had a discussion about this on IRC already.
Then consensus was that we should switch to a secure protocol if we change something.
I also wrote this which describes a protocol that improves the current situation but isn't very secure either.

I'm afraid the current situation is neither secure nor comprehensible for new players nor convenient. Do you really believe players will select a unique password for each server, memorize that and enter a unique password each time they connect to a server? For a game, without any password managers? If griefing occours, it'll be blamed on siblings anyway.
I'd rather wish MT passwords would be stored locally so that I don't have to enter them each time. Of course that's insecure - but the whole communication is insecure. On a tablet, entering a complex password might be considered a "game" of its own :-/

SFan5 wrote:the password is salted with the username.

This doesn't solve the problem of players using the same password on different servers, because they probably used the same username as well. Which means that an unethical server owner could easily use the salted passwords on her server to access peoples accounts on other servers.

Why not add the server name to the salt? Now the hashed passwords on one server will not be of any use on another server. Of course, this would mean changing your server name would invalidate your password database...

Other option, of course, is to have the client salt with a random number and send the random number to the server along with the password. That would make each password hash unique no matter how many different servers the user used the same userid and password on. But either the client would have to store the random number or the server would have to send it to the client on subsequent logins. messy. Probably better to just go with the server name?

We can't rely on the server name being constant. Also, the player must be able to connect with different clients, so storing in the client is not an option.

The only way I can see to prevent this in the software is to use centralised authentication.

Kilarin wrote:Why not add the server name to the salt?

What is a "server name"? We do not have such a thing for every server.

I interpreted server name as host name - ip address or domain name.

Salting with a hostname or a servername could easily be spoofed as that data is public. Salt it with something unique and only the server admin would have access to... the UUID of the servers hard drive.

sfan5 wrote:What is a "server name"? We do not have such a thing for every server.

Ip address would be best, because you ALWAYS have the ip address before connecting.

Only way to do this without fear of losing your password database if you change ip addresses would involve an exchange between the server and the client. Server stores a random string permanently in its database, this is the server salt. Client wants to connect to the server, the server sends them the random server salt. client hashes their password using the server salt, the user id, and the password, and send the hash to the server.

Now the server has a password hash that is unique to the user, and to the server, and will do no one any good trying to log in as that user on any other server, even if the user used the same userid and password. And if the server changes locations, they will NOT corrupt their user database since the server salt does not change.

ExeterDad wrote:Salting with a hostname or a servername could easily be spoofed as that data is public. Salt it with something unique and only the server admin would have access to... the UUID of the servers hard drive.

Why would it matter if the salt is known? Salts aren't supposed to be secret, are they?

Hostnames, IP Addresses and domain names can and do change.

Correct me if i'm wrong, but aren't username and password stored per world ?
If that's the case, a simple salt could be the world's seed (should be sent to the user before identification is done). That one is a constant that does not change for a given world.

We're talking about servers here, and servers can only host one world. Also, each user should have a unique salt. It is okay for an attacker to know the salt, but I'm not sure about them specifying the seed as they could take another server's seed and you're back to square one.