Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?
You are not logged in.
Pages: 1
To prevent the latest problems (1, 2, 3, 4, 5, 6, 7, 8, 9, ... and 15 more topics) about leaking of personal data:
What about peer-to-peer encryption?
Only users on both ends will be able to read the message (maybe using their own specified Secret Key and their specified public Key). This will also prevent any 3rd connection from reading the content. The negative aspect of this is, that you won't be able to report the message, but you will still be able to block the one who wrote the message. The database will still store the "blank secret" cipher.
The positive aspects are, as already mentioned, the future safety (and now I mean the real meaning of "keeping the data safe", not safe like did the staff till now.)
Are there any other pros/cons of it?
The problem is that the key needs to be stored somewhere, and as EE is a web game that would have to also be in the database, so it wouldn't really be any safer than before.
Yes there are products that work around this, but there are massive limitations when it comes to viewing messages on a device other than the one you started on, and we can't really have this be the case for EE.
Edit: Found some background info if you're interested: https://core.telegram.org/tsi/e2ee-simp … are-a-mess
Offline
Use the salted hash of the password to encrypt an RSA private key. Publicize the public key.
Upload a new keypair when the account password changes.
Because this is a webgame, the system only prevents old messages before the leak from being read. The hacker can change the database or game code to alter the encryption behavior and execute man in the middle attacks. But it's the same level of security you get with WhatsApp end to end encryption (it's still pretty good).
I have never thought of programming for reputation and honor. What I have in my heart must come out. That is the reason why I code.
Offline
Use the salted hash of the password to encrypt an RSA private key. Publicize the public key.
Upload a new keypair when the account password changes.
In this case, that would be an incredibly unsafe thing to do...
Currently the person who had access to the database got a list of all messages, if we followed your procedure they would effectively get a list of 'hashes' of passwords. (Not hashes exactly, but things that could be used to crack a user's password in the same way as a hash could be)
If the level of security was the same for both the password system database and the mail system database then maybe, but the password system database is massively more secure than the rest of the game's database, so its really not a good idea.
Offline
Fair point.
The only reason it's "massively more secure" is that you guys don't have access to it. lol.
I have never thought of programming for reputation and honor. What I have in my heart must come out. That is the reason why I code.
Offline
The only reason it's "massively more secure" is that you guys don't have access to it. lol.
However, if the staff stores all the keys and text messages, don't they still have access to the text message?
yeha nonoe shoudl have acceso to the passwords its sad that they sitll have to be sotred somwhere to 'check'
thanks hg for making this much better and ty for my avatar aswell
Offline
yeha nonoe shoudl have acceso to the passwords its sad that they sitll have to be sotred somwhere to 'check'
nobody has access to the passwords and the topic is about inbox. (im not bullying you)
Offline
ingame mail is useless and beyond bad, just delete it
i never used it for things other than sending random meaningless garbage to my friends
However, some people didn't just send garbage, as from what I understood, some people leaked passwords in those inboxes...
This drama is a complete mess, I have no idea what's going on anymore.
Pages: 1
[ Started around 1713442948.6497 - Generated in 0.076 seconds, 12 queries executed - Memory usage: 1.5 MiB (Peak: 1.66 MiB) ]