2

So, a friend and I are currently writing a panel (in python/django) for managing gameservers. Each client also gets a MySQL server with their game server. What we are stuck on at the moment is how clients will find out their MySQL password and how it will be 'stored'.

The passwords would be generated randomly and presented to the user in the panel, however, we obviously don't want them to be stored in plaintext or reversible encryption, so we are unsure what to do if a a client forgets their password.

Resetting the password is something we would try to avoid as some clients may reset the password while the gameserver is still trying to use it, which could cause corruption and crashes.

What would be a secure (but without sacrificing ease of use for the clients) way to go about this?

icebox3d
  • 449
  • 7
  • 17
  • *"presented to the user in the panel"* && *"don't want them to be stored in plaintext or reversible encryption"* I don't understand. – Waleed Khan Dec 23 '12 at 02:50
  • We want to be able to recover the presented password down the line if the user forgets it but doing so in a secure way. – icebox3d Dec 23 '12 at 02:52
  • 2
    Don't store passwords in a recoverable fashion. Just implement password resets and be done with it. – Peter Rowell Dec 23 '12 at 03:13
  • However the problem is that if someone resets their password when the game server is running it could cause problems with data integrity. However I think we will go not storing them – icebox3d Dec 23 '12 at 03:21
  • There's no reason "data integrity" should be affected by a reset. – Peter Rowell Dec 23 '12 at 03:46

2 Answers2

4

Though this is not the answer you were looking for, you only have three possibilities

  • store the passwords plaintext (ugh!)
  • store with a reversible encryption, e.g. RSA (http://stackoverflow.com/questions/4484246/encrypt-and-decrypt-text-with-rsa-in-php)
  • do not store it; clients can only reset password, not view it

The second choice is a secure way, as RSA is also used for TLS encryption within the HTTPS protocol used by your bank of choice ;)

Phil Rykoff
  • 11,999
  • 3
  • 39
  • 63
  • 1
    I would go for option #3. By only allowing resets you completely eliminate the problem of key storage for reversible encryption. Resetting passwords is a *totally* solved problem. – Peter Rowell Dec 23 '12 at 03:12
  • Totally "Yes", but as the problem included password *recovery* by OPs definition... No :))) – Phil Rykoff Dec 23 '12 at 03:20
  • IMNSHO, "password recovery" is a nice sounding, but naive feature to spec; unfortunately it is essentially insecure. Password reset *is* secure (or at least it can be). But then maybe security doesn't matter for this application. – Peter Rowell Dec 23 '12 at 06:42
1

Your question embodies a contradiction in terms. Either you don't want reversibility or you do. You will have to choose.

The usual technique is to hash the passwords and to provide a way for the user to reset his own password on sufficient alternative proof of identity. You should never display a password to anybody, for legal non-repudiability reasons. If you don't know what that means, ask a lawyer.

user207421
  • 305,947
  • 44
  • 307
  • 483