Encryption

[aaroncm]

Hi Guys,

 

First off, not sure if this is the correct area to post. My question is a little bit mixed, including SQL and PHP.

 

I'm building a basic private messaging system, and planned to use PHP, SQL for the storage, and a little bit of JS on the client. I'm a little confused when it comes to encryption though. My understanding with user password encryption is that the password is stored in the database as a hash, and then a user sent password is compared to the original hash for verification. I've implemented this successfully using password_verify() and password_hash() functions, and I'm pretty sure it's working fine.

 

However, my big question is in regards to the storage of message data. As far as I can tell, this system won't work, it's really only suitable for password verification because the hash can't really be reverted to the original data, it can only be compared? How should I go about encrypting message data? Is it possible? If I open up a SQL database containing private message data on a server, I don't want to be able to read the contents.

 

Any help would be greatly appreciated!

[Jacques1]

My advice is: Don't do it.

 

Without expertise and experience in the field of cryptography, you will screw up. What you describe as simple “encryption” of private messages is much more than that: You have to worry about key management, ensuring the integrity and authenticity of the messages, choosing the right techniques, getting all the ugly little details right etc.

 

But what's much worse is that the concept is already flawed: You said that you don't want to be able to read the messages, but at the same time you want to manage the encryption process. That's a contradiction in terms. If you manage the keys, then of course anybody with sufficient access to the server can read the messages. In fact, it's questionable whether the encryption has any benefit at all. Since the keys are basically sitting right next to the ciphertext, an attacker may very well get both, in which case you might as well have stored plaintext. What's the concrete attack scenario you're trying to protect against?

 

If you want to make sure that the message are indeed private, then you have to leave the encryption to the user. For example, they could use GPG to encrypt the message on their PC, paste the ciphertext into the message field, and then the receiver decrypts the ciphertext on their PC again. Your job would be limited to sending plaintext messages around (without any encryption whatsoever).

[aaroncm]

Thanks for the advice. That does make sense. So basically, when it comes down to data privacy, most of the time someone's going to have access, and it's reliant on a trustworthy person more than encryption?

 

That's fine. I wasn't 100% sure on how to go about the project when it came to user security and privacy. So are you saying it's common practice for chat data to be stored as plain text?

 

For me it just wouldn't feel right being able to see other people's chat history. I'll just avoid it. I planned on making a chat system kind of in between instant and private messaging type. So I'll probably set a limit on message storage. Maybe 100 max history chat messages or something.

 

Any further input is highly appreciated.

 

Thanks a lot!!

[Jacques1]

Not sure if you've understood this correctly. The messages are encrypted. They're just not encrypted by you but by the users themselves – if they choose to do this.

 

The idea of encrypting the data on the server so that you can't see it is rather silly. If you respect the privacy of you users, just don't read the messages. You may set up a database view so that you won't “accidentally” see them. If you don't respect the privacy of your users, why do you care about encryption in the first place?

 

The point of encryption is to make it impossible for unauthorized people to read the data. It's not about “covering your eyes”. If that's your goal, there are much better tools like the already mentioned database view.

[aaroncm]

No I understood you fine. The message data isn't encrypted, unless the users manage it themselves. That's fine.

I just didn't know what was the norm when it came to this sort of thing. So I've decided the messaging data can stay stored as plain text, and I'll limit chat history. And obviously keep the login password encryption.

[Jacques1]

I wouldn't necessarily say it's the norm. Server-side encryption is actually fairly popular, but for the wrong reasons. Users like it, because they're lazy and usually can't tell the difference between actual security and security theater. And service providers like it, because it allows them to throw around fancy terms like “RSA” or “military-grade AES-256 encryption”.

 

The question is whether encryption makes sense in this case. What's the concrete benefit? What does it protect against?

 

A good example for this discussion is the now-defunct e-mail provider Lavabit (I'm sure you've heard about it). They also used all kinds of fancy encryption and made big promises. As long as no unauthorized persons had access to the server, things indeed went well. But when they were forced to hand over their private TLS key, the whole encryption layer more or less vanished. In other words, they had the exact same problem like a run-of-the-mill provider which does not encrypt their e-mails. So what was the whole point of this project? To make people feel secure when they aren't?

 

Personally, I prefer honesty. I don't make promises I cannot keep. If users send their plaintext messages to the server, they're not secure. I could make the situation a bit less bad, but I cannot escape the basic fact. So I rather make it clear that the messages are unprotected unless client-side encryption is used.

[gizmola]

Jacques makes a lot of excellent points, and I don't disagree with him, however, I think a devil's advocate position is merited.

 

First off, there is support for many types ofencryption/decryption with http://php.net/manual/en/book.mcrypt.php

 

Hashing is not encryption of course, and is one of the reasons that people favor it for password access --- because the cipher text can not be decrypted. Your post reflected that you understand this concept adequately.

 

There are times when people want to do what you're asking about, or even more frequently, they are forced to add encryption of certain types of data for legal/compliance reasons. One example would be the storage of credit card information.

 

Jacques points out that if there is a master key and the server is compromised, then the user will obtain the data anyways. That isn't necessarily true. For example, if you have a well secured password, crackers might execute a SQL injection or application level exploit that discloses or leaks data, without fully compromising the system. They will not be able to decrypt the data without the key.

 

I don't look it this as Security Theater, but rather, adding additional barriers to the access of cipher text. One of the reasons this is sometimes implemented, is to deal with the issues inherent in database backups. If your data is encrypted, then a database backup is not a concern, so long as that data is kept independent of the private key.

 

I'm not arguing that you should bother to encrypt the data in your use case, but you should also be free to consider your options, and you should also feel free to implement a proof of concept, even if you ultimately decide not to bother, purely as a way of continuing to explore and familiarize yourself with the tools available and security in general.

[Jacques1]

First of all, I am not against encryption in general. Quite the opposite: Using the right tool for the right reasons is fantastic, and I applaud everybody who does it.

 

The problem is that there's way too much bad cryptography. It's easy to call a bunch of Mcrypt functions, store the ciphertext somewhere and tell everybody that their data is now super-secure. This requires little more than common sense. But it's damn hard to define a concrete security context, choose the right tool and use it in the right way. Unless you actually have a security background and a lot of experience, I'd say it's as realistic as a layman managing to perform a brain surgery.

 

Even worse: Screwing up cryptography does not mean that you're simply back to square one. You've invested a lot of time and trust, and if the solution then turns out to be broken, that's a real problem. While you were busy encypting your stuff, other security techniques had to wait. While you thought that your data is safe, it wasn't. In other words, a failure makes you actually lose something.

 

If there's little to gain, a lot to lose and a poor success rate, the usual answer is to not do it.

 

Let's take your database encryption as an example. I do agree that this sounds like a good idea at first. But it's easier said than done:

• How do you encrypt the data? If you use AES_ENCRYPT() within MySQL, you've already lost, because this gives you the extremely insecure “Electronic Code Book” mode (known from the Adobe password leak). The plaintext may also pop up in the query log.
• So you use Mcrypt instead, which is not exactly the best choice either. Are you sure you're using it correctly? Large frameworks like Yii or Laravel have already screwed up, so you need to be better then those.
• How do you manage the initialization vectors? Every single piece of data needs a perfectly random string next to it.
• How do you manage the keys? You need a way to change them in case they have been compromised. That means decrypting all ciphertext, regenerating all initialization vectors and encrypting all plaintext again. Not exactly trivial.
• Encryption alone only provides confidentiality, it does not help against manipulation. For example, if the attacker is able to change the initialization vector, they control the resulting plaintext. That's probably not what you want. If you decide to add a message authentication code as well, that means three times as much effort and an even bigger risk of screwing up.

Sure, this is all doable. But is it really a good idea to spend a large part of the development process on a very fragile security feature which only helps in a specific scenario?

 

Playing with cryptography to learn from it is an entirely different story. If that's your goal, do whatever you like. But don't even think about using it in production.

[aaroncm]

Encryption was just something I was considering throwing in, for the hell of it. Before I started this thread I didn't know much about it, I assumed I could throw in a few function calls and have some semi-decent security, but I guess not.

 

I can see how it can be more trouble than it's worth. I don't need to encrypt message data, I just thought it would be something users would like. But like you have stated, the data is, for the most part, never going to be 100% secure.

 

Thanks for the input. I still might play around with it anyway.

 

(Also, Administrator Gizmola, do all posts have to be approved by a Moderator? Am I meant to have an email verification message or something because I haven't gotten one?)

 

Thanks!

[CroNiX]

I never receive mail from this site either.

[Jacques1]

That's not really related to encryption, so you should post it into the right forum. Actually, there is a thread about it already.

[darklexus2k9]

why dont you have your servers take the usernames of both parties and join them together than use a random genarated string appended to the end hash this then use that has as a salt for creating another hash and use this to store it on your system ?

 

or the most secure way have your messanger ask the user for a password client side and then use this as a salt for a hash and encrypt the messages client side before they are even sent to your servers ? this way you have no idea what the salt is and you couldnt decrypt it orbsee it and in order for the other person to read the message they must have password the other user used to encrypt it in the first place witch could only be given directly ?

 

this way a user could use a diffrent password for every person they messaged and even if one password was guessed the rest would bebsecure and all your server would hold is encrypted messages with an unknown salt ?

[Jacques1]

why dont you have your servers take the usernames of both parties and join them together than use a random genarated string appended to the end hash this then use that has as a salt for creating another hash and use this to store it on your system ?

 

I have no idea what you mean and what you're trying to achieve.

 

 

 

or the most secure way have your messanger ask the user for a password client side and then use this as a salt for a hash and encrypt the messages client side before they are even sent to your servers ? this way you have no idea what the salt is and you couldnt decrypt it orbsee it and in order for the other person to read the message they must have password the other user used to encrypt it in the first place witch could only be given directly ?

 

You keep talking about salts and hashes, but I'm not sure if you know what this actually means.

 

Anyway: Where does the client-side code come from? The server! This is simply server-side encryption in disguise. As I've already tried to explain, you cannot protect data from your self. If you control the encryption process, then you have access to the data. Period.

 

Exchanging passwords is also a bit ... dated. That was before the year 1970. Nowadays, we have tools like GPG which use asymmetric encryption.

 

 

 

this way a user could use a diffrent password for every person they messaged and even if one password was guessed the rest would bebsecure and all your server would hold is encrypted messages with an unknown salt ?

 

Again: What salt? Do you mean the key?

[gizmola]

(Also, Administrator Gizmola, do all posts have to be approved by a Moderator? Am I meant to have an email verification message or something because I haven't gotten one?)

We have moderation turned on because we're having a lot of issues with spam posts. Once you hit a threshold, your posts pass through moderation.