Read the blogs!
Started by Xarcell, October 06, 2011, 01:51:46 AM
Quote from: SoLoGHoST on November 07, 2011, 04:47:54 AMOk, why not allow an admin to view all attachments sent over PM? If this feature were implemented, it could be noted to the user in the same area where they attach files within their messages. Stating the membergroups that will be able to view their Private Messages (to the user), and perhaps even make it able to be approved. Since the Owner of the site may be held responsible for it, why not give them the option to do it, and provide a means for them to moderate it COMPLETELY! Private messages should be private, but attachments in these message, to me, should be public to a select member group (that the admin decides). But, most importantly, the user who sends the attachment(s) should be notified that they are sending a PUBLIC attachment within a Private message. Public meaning, it is possible for the Admin and other membergroups to view the content of an attachment if they deem so, in order to make sure that the content is allowed on their forum, or not.
QuoteNot sure if OOP would help SMF or hurt it. I'm leaning more towards the latter...
Quote from: live627 on November 07, 2011, 06:50:39 PMQuoteNot sure if OOP would help SMF or hurt it. I'm leaning more towards the latter...OOP as in WP-like rat's nest or well-designed OOP?
Quote from: SoLoGHoST on November 08, 2011, 02:35:27 AMSMF provides this ability to do this, by storing Private Messages within the database and NOT encrypting them. So in a way, SMF is already guilty of allowing the Admin and anyone who has access to the database, the ability to view PRIVATE and PERSONAL Messages!
Quote from: 青山 素子 on November 08, 2011, 12:25:52 PMQuote from: SoLoGHoST on November 08, 2011, 02:35:27 AMSMF provides this ability to do this, by storing Private Messages within the database and NOT encrypting them. So in a way, SMF is already guilty of allowing the Admin and anyone who has access to the database, the ability to view PRIVATE and PERSONAL Messages!I believe this has been discussed before. If they were stored in an encrypted form in the database, the key would still need to be stored somewhere to allow users to actually read the messages.If it's stored on the server, the admin has access and can still read messages should they want. If the key is stored on the user's machine (via HTML5 Web Storage or another mechanism) then that both limits the machines where messages can be read and sent and makes the contents permanently inaccessible if the key is lost from the user's computer. You also have to rely on the forum to not store a plaintext copy.The privacy of PMs on all forums is subject to the difficulty of accessing the messages. With some forums, you can "impersonate" users, allowing access that way. Others have easy-to-find code that will allow direct reading. With SMF it relies on the fact that there isn't any easy-to-find code, nor way to "become" a user, forcing a database dive that most admins are too unmotivated or unskilled to do.For more secure PMs over forums, the messages should be using PGP/OpenPGP encryption outside the forum itself.
Quote from: SoLoGHoST on December 11, 2011, 11:11:37 PMA simple base64_encode when inputting into the database and base64_decode after retrieving from the database would be sufficient enough IMHO. Or even serializing and unserializing it. But honestly, the fact that it is human readable tells me that you just don't care!
Quote from: 青山 素子 on December 12, 2011, 12:35:41 AMQuote from: SoLoGHoST on December 11, 2011, 11:11:37 PMA simple base64_encode when inputting into the database and base64_decode after retrieving from the database would be sufficient enough IMHO. Or even serializing and unserializing it. But honestly, the fact that it is human readable tells me that you just don't care!If one is just going to do that, why bother? I mean, seriously, how difficult is it to just decode it at that point? If you have enough skill to pull the right tables and display them, it's not even a hurdle to do a base64 decode on the column. As for serializing, plain text is plain text so that won't do anything at all.One more sure way of "protecting" on the database side is to just use aes_encrypt and aes_decrypt with a key generated at random on an install. Of course, that still doesn't prevent an admin from just changing those calls to not be used and then it's all plaintext on the backend yet again. It also doesn't protect you from an admin that decides to try and login as you so they don't have to dive into the database.See, that's the thing. Unless you are the only one that has the key, it's not private. Trying to use a forum's personal message system as a secure communication channel is stupid because you (usually) aren't the one with server and code access. Any "rogue" admin that really wants the messages can bypass any protection in the code.Think of it like a cellular phone call. Communications are encrypted from handset to cell site (that's the base64 on your suggestion), but the network provider has the ability to switch that on or off, or even listen in on the content of any communication going across the network it owns. If you want to use secure communication over that medium, you have to resort to encryption or some secure code that doesn't depend on the medium over which it's being transferred.So, all you are proposing is to burn CPU cycles on useless mechanisms to possibly make some people feel better for a bit of security theater. I'd rather use that CPU on something that's actually useful.So, I suppose you are correct in the accusation that the developers don't care. They don't care to do things that will impact performance and provide absolutely no benefit.
Quote from: SoLoGHoST on December 12, 2011, 10:25:09 AMWell, atleast with using base64_encode, you force the user to have to use a script to decode it as opposed to just reading it directly from the database.
Quote from: 青山 素子 on December 12, 2011, 12:35:41 AMIf you have enough skill to pull the right tables and display them, it's not even a hurdle to do a base64 decode on the column.
Quote from: SoLoGHoST on December 12, 2011, 10:25:09 AMSecurity should not be compromised because it impacts performance. Anyways, I suppose this is not really a huge security issue... You could also create a hash and base64_encode that even. Given the time of the personal message, we could even include this into an array, with the hashed message that is base64 encoded, as well as even the id from the database for it, serialize the array, and when we unserialize we check for the time to match the time of the PM in other columns of the table or the id.
Quote from: SoLoGHoST on December 12, 2011, 10:25:09 AMAnyways, just offering up alternatives. If you don't like them, or think it impacts performance too much, no problem. Just ideas is all they are.
Quote from: SoLoGHoST on December 12, 2011, 02:20:44 PMWhat I was suggesting with the hash, is that you see how hashes are used for file attachments in posts, well sort of the same method for this. The hash can be stored in the database for this, within the pm table, and can be used when unserializing the array that contains the message.
Quote from: SoLoGHoST on December 12, 2011, 02:20:44 PMBut, yeah, I suppose it wouldn't make any difference, especially if everything is coming from within the database on the output of the message.