XF 2.0 Encrypt Post
- Thread starter Hyprem
- Start date
oman
Well-known member
Not that I'm aware of.
Why are you looking to encrypt the source code of posts? Is there a particular content type you are including which you would rather not be copied?
DragonByte Tech
Well-known member
Encrypting a post is pointless in every single scenario except for a case where two members want to share content privately and they have exchanged the decryption key outside of your forum. In this scenario, it makes no sense to use your forum to share this content in the first place, as they should be using a secure email service instead.
You need to understand that the purpose of encryption is not to secure content that needs to be viewed by a potentially infinite amount of people. The purpose of encryption is to store content in such a way that only one person (you), or a select few people (you, and the people you give the decryption key to) can view the content.
If you encrypt a post, no-one can view it without unlocking the post. It is entirely impossible to encrypt a post in such a way that anyone trying to view the post will see the content (be it video or other content) automatically. If you did, then you would need to store the decryption key on your server alongside the post, making the entire process a complete waste of your time as anyone with access to your database also has access to decrypt your post.
There's also no browser support for encrypting the source code, but not the display, as that is not how web browsers work.
Don't be concerned about encryption for the sake of encryption. The idea that "encryption = more security" is completely false, you can have content encrypted over a thousand times but it is still entirely insecure, because you also send the decryption key along with the content when transmitting your message.
You need to understand that the purpose of encryption is not to secure content that needs to be viewed by a potentially infinite amount of people. The purpose of encryption is to store content in such a way that only one person (you), or a select few people (you, and the people you give the decryption key to) can view the content.
If you encrypt a post, no-one can view it without unlocking the post. It is entirely impossible to encrypt a post in such a way that anyone trying to view the post will see the content (be it video or other content) automatically. If you did, then you would need to store the decryption key on your server alongside the post, making the entire process a complete waste of your time as anyone with access to your database also has access to decrypt your post.
There's also no browser support for encrypting the source code, but not the display, as that is not how web browsers work.
Don't be concerned about encryption for the sake of encryption. The idea that "encryption = more security" is completely false, you can have content encrypted over a thousand times but it is still entirely insecure, because you also send the decryption key along with the content when transmitting your message.
Hmm, I think the underlined assumption is wrong.
If post content is encrypted/decrypted before being sent to/received from the database using a key that is not stored in the database, a person who only has (full) access to the database (which might be on completely different server) does not automatically also have access to the key.
If the data stored in the database also does not allow to gain access to that key I don't see a way how this person could decrypt the data unless there are (unknown) attack vectors that would allow access to the key by manipulating the DB (eg. using a PHP callback, etc.).
DragonByte Tech
Well-known member
I think you're a little bit caught up in the semantics of using the word "database" rather than "server" in this case. In order for a post to be displayable in the browser without the manual input of a decryption key, the decryption key will need to be stored either on disk or in the database (which is the same thing, really, as databases are files too).
In my opinion, if your security mechanism can be defeated in its entirety if someone gets the most basic of exploits running on your site (the c99 shell being a very common example that should immediately trigger PTSD flashbacks for anyone old enough to have been running a forum in the early 2000s), then the security mechanism is useless and you are only wasting your server's resources by using it.
This is why you don't use MD5 for hashing passwords anymore. If you have the option of using only plaintext or MD5, then there's no point in you using MD5 since it offers about as much security as storing the password in plaintext.
If a piece of security can be bypassed by the most basic exploit, then I consider it to be equal to no security. A hashed password (with a good hashing mechanism) is at least going to take some major effort to bypass, so it's as close to perfect security as we can get in today's day and age.
You just defeated your own point there. Although it may not be as easy with XenForo storing merely class loading instructions rather than actual PHP code directly in the database, there are still plenty of ways for a malicious attacker with DB access to gain access to your files as well, thus defeating the encryption of posts.
This is the first line in my previous post, and I stand by it:
Fillip
As pointed out before, there is a difference in having access to the database and having access to the filesystem.
Having access to the filesystem usually makes it very easy to gain access to the database, the crendentials are usually available in plaintext files.
On the other hand, having (limited) access to the database (for example via a SQL injection) does not necessarily allow easy access to the filesystem.
I therefore still disagree with your statement, it might not be comletely pointless to encrypt some data in the database.
It's also pointless to use passwords as anyone with enough time/computing power can crack them - yet we use them.
Or to build houses with doors and keys, anyone with the right tools and enough time can break them.
Absolute security does not exist, so the only thing we can do is trying to make unauthorized access as difficult as possible, and encrypting parts of the database without the keys being stored in the database does add a layer of complexity.
DragonByte Tech
Well-known member
Now I'm going to flip it around and get into semantics; having write access to the filesystem is very different to having read access.
In the example of the c99 shell (which, since you didn't comment on, I'm going to assume you didn't encounter much or at all back in the days when it ran rampant), it would always allow you to read files even if you couldn't write to them.
Therefore, storing the decryption key in the file system is absolutely not any more secure than storing it in the database.
I'm not going to comment on the rest of your post as I believe you're well aware that those are straw man arguments that have no bearing on the current discussion.
Fillip
Not wanna crunch into the tech stuff, but just pointing out the original point of @DragonByte Tech : it's just not how forums work. No matter how the encryption and all the stuff belonging to it would work, once you have to use the user himself as part of an active encryption, you've already lost.
That's how advanced level of authentication works and that's simply not in the range of SSO (Google, FB, ...) or simple logins (pw & mail) - but that's how forums work. Forums need this basic level of authentication to work.
That's how advanced level of authentication works and that's simply not in the range of SSO (Google, FB, ...) or simple logins (pw & mail) - but that's how forums work. Forums need this basic level of authentication to work.
