1

I am writing a (third-party) client for a game, and one feature that I would like this client to have is the ability to automatically log into the game using credentials previously entered. The credentials simply consist of an alphanumeric username and password. One naïve way of implementing this is storing a file containing the username and password on the local machine. However, this is unsafe for a number of obvious reasons. One in particular is that this client supports plugins that other developers can write. This opens up the door for a malicious developer to read the contents of the file, effectively compromising the account.

I have also considered the idea of using some cipher to encrypt (and decrypt) the password, but I was not sure what was a safe way to seed the cipher. One idea that I had was creating a randomly generated file and using that to seed the cipher and then using that cipher to access the password. However, again, a malicious plugin could simply read that randomly generated file, seed their own cipher, and then decrypt the contents of the password file.

Is there a secure way to store and retrieve a user's password on the local machine? Assume that a malicious developer has full access to the source code of the application and knows exactly what algorithms and techniques are being used.

Edit: I have no access to the server that the client connects to. My application is basically a "wrapper" for the official game client that adds extra functionality.

  • you should use a server-generated token for "remember-me" authentication – Neil McGuigan Feb 25 '16 at 21:50
  • 2
    Do you have control over the game server code too, or are you just writing a client for someone else's game? – TTT Feb 25 '16 at 22:18
  • I am just writing the client. My client is basically a "wrapper" to the official game client, but it adds additional features and tools. I have no access to the server that it connects to. – Martin Tuskevicius Feb 25 '16 at 22:35
  • The more complex you make the solution, the harder it will be to integrate with any tool the user/target device chooses to manage authentication. Although, with the exception of the KDE wallet, I'm not aware of any such tool which operates across different clients on the same device. At least let the user choose whether your app should manage the credentials. – symcbean Feb 26 '16 at 1:17
  • 1
    Suppose the user doesn't have your plugin installed, but does have a malicious plugin installed. Can the malicious plugin capture the user's username and password as they enter it in? – TTT Feb 26 '16 at 22:42
1

No. Not without user input such as a passcode or passphrase used to encrypt and decrypt the credentials.

Even so, the malicious developer could sniff the credentials after decryption anyways.

| improve this answer | |
1

While this may be beneficial to the user, think of the impact of that password being compromised.

Instead of saving your user a few seconds for every login, your alternative is a breached account which can mean a loss of funds, identity, and creates more work for yourself and/or your team if/when reported.

Do yourself and your users a favor and do not save their password. It's simply not worth it.

Let's refer to our friend the CIA/AIC triangle:

  • Confidentiality: An inherent risk is present that the stored credentials will be decrypted. This is the easiest attack vector and even gives the attacker the ability to re-use (too many people re-use passwords...ugh) the credentials for other services, so your game may allow an attacker to obtain data from multiple services/sites for a single user.
  • Integrity: It is very hard to ensure that a file cannot be read or tampered with on a filesystem, so you have no guarantee that however you choose to store the credentials that they cannot just be taken and cracked later (even if the crypto is strong with you).
  • Availability: Makes the game more readily available to be used by mere seconds, so the value added is miniscule.

You impose less risk to your user and have greater control when you maintain credentials centrally. Obviously there is always inherent risk, and your servers will become a target, but your goal in security is to balance the triangle the best that you can (which may mean sacrifices).

Thought: If you're focused on usability, at least offer the ability to remember their username so that all they have to type is their password. However if you're really inclined to save that password on the system, implement a 2FA solution to protect you and your users.

| improve this answer | |
  • In case of saving the password, 2FA won't protect a user that re-uses passwords from an attacker – Mr. E Jan 21 '17 at 15:12
  • 1
    Good answer. The game is likely designed to not to allow password saving for a reason, and that reason being ensuring security is a higher priority over streamlining the user experience. I'd think carefully about proceeding because whatever scheme you devise if that is exploited you might become liable for the damages that users incur. That is a big can of works that I wouldn't open. – Thomas Carlisle Feb 20 '17 at 17:47
1

Limit the plugins

"...this client supports plugins that other developers can write. This opens up the door for a malicious developer to read the contents of the file..." is a very dangerous statement - can the third party plugins really read arbitrary files off of the user machine? This should not be the case, as that opens up the possibility of much more damaging malware than simply stealing the credentials of a game.

The plugins should be carefully sandboxed so that their access to the filesystem is strictly limited - they should be able to read resources packaged within the plugin and nothing else. If/when this is implemented, this also removes the risk that they can access stored credentials.

| improve this answer | |
1

Without control on the server it's not posible to have a reliable and secure way to do this

As you said in your question an attacker that develops a malicious plugin will have access to everything that is stored client side so you can't depend on anything client side to authenticate users

Even more, if the plugins has access to everything client side then even entering the password is dangerous. A plugin may capture the password once the user enters it and redirect to a server controlled by the attacker

I think the best to do would be sandboxing the plugins and just remember the username. Entering a password takes 5 seconds at most, it shouldn't negatively affect user experience

| improve this answer | |
1

I'm struggling a bit to understand how storing the credentials using encrpytion but with the encryption keys as accessible as the encrypted data is any safer than storing the cleartext of the credentials.

While as an end-user, you log into a site using a username and password, there is often much more happenning behind the scenes. Schemes like oauth2 are specifically designed to address scenarios like this. Also, many modern operating systems provide facilities for managing user passwords (e.g. gnome keyring, KDE wallet, seahorse) but if you're stuck on MSWindows then I think you're stuck with third party add ons.

Really, if you can't trust other people's code in the same address space as yours then you don't have a lot of options.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.