1

I'm making an application that logs multiple accounts into a game server. I'm able to do this by passing in the username and password as argument parameters to the game executable.

Unfortunately, I need to do this via plaintext. How would you recommend I store user credentials so that they are at least somewhat "protected"?

Originally I was planning on storing it as a hash and salted password in a SQLite db stored locally on my machine that I would access until I realized I needed the plaintext password to login. So I had irreverisbly encrypted my login and could not retrieve it.

4
  • 3
    It is not clear from your question where do this password needs to be stored and from what attacks it needs to be protected from. Is it a local system fully under your control or a remote system controlled by somebody you don't trust? does it need to be protected against some nosy family member with not much knowledge of IT or against an advanced attacker which has hacked your system? What is the impact if the password leaks, i.e. just a nuisance vs. lots of invested money lost? Etc. Commented May 1 at 4:58
  • We have a few questions here on similar topics: security.stackexchange.com/questions/193047/…
    – schroeder
    Commented May 1 at 6:53
  • @SteffenUllrich So all of my concern just comes from wanting to learn and if someone were to somehow get access to my db file, they wouldn't be able to decipher my passwords. But I also plan to release my application as open source so I'm wondering how I could scramble the encryption to be unique for each user. If they were to get the passwords the risk is really just a loss of personal time spent if they hijack the account or steal items. Commented May 1 at 18:18
  • 1
    @HandmadeWeakness: "if someone were to somehow get access to my db file, they wouldn't be able to decipher my passwords" - so you need to encrypt these with a key the attacker does not get access too. This means that the encryption key should not be simply stored as readable on the same system, because then the attacker which is able to get the DB could get the key too. So either it is the user entering the key (like common with password managers) or some hardware (like TPM) keeping the key and doing the decryption -> see answer from Adam Katz Commented May 1 at 18:25

1 Answer 1

5

If this is a desktop app, connect to your session-locked password store (e.g. GNOME keyring/KWallet for Linux, Apple Keychain for Macs, or Credential Manager for Windows).

If this is a server system, consider a password vault like the free/open-source Bitwarden Secrets Manager.

Otherwise, consider a hardware token. While you can't use security keys without support from the service you're logging into, you can use a peppered hash of some static hardware facet (like a hardware token's public key) that your code never stores (it looks it up every time). If somebody gets your code, they only get the pepper. They'd need access to your physical system to get the passcode. (Warning, this is not a vetted proposal and probably isn't terribly secure, though it is better than storing a password in the clear. Why can't you use a password manager or vault?)

2
  • I've used the machine's serial# for this in the past. (in cases where you don't have a TPM ) It just becomes a part of the key... no hash. Commented May 7 at 22:08
  • 1
    @browsermator – The reason I suggest a peppered hash is that if the password is ever leaked, you can just change the pepper and get a whole new password out of it.
    – Adam Katz
    Commented May 7 at 22:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .