Private Nachrichten verschlüsseln mittels EN/DECODE() sinnvoll?

[Truncate]

Hallo,

bei einer Community sollen ALLE internen Nachrichten verschlüsselt werden damit nicht der Vorwurf entsteht, der Betreiber oder der Support würden eventuell "mitlesen" etc.

Auch bei einem eventuell Hackangriff sollte dem Hacker nicht tausende Mails in Klartext in die Hände fallen.

Nun kann man ja mittels EN/DECODE() verschlüsselte Nachrichten in die DB schreiben.

Natürlich sollte nicht immer das gleiche Passwort benutzt werden, sonst macht das ganze ja keinen Sinn.

Wenn man allerdings für jede Mail immer das aktuelle Passwort des Users nimmt, sind alle Mails bei einer ev. Passwortänderung verstümmelt.

Ich als Betreiber sollte "wirklich" keine Möglichkeit haben, die Mails zu lesen sondern nur die Verfasser.

Denkbar wäre vielleicht die obige Möglichkeit mit dem Userpasswort, wo aber dann bei einer Änderung auch immer alle Nachrichten erst entschlüsselt werden und anschließend mit den neuen Passwort wieder reingeschrieben werden.

Was meint ihr dazu?

[goth]

Re: Private Nachrichten verschlüsseln mittels EN/DECODE() sinnvoll?

Original geschrieben von Truncate
Denkbar wäre vielleicht die obige Möglichkeit mit dem Userpasswort, wo aber dann bei einer Änderung auch immer alle Nachrichten erst entschlüsselt werden und anschließend mit den neuen Passwort wieder reingeschrieben werden.

Das würde allerdings bedeuten, dass irgendwo das Kennwort des Benutzers gespeichert ist. Solange verschlüsselnder und entschlüsselnder Algorithmus im gleichen Zugriffsbereich liegen dürfte es wohl kaum 'ne sichere Methode geben. Denkbar ist in diesem Falle bestenfalls das verschlüsseln der Daten um ein einfaches (versehentliches) lesen zu verhindern.

[wahsaga]

Re: Private Nachrichten verschlüsseln mittels EN/DECODE() sinnvoll?

Original geschrieben von Truncate
Auch bei einem eventuell Hackangriff sollte dem Hacker nicht tausende Mails in Klartext in die Hände fallen.

Stimmt - die kleine Hürde, dass - nach deiner Idee - ebenfalls in der DB stehende Passwort auch noch auszulesen, und damit die Nachrichten zu entschlüsseln, soll er schon noch selber nehmen ... ist wohl auch eine Frage der Hacker-Ehre.

Ich als Betreiber sollte "wirklich" keine Möglichkeit haben, die Mails zu lesen sondern nur die Verfasser.

Bevor du die Daten speicherst, musst du sie ja erst mal in Empfang nehmen.
Und nichts und niemand - außer deinem Ehrenwort - kann mir garantieren, dass du sie nicht dabei schon "mitliest", bzw. neben der DB noch irgendwo anders ablegst.

[onemorenerd]

ACK, um auszuschließen, dass der Support mitliest, müßtest du die Nachrichten schon beim Client verschlüsseln, wozu er einen Key bräuchte. Technisch noch machbar, aber zum Entschlüsseln bräuchte der Empfänger ja den selben Key (ich reduziere das Prinzip des Public/Private-Key hier mal, das Problem bleibt das selbe). Wie kommt also der Key vom Sender zum Empfänger? Über deinen Server sicher nicht, denn dann kennst du ihn und könntest die Nachricht decodieren. Bleibt also nur der direkte Weg: Der Sender mailt dem Empfänger den Key direkt ... das kann er sich dann auch sparen und stattdessen die eigentliche Nachricht senden.

[Truncate]

Naja der "Support" hat lediglich Zugriff auf eine Adminoberfläche und eventuell noch phpmyadmin.

[onemorenerd]

Wenn du es schaffst, DAS den Usern zu verkaufen, dann kannst du ihnen auch gleich glaubhaft machen, dass NIEMAND ein Interesse daran hat, ihren Kram zu lesen.

[Truncate]

Ja ist halt schwer, besonders wenn irgendwelche Neider solche Behauptungen einfach mal in den Raum stellen...

Ansonsten interessiert mich der Mailverkehr wirklich nicht, da es meist ja eh das gleiche Gebrabbel ist...

[goth]

Original geschrieben von Truncate
..., da es meist ja eh das gleiche Gebrabbel ist...

Aha ... du kennst es also schon ... !

[sono]

Hm man kann schon ein wenig machen um seine sachen etwas zu schützen.

Wenn du den Weg von Client zu Server veschlüsseln willst bekommst du das mit ssl problemlos hin.

Dann kannst du einmal das Filesystem verschlüssel und so das auslesen verhindern wenn jemand direkt auf die Daten zugreifen möchte.

Weiter kannst du zb ein externens Programm per exec einbinden dass die verschlüsselung und entschlüsselung der Daten übernimmt.

So kannst du Daten verschlüsseln ohne dass man leicht nachvollziehen kann wie du es gemacht hast.

Der Angreife müsste schon deinen Server komplett hacken um an alle Daten zu kommen die er benötigt.

Ich hab das Problem mal folgendermasen gelöst:

1: Filesysteme auf dem die Datenbank und die Daten liegen transparent mit AES verschlüsselt
2: Wichtige Daten liegen verschlüsselt in der Datenbank , Ver und Entschlüsselung übernimmt ein externes Programm ( system() , exec() ).

Nachteil an der Geschichte ist, dass man beim Booten einmal das PWD fürs Filesystem eingeben muss und zum anderen das PWD zum Verschlüsseln und entschlüsseln der Daten.
Nebenbei hat man Performanceeinbusen von ein paar % ( ich glaube es waren bei uns ca 15% )

Vorteil, die Passwörter liegen nicht auf dem Server und selbst wenn jemand die Daten auslesen kann , hat er erst mal kaum Möglichkeiten die Daten zu entschlüsseln. Die Daten sind so vor Diebstahl der Festplatte sowie vor direkten Hackerangriffen über das Netz relativ gut gesichert.

Viel Spaß beim Nachbauen,

Ps von wegen Neider, stell die Jungs doch mal zur Rede. Nimm jemanden mit der Ahnung hat und verlange eine Ausprache bei dem dem Sie Mist erzählt haben.
Wenns ums Geld geht klärt man sowas mit einem Sachverständigen und einem Anwalt sowie einer direkten Konfrontation mit dem was gesagt wurde.

Das machste einmal und schon hast du Ruhe vor Dummbablern.

( Ist klar das das nur geht wenn man selbst im Recht ist.)

Gruß Sono