Investigate adding support for Freedesktop.org secret service

[gvissers]

The client can currently store usernames and passwords on disk. Some measures are taken to protect these data (at least on Linux, read/write permissions are restricted to the user running the client, and the passwords are encrypted with a simple XOR cipher with the key stored in a separate file). The password length is still visible however, and in many cases the encryption can be broken without the key, especially when multiple distinct passwords are stored.

On Linux, the most widely used wallets (Gnome Keyring, KDE wallet, and KeepassXC) implement the Freedesktop.org secret service API, which defines a DBUS API to storing and retrieving secrets. Let's investigate how hard it would be to use this API as an alternative way to storing EL account information more securely (in addition to the current file based solution). Perhaps the code reorganisation needed will also make it easier to add support for other password managers on other operating systems.

[pjbroad]

The password manger was not meant to be cryptographically secure, but just to provide some privacy to avoid mishaps. For example posting your el.ini file into the forums when it contains your password. You would have to be pretty silly to post your password file and/or key file; they are quite obviously named. It was mainly to allow simpler management of multiple characters without the need to use the full separation of the the server.lst; which is complex to use for many players. The current method allows easy copying of files from place to place and its easy to backup the files, they are just text. All that, for me, brings into question the need for anything more complex and I would certainly prefer to have the current method fully available as I'd likely want to continue to use it. I'd be interested to know how easy it is to break the password file though and if we could make it better without major rework. Of more concern perhaps is the transport protocol between the client and the server.

[gvissers]

I understand that the password manager was not meant to be cryptographically secure, and for whatever it is worth, I think it does a good job of preventing accidents like the one you mention, and is convenient to use. But indeed it is not secure. I wrote a python script to do a very stupid brute force search and sorted the possible results with the following heuristics: lower case letter 10 points, upper case 8, digit 5 and all other characters 1. The success of such a stupid approach depends on the number of passwords stored, and the variety of characters used, but with the following (admittedly doctored) list of passwords

passwords = ['grum', '1234', 'GARN', 'bluap']

(encrypted with the key I have currently in one of my profiles, though the key doesn't matter) the correct passwords (well, the first four bytes of each) end up at position 1871 out of (only) 591,952 possible results, close enough to the top of the list to eyeball the results and guess at the correct line. Using

passwords = ['bluap', 'grum', 'garn', 'aisy', 'radu', 'entropy', 'roja', '1234']

the correct entries show up at position 288 out of 4,369,402, close enough to the top that you might just test all entries until you reach the right one (though I don't know after how many failed attempts the server locks the character).

Now I will admit that with my current "real"(*) password file containing only three entries the correct passwords did not show up until line (approximately) 15,000. But given enough passwords, it can be cracked. And having more diversity in your passwords only makes it worse, as that reduces the search space. And finally, if you only know a single password you can trivially decode the rest.

I'm not out to replace the current password manager. But since I'm already using a password manager (KeepassXC) anyway since every website and its dog wants me to create an account, storing my EL logins in it would not be a burden for me.

As for the traffic between the server and the client: that's another can of worms. The fact that a packet sniffer anywhere on the network can easily retrieve your user name and password is embarrassing. And the fact that the server probably still stores the passwords in plain text perhaps even more so. I fully agree that we should use TLS or something, but that would require server support, which means getting Radu on board.

(*) I don't use the password manager for the official game server, only for testing

EDIT: adjusted the heuristics slightly, adding a bonus point if a password contains a vowel. The correct (start of) decrypted passwords for the tests above are then found at positions 391 and 27(!) respectively.

[gvissers]

I was reminded of the password manager again yesterday, and did some more thinking on how the encryption on the current password file could be reversed. While my original idea did not pan out, I managed to write a simple program that manages to decrypt my password file by brute force in under a minute (as well as the other test cases I wrote about in the previous post). The file only contains three rather short passwords, more data should make it even easier to crack. Also, I'm an absolute amateur in this field.

I'm still not advocating to remove the password manager, it is useful and certainly a step up from a Post-It note on the screen. As long as people do not have access to your password file you should be fine (well... somewhat; the password is still sent in clear text to the server...). I do consider the current encryption scheme in the password manager to be well and truly broken at this point, however.

I do not want to post the code here, for obvious reasons. There are no deep cryptographic insights, though, so I'm certain any reasonably competent programmer would be able to reproduce this. @pjbroad , if you're interested, let me know and I can send the code to you.