1

A chat app I'm developing requires storing the chat history on the server. Whats the best way to securely store this? I do not want to store plain-text chat logs in a table.

My initial thought was storing them encrypted based on the *users password, however if the user forgets his password, whats the best way to handle that? Since I have no idea what the password is to decrypt and re-encrypt with the new password.

Another solution was encrypt everything with a public key, and keep the private key stored on a separate machine (and in local memory for that server) and fetch it when its needed to decrypt and grab the full chat history.

Any help or case-studies would be awesome.

*added to avoid confusion

Faisal Abid
  • 8,900
  • 14
  • 59
  • 91
  • 1
    "My initial thought was storing them encrypted based on the password" Whose password? – BoltClock Dec 12 '13 at 16:27
  • I can't imagine that users would be happy to give you their private key for you to store - kinda defeats the object. Just tell them that, if they lose their private key, they lose access to their history permanently. – Martin James Dec 12 '13 at 16:30
  • 3
    The private key scenario is a fantastic option, arguably the most secure route. That said, the risk with that is that anyone with the private key can decrypt it. That said, who are you trying to secure it from? Prying DBAs or theft? This is a good thread on a similar topic: http://stackoverflow.com/questions/70450/is-it-worth-encrypting-email-addresses-in-the-database – brandonscript Dec 12 '13 at 16:30
  • Why are you encrypting? Who are you trying to protect it from? Also, how do you know the user's password? If it's the user's password, should she be the only one to know it? – user93353 Dec 12 '13 at 17:01
  • Thanks R3mus. user93353 - the user would enter the password to "secure" his chat. Martin James - We would be generating a private key for them for this use only. – Faisal Abid Dec 12 '13 at 18:49

1 Answers1

0

Because if the DB is stolen, you want to protect against these:

  • Avoid plain text messages.
  • The keys can't be stored in the same database.
  • You don't want a single key, because if that is guessed, then they unlock everything.
  • You don't want the key keys tied to information provided by the user (especially if it is easily guessable or can change/forgotten).

So if you have the budget, I would use a hardware based solution. This would provide the necessary separation and supply you with good keys, that aren't stored on the file system or database, and will be stored securely themselves. You can start with a single card (keeping everything on the same physical server) or scale out to a rack-mounted box if necessary.

josh poley
  • 7,236
  • 1
  • 25
  • 25