We had to use a new way of how the server stores the password. This means that if you set your password with 0.4.13, by either logging in the first time (creating the account), or by changing your password from the gui, you can't log in with a <= 0.4.12 client anymore. If you only use your password without changing it, such as only doing login, you can safely use 0.4.13 without losing the capability to log in with 0.4.12 and earlier.
- 1. What are the technical details? You can read them up in the wiki.
2. Why do we need such a new way to store the password? The reason is better security of your password. During first login, the client has to send the database verifier, if its the 0.4.12 hash or the srp hash, to the server. Anybody who holds a <= 0.4.12 verifier for your password could log in to all servers where you use the same username and password, and a <= 0.4.12 verifier as well. This is at least the server owner, but could include everybody who can monitor or modify your internet. Somebody who knows the new verifier, can't do this, and only gets a way to brute force your password.
3. How can I create an account or change my password, and still be abled to log in with 0.4.12 or earlier? Do the password change/account setup with a 0.4.12 client.
4. I have such a new password value. How can I get an old one? You'll need help from a server admin. Both the /clearpassword and /setpassword make passwords compatible with 0.4.12. So you can ask them to reset your password with one of those commands, and then you should be abled to log in with 0.4.12 and change the password to your real password with the mask.
- 1. I have set up my own auth handler, and want to share logins with other services like IRC or a forum. How can I do this? SRP draws its strength from the server not getting the password in clear text, not even for a short time during login. For services like IRC, which are targeted at more experienced users, I'd suggest setting up auth tokens that are server generated, random, stored in clear, and readable by logged in users from ingame, e.g. via a chat command. This way the server never gets the actual password, only auth tokens that are guaranteed to be not shared between servers. Services for all experience levels will have to use the password, there is no better way. You'll need to find out how to do the SRP verifier generation in your specific programming environment, the wiki and SRP's wikipedia page can help. We (the devs) have intentionally not provided a lua call, to prevent abuse.
2. I have set up my own auth handler, and want to share logins between multiple servers. Is this possible? Yes, logins between multiple minetest servers can still be shared, there is only a salt added, and no value that's different on another server.
3. auth.txt has now such ugly long lines, I don't like them. Due to the assymetric cryptography done, SRP requires a bit longer verifiers than 160 bit, like for SHA-1 hashes. This can't be made shorter, e.g. by using elliptic curves. On stackexchange, Thomas Pornin gives a good explanation why elliptic curves can't be used.