Hallo Cruz,
Und wie gesagt ist es eh für den privaten Einsatz gedacht.
Das hält uns aber doch nicht davon ab darüber nachzudenken wie man es in einem größerem Rahmen angehen würde oder? :) Und was für einen größeren Rahmen gut genug ist, das muss für deine Home-Applikation erst recht gut sein.
Stimmt schon. Aber übertreiben wollte ich es auch nicht ;-) Doch die Gedanken für den größeren Einsatz sind durchaus interessant.
Ich meine damit nicht die Übertragungszeit, sondern dass es unterwegs eine Menge Dinge, die schiefgehen können. Wenn du die Dateien auf einem direkterem Weg einliest, elimierst du Fehlerquellen.
Ich könnte auch ein upload Ordner einrichten und die Dateien dorthin verschieben und anschließend im Frontend eine Auswahlliste generieren lassen aus der ich die zu verschlüsselnden Dateien auswähle. So erspare ich mir das upload Formular und die damit einhergehenden Sicherheitsprobleme. Die verschlüsselnden Dateien werden dann in einen secure-Ordner verschoben. Beim decodieren dann in einen download-Ordner, in dem manuell wieder die Dateien geschreddet werden können, sobald die Datei nicht mehr gelesen werden soll.
Außerdem muss ich so nur überprüfen, ob die insert´s alle korrekt ausgeführt wurden und muss mich nicht darum kümmern, ob auch die Datei im Filesystem gelandet ist, falls ich alles in die DB ablege.
Du bist ja hart drauf. Checks machen eine Software langsamer. Alles was von einem User eingegeben wird muss auf Herz und Nieren geprüft werden, aber ein INSERT in die DB oder eine Schreiboperation ins Filesystem würde ich nicht mehr überprüfen, wenn sie ohne Fehlermeldung durchgelaufen ist.
Da möchte ich nur Fehlerquellen vermeiden. Und ein COMMIT, ROLLBACK oder auch LOCK table zusätzlich in den SQL Abfragen sind auch nicht so der große Aufwand.
Hm..ich würde das in einer Tabelle machen, weil es nur eine 1:1 Relation ist.
Meine Version:
id, metaangabe, pfadangabe zum encoded file
Würde auch gehen. Wenn man auf die Spalte metangabe noch einen Volltextindex legt, kann man mit MATCH AGAINST auch gut suchen lassen.
Ja wie sicherst du denn eine Datenbank? Klar zu Hause mit ein paar MBs brauchst du dir keine Gedanken machen, aber wir spielen ja großen Rahmen. Eine Datenbank mit "Haut und Haaren" zu backupen ist keine gute Idee, denn dan sichert man auch die Datenbank Programme, die Manuals und die Logfiles mit. Normalerweise ist ein Backup auf Platzersparnis optimiert und da haben solche Dinge nichts verloren, nur die reinen möglichst gut komprimierten Daten.
Ich sicher die einfach mit mysqldump, also wird nur das gesichert was ich brauche. Also keine Logfiles etc. Die Sicherung wird auch nur dann erstellt, wenn keine Datenbank Zugriffe/Schreiboperationen ausgeführt werden.
Klar hilft das shredden, nachdem du die Datei in die DB geschrieben und vom Filesystem gelöscht hast. Und das ENCODE ist sehr sicher was
das dekodieren mit einer Brute Force Attacke angeht. Aber mal angenommen ich breche in deinem System ein. Ich würde als erstes in deinem Quelltext nach dem Passwort suchen, was du für das ENCODE verwendest und schon habe ich deine Daten. User und Passwort für die Datenbank stehen wahrscheinlich sogar in einer leicht zu findenen Konfig Datei.
Nein, das Passwort würde ich erst über das Webfrontend eingeben und in der Session speichern. Das Passwort kann ich ggf. auch in der Datenbank speichern und mit PASSWORD() verschlüsseln. Beim einloggen wird überprüft, ob das Passwort stimmt. Falls ja, wird dieser String bis zum Ausloggen in der Session gespeichert und zum decodieren genutzt. Also liegt nirgends das Passwort im Klartext vor.
Wenn du eine neue Datei einpflegen willst, dann schreibst du sie ins Filesystem und verschlüsselst sie mit einem Passwort, dass du nur zum Zeitpunkt der Verschlüsselung eingibst. Dieses Passwort steht nirgends auf deinem Computer gespeichert, es existiert nur in deinem Kopf und ist höchstens mit altertümlichen Foltermethoden zu erlangen. Dann trägst du die Metaangaben + den Pfad zur Datei in die Datenbank ein und fertig. Jetzt sehe ich keine Möglichkeit mehr an deine Daten zu gelangen, wenn ich bei dir einbreche. Ich könnte bestenfalls deine Metaangaben dazu lesen. Und das shredden wird nebenbei auch komplett überflüssig.
Da weiss ich leider nicht ausreichend Bescheid, ob das shredden wirklich nicht notwendig ist. Evtl. wird beim verschlüsseln (egal ob mit encode oder einem verschlüsseltem Dateisystem) doch irgendwo eine unverschlüsselte Kopie angelegt, die zwar gelöscht wird aber mit diversen Tools doch zu restaurieren geht.
Da sehe ich noch Probleme: Ich habe vielleicht wunderbar die Dateien verschlüsselt, die ohne Passwort nicht zu decodieren sind (außer mit Brute Force), aber irgendwo liegen dann doch noch -für den normal Benutzer unsichtbar- die Dateien im Dateisystem. Mit diversen Tools kann man das ja wiederherstellen. Also suche ich noch eine Möglichkeit alle Dateien die gelöscht wurden auch zu shredden.
Viele Grüße
Andreas