Thema: Verschlüsselte pdf-Datei als E-Mail Anhang

[K!aus]

Hallo ihr Lieben,

um mich etwas mit der Cloud zu beschäftigen, habe ich einen kleinen webservice geschrieben, bei dem registrierte Benutzer/innen kleine pdf-Dateien als verschlüsselter Anhang an eine Empfänger E-Mail verschicken lassen können: Secure Delivery.

Natürlich gibt es diverse Dienstleistung dieser Art, aber man muss ja mal zum Üben mit etwas anfangen. 

Ihr seid herzlichen eingeladen den Webservice zu testen.

Falls ihr Interesse habt, dann schickt mir doch eine PM mit einer E-Mail. Ich würde euch mit dem Benutzernamen eures Accounts registrieren und ihr erhaltet an die genante E-Mail euer Passwort. Von euch wird lediglich der Benutzername und das Passwort gespeichert, der E-Mail bedarf es lediglich einmalig zum Zusenden.

Ich bin gespannt und viele Grüße
  K!aus

[JollyOrc]

den verschlüsselten Inhalt und das Passwort dazu über den gleichen Kanal zu senden ist aus OPSEC Sicht aber auch eher...

...fragwürdig?

Als Programmierübung aber ein hübsches Projekt! 

[K!aus]

Hi JollyOrc,

besten Dank für dein Feedback.

Du hast recht, dass es nicht schön ist, den Inhalt als auch das Passwort über den selben Kanal zu schicken. Um das etwas zu entzerren, habe ich zumindest zwei verschiedene E-Mails gewählt. 

Ich kann mir gut vorstellen das Passwort fortan z.B. mittels sms77 zu versenden.

Allerdings bin ich ehrlich gesagt etwas bei der Benutzerfreundlichkeit hängen geblieben, denn mit der Variante des Passworts via sms, muss ich als Sender ja zwei Empfänger-Daten eingeben. 

Natürlich könnte ich einem Benutzer auch die Möglichkeit geben potentielle Empfänger mittels E-Mail und Handynr. zu hinterlegen, dann ist der Webservice aber nicht mehr Stateless. 

Zu guter letzt könnte ich natürlich die Datei (dann nicht mehr unbedingt pdf) als BLOB in der Datenbank speichern und mit der E-Mail nur eine url schicken, die zum Download der Datei führt, allerdings vorher ein Passwort abfragt, dass man via sms erhält. 

Viele Grüße
  Klaus

[JollyOrc]

Ggfs. den Webservice nur zum Verschlüsseln nutzen, das Ergebnis über die Webseite zurückgeben, und dann die Benutzer selbst wählen lassen, wie sie PDF und Passwort versenden wollen?

Dann musst Du auch überhaupt keine Daten erheben

[1of3]

BLOB in der Datenbank

Das ist tendenziell ungünstig. Jedenfalls wenn du mit Datenbank SQL meinst. Denn wenn du deine relationale Datenbank irgendwie backupst, machen Blobs die Sache ganz schnell unangenehm groß. Besser ist es den Dateiinhalt auf einem gesonderten Verzeichnis abzulegen und in der DB nur die Metadaten und den Speicherpfad zu halten. Handelsübliche Dateisysteme sind auch sehr gut darin Dateien zu händeln.

[Blechpirat]

Handelsübliche Dateisysteme sind auch sehr gut darin Dateien zu händeln.

Es ist, als ob sie dafür geschrieben worden wären

[K!aus]

Hi,

Das ist tendenziell ungünstig. Jedenfalls wenn du mit Datenbank SQL meinst. Denn wenn du deine relationale Datenbank irgendwie backupst, machen Blobs die Sache ganz schnell unangenehm groß.

Hast du dazu eine ausführliche Quelle, da mir die Zusammenhänge mit dem Backup nicht klar sind. 

Handelsübliche Dateisysteme sind auch sehr gut darin Dateien zu händeln.

Verstehe ich, aber wenn ich schon eine Datenbank habe, warum sollte ich dann eine zweite Persistenzschicht, d.h. weitere Abhängigkeit einführen? Zumal auch nicht klar ist, ob ein Dateisystem vorhanden ist, dort wo der Service ausgerollt wird. 

Tolle Diskussion, viel Input. 

[Turgon]

Das ist tendenziell ungünstig. Jedenfalls wenn du mit Datenbank SQL meinst. Denn wenn du deine relationale Datenbank irgendwie backupst, machen Blobs die Sache ganz schnell unangenehm groß.

Hi,Hast du dazu eine ausführliche Quelle, da mir die Zusammenhänge mit dem Backup nicht klar sind. 

Wenn du ein Backup der DB machst, backupst du die Dateien jedes mal mit, obwohl es nicht viel Sinn macht, sie mehr als einmal zu backupen. Die Dateien werden höchstwahrscheinlich mit Abstand den Löwenanteil der Backupgröße ausmachen – und das jedes mal.
Nehmen wir an, du machst jeden Tag ein Backup, die Größe der Dateien in der DB beträgt 1 GB. Dann hast du schon innerhalb einer Woche relativ sinnlos 7 GB angesammelt, die nur Platz wegnehmen. Liegen die Dateien dagegen im Dateisystem, kann man dort die ganz normalen Dateisystem-Backups fahren.
Das Problem dabei natürlich ist: Der Client muss irgendwie an das Dateisystem rankommen. Deswegen verwende ich bei meinen DBs eine Art Hybridlösung: Der Client redet nur mit der Datenbank, und die übernimmt das Handling auf dem Dateisystem.

[K!aus]

Hi,

[..]
Nehmen wir an, du machst jeden Tag ein Backup, die Größe der Dateien in der DB beträgt 1 GB. Dann hast du schon innerhalb einer Woche relativ sinnlos 7 GB angesammelt, die nur Platz wegnehmen. Liegen die Dateien dagegen im Dateisystem, kann man dort die ganz normalen Dateisystem-Backups fahren.
[..]

Ich vermute du meinst mit normalen Dateisystem-Backups sowas wie nur neue Dateien backupen oder bei neuerem Zeitstempel eben die aktuelle Datei nehmen (falls kein diff benötigt wird, i.e., versioning), privat verwende ich dazu rsync.

Aber geht diese Art des Backups nicht auch mit einer Datenbank? Ich meine, ich kann mich ja auch mit einem Dateisystem "dämlich" anstellen und einfach jeden Tag die komplette Platte speichern, dann wäre dein genanntes Beispiel nicht spezifisch für den Vorteil eines Dateisystems, sondern einfach wie man geschickt sichert.

[1of3]

https://dzone.com/articles/which-is-better-saving-files-in-database-or-in-fil

Deswegen verwende ich bei meinen DBs eine Art Hybridlösung: Der Client redet nur mit der Datenbank, und die übernimmt das Handling auf dem Dateisystem.

Bei uns in der Firma nutzen wir eine Erweiterung für die ORM-Schicht, die das freundlicher Weise mit erledigt.

[Turgon]

Hi,Ich vermute du meinst mit normalen Dateisystem-Backups sowas wie nur neue Dateien backupen oder bei neuerem Zeitstempel eben die aktuelle Datei nehmen (falls kein diff benötigt wird, i.e., versioning), privat verwende ich dazu rsync.

Genau, dh jede Datei landet genau einmal in den Backups.

Aber geht diese Art des Backups nicht auch mit einer Datenbank? Ich meine, ich kann mich ja auch mit einem Dateisystem "dämlich" anstellen und einfach jeden Tag die komplette Platte speichern, dann wäre dein genanntes Beispiel nicht spezifisch für den Vorteil eines Dateisystems, sondern einfach wie man geschickt sichert.

Nein, das geht mit Datenbanken nicht, das ist nicht sinnvoll.
Man kann einzelne Tabellen vom Backup ausschließen, aber nur Änderungen an Tabellen zu backupen geht nicht sinnvoll und würde auch eine Wiederherstellung der DB zum Alptraum machen, da man ja aus einer ganzen Menge Backups sich die Datenbank zusammenklauben müsste und auch noch die Konsistenz beachten.
EDIT: Wobei es da allerdings Möglichkeiten über ein Backup der Transaktionsdaten gibt, aber ein komplettes Datenbankbackup nur über die Transaktionsdaten zu fahren halte ich für sehr risikoreich.

[K!aus]

Hi,
besten Dank für diesen Exkurs der Datensicherung. Wieder einmal zeigt sich, dass dies eine Welt für sich ist. 

Auch wenn diese Diskussion spannend ist, würde ich als nächstes eher zusehen über z.B. sms77 einen zweiten Kanal der Übertragung des Passworts aufzumachen. Als Konsequenz die Datei(en) verschlüsselt zu speichern (auch wenn erstmal als BLOB) und diese mittels einer versandten url verfügbar zu machen (security through obscurity) dürfte wieder {einiges, genug} an Arbeit mit sich bringen.

Darüber hinaus geht es ja um Zustellung, d.h. ich würde eher einen Zeitstempel einfühen, s.d. die Datei(en) nach z.B. 10 Tage gelösch werden.

Viele Grüße
  K!aus

[Turgon]

Darüber hinaus geht es ja um Zustellung, d.h. ich würde eher einen Zeitstempel einfühen, s.d. die Datei(en) nach z.B. 10 Tage gelösch werden.

Die Datenmenge sinnvoll zu begrenzen ist natürlich das einfachste