I want to implement a private messaging system to my website, but I'm wondering if the content of the -supposedly private- message between Alice and Bob should be stored in plain text in the database or it should be encrypted prior to that, so that even if the database is hijacked, the attackers wouldn't be able to read the messages.

So my questions are:

  • Is this neccessary to do if your site is not a banking/PayPal-like site? Do Facebook, YouTube, etc. do it this way?

  • How would I go about letting only Alice and Bob decrypt it?

It might be overkill to do this (at least in the website I'm working on), but if I'm going to do it, I guess it's better to do it before launching the site.

  • That's entirely up to you. You need to decide how the feature will be used and what your users will expect.
    – SLaks
    Commented Mar 11, 2013 at 19:13
  • @IlmariKaronen Yeah actually, I just realize that site exists.
    – John Doe
    Commented Mar 11, 2013 at 19:15
  • You could just encrypt the database as a whole. Then only worry about using asymetric (public/private key) to encrypt communication across the web, or simply SSL. While I'm not very knowledgable on this, I beleive SQL Server gives you this option.
    – Anthony Queen
    Commented Mar 11, 2013 at 20:20
  • @AnthonyQueen Thanks for the advice. I'll implement SSL on the website (more precisely, in the login form, while sending a private message and while reading it). Sadly, if the database is hacked, the attacker would still be able to read the messages.
    – John Doe
    Commented Mar 11, 2013 at 20:37
  • To a large degree, it depends on what the requirements are. Are the users led to believe the messages are private? To what degree? Should administrators or moderators have rights to view the messages?
    – Xander
    Commented Mar 11, 2013 at 22:41

3 Answers 3


the answer is probably using RSA to encrypt private messages. Each user has a keypair, and Alice uses Bob's public key to encrypt her message, and Bob decrypts it with his private key. The issue comes with the distribution and security of these keypairs

Since the only information known only to a user within a system like this is a password, it will be difficult to effectively and securely store the user's private key. The only mechanism I can think of is encrypting the private key with a key derived from the user's password. This private key is then stored, probably client-side, and used to encrypt and decrypt messages while the user is logged in.

Unfortunately, this system puts you at the mercy of security issues of whatever technology you choose to use (cookies, server-side session data, localStorage, etc), and a motivated attacker can probably circumvent it fairly easily. It would probably necessitate some sort of browser plugin to provide a brigde to gpg or equivalent to come even close to being secure, and that will end up being more trouble then it's worth.

Long story short: You probably can't do it in a way that is actually secure against a motivated attacker

  • Thanks for the answer! But yes, it's difficult to get this right. The private key should be derived from the user's password, but at the same time it should be stored outside the database, which is a whole different can of worms. I guess in the case of my website, it'd open more security holes than give benefits.
    – John Doe
    Commented Mar 11, 2013 at 20:33
  • What happens when a user changes their password?
    – Jeff Ferland
    Commented Mar 12, 2013 at 0:07

Well, as the previous posters already explained, a real encryption validating the recipient is very hard to implement.

What you can do with easier methods - like symmetric encryption on application level - is to create a layer of abstraction:
When an attacker gains access to only the datastore (like when there was a vunerability in the datastore's permission/ACL system or a possibility for query injection - those are common flaws), the data will stay safe. The application will be necessary to gain plain text.

I guess (no facts, though) that social networks and communities are unlikely to do more - or even do anything.

The only real answer for your topic question is: It depends. (like always)

If you're creating a forum about sweet cats, PN encryption is probably not an issue you should primarily deal with.


Well "Private" Messages should stay private. You could do this by encrypting the PMs with a symmetric encryption algorithm(such as AES) and having a second server(for more security) that accepts the session id, the PM id and responds with the pm key if the user is sender/recipient. Hope my answer is clear.

  • this is not a particularly secure system, as an attacker could easily forge messages to retrieve keys from the PM key server.
    – Peter Elliott
    Commented Mar 11, 2013 at 20:07
  • But every PM would have a different key
    – MemCtrl
    Commented Mar 12, 2013 at 5:50

You must log in to answer this question.