Dateien auf Server verschlüsseln
0 
dedlfix
0 0
Dateien auf Server verschlüsseln
Hi,
ich bräuchte da einen kleinen Gedankenanstoß:
Ich habe eine Website auf der sich verschiedene User einloggen können (Das Passwort ist als Sha-512 Hash in der DB gespeichert).
Ich möchte nun einen Upload realisieren, wo die einzelnen User Dateien hochladen können die dann verschlüsselt auf dem Server abgespeichert werden.
Ich möchte aber nicht, dass der User jedes Mal wenn er eine Datei ansehen bzw. herunterladen möchte, das Passwort zum Entschlüsseln eingeben muss.
Ich habe mir überlegt, dass ich die Datei mit dem User Passwort, mit dem er sich auch auf der Website einloggen kann, verschlüsseln könnte und wenn der User eingeloggt ist, sozusagen im Hintergrund die Dateien entschlüssel, damit der User das gar nicht mitbekommt.
Das Problem ist hier aber, dass ich das Passwort beim Login Vorgang in einer Session abspeichern müsste, da das Passwort in der DB ja nur als Hash abgespeichert ist.
Meine Frage hier wäre, wie sicher ist das?
Oder denke ich vollkommen falsch, und es gibt eine sicherere/bessere Lösung?
Danke
MfG
Naps
-
Tach!
Ich habe eine Website auf der sich verschiedene User einloggen können (Das Passwort ist als Sha-512 Hash in der DB gespeichert).
Auch gesalzt?
Ich habe mir überlegt, dass ich die Datei mit dem User Passwort, mit dem er sich auch auf der Website einloggen kann, verschlüsseln könnte und wenn der User eingeloggt ist, sozusagen im Hintergrund die Dateien entschlüssel, damit der User das gar nicht mitbekommt.
Das Problem ist hier aber, dass ich das Passwort beim Login Vorgang in einer Session abspeichern müsste, da das Passwort in der DB ja nur als Hash abgespeichert ist.Es bestünde auch noch die Möglichkeit, HTTP-Authentifikation zu verwenden, dann sendet der Client das Passwort immer wieder mit. Das kannst du dann verwenden und nach dem Request wieder vergessen. Selbstredend wäre spätestens dann HTTPS angebracht. Aber auch bei Passworteingabe über Formular wäre eine verschlüsselte Verbindung sinnvoll.
Meine Frage hier wäre, wie sicher ist das?
Das ganze System nützt dir wenig, wenn der Server kompromittiert werden kann. Eine Unterwegs-Verschlüsslung ist dann sinnlos, weil man ja gleich an der Quelle mitschneiden kann. Weiter wäre bei deiner Idee zu untersuchen, wer die Session-Daten lesen kann. Das setzt sich zum einen zusammen aus den Zugriffsbedingungen (Rechte) auf die Dateien auf deinem Server (die Session-Dateien und auch die mit deinem PHP-Code). Zum anderen muss das problem gekaperter Sessions beleuchtet werden. Über die Session-ID - auf welchem Wege auch immer sie ein Dritter in die Finger bekommt - kann man eine Session wiederaufnehmen, besonders dann, wenn der Nutzer einfach weggeht, sie nicht ordentlich schließt und ihre Daten bis zur nächsten Garbage Collection liegenbleiben, was durchaus länger als der eingestellte Timeout sein kann.
dedlfix.
-
Tach!
Ich habe eine Website auf der sich verschiedene User einloggen können (Das Passwort ist als Sha-512 Hash in der DB gespeichert).
Auch gesalzt?
Ja, ich hab in der DB für jeden User bei der Registrierung einen Salt erstellt und zusätzlich einer der für alle gleich ist. Schaut dann so aus:
sha-512($userPass.$dbSalt.$staticSalt)Ich habe mir überlegt, dass ich die Datei mit dem User Passwort, mit dem er sich auch auf der Website einloggen kann, verschlüsseln könnte und wenn der User eingeloggt ist, sozusagen im Hintergrund die Dateien entschlüssel, damit der User das gar nicht mitbekommt.
Das Problem ist hier aber, dass ich das Passwort beim Login Vorgang in einer Session abspeichern müsste, da das Passwort in der DB ja nur als Hash abgespeichert ist.Es bestünde auch noch die Möglichkeit, HTTP-Authentifikation zu verwenden, dann sendet der Client das Passwort immer wieder mit. Das kannst du dann verwenden und nach dem Request wieder vergessen. Selbstredend wäre spätestens dann HTTPS angebracht. Aber auch bei Passworteingabe über Formular wäre eine verschlüsselte Verbindung sinnvoll.
Meine Frage hier wäre, wie sicher ist das?
Das ganze System nützt dir wenig, wenn der Server kompromittiert werden kann. Eine Unterwegs-Verschlüsslung ist dann sinnlos, weil man ja gleich an der Quelle mitschneiden kann. Weiter wäre bei deiner Idee zu untersuchen, wer die Session-Daten lesen kann. Das setzt sich zum einen zusammen aus den Zugriffsbedingungen (Rechte) auf die Dateien auf deinem Server (die Session-Dateien und auch die mit deinem PHP-Code). Zum anderen muss das problem gekaperter Sessions beleuchtet werden. Über die Session-ID - auf welchem Wege auch immer sie ein Dritter in die Finger bekommt - kann man eine Session wiederaufnehmen, besonders dann, wenn der Nutzer einfach weggeht, sie nicht ordentlich schließt und ihre Daten bis zur nächsten Garbage Collection liegenbleiben, was durchaus länger als der eingestellte Timeout sein kann.
dedlfix.
Danke erstmals. Die Problematik ist also doch umfangreicher als ich dachte! Ich werde mir mal was überlegen und dann hier noch mal posten!
MFG
Naps
-
-
Moin!
Ich habe eine Website auf der sich verschiedene User einloggen können (Das Passwort ist als Sha-512 Hash in der DB gespeichert).
Die einzige gültige Speicherform für ein Passwort ist bcrypt-gehasht. PHP bietet da zum Glück ab Version 5.5 eine einfache Funktion an, die den ganzen Kram im Hintergrund einfach erledigt, und ab PHP Version 5.3.7 gibt es eine Bibliothek, die diese Funktion re-implementiert.
Siehe https://github.com/ircmaxell/password_compat
Ich möchte nun einen Upload realisieren, wo die einzelnen User Dateien hochladen können die dann verschlüsselt auf dem Server abgespeichert werden.
Was willst du damit erreichen?
Wenn ein User die Datei hochlädt, und durch die Verschlüsselung niemand anderes drankommt, kann er sich den Upload im Prinzip auch sparen. Von Online-Backups hast du auch nicht gesprochen (da wäre so eine Einweg-Speicherung nachvollziehbar). Aber selbst dort würde ich meine Daten VORHER verschlüsseln - ich vertraue dir einfach nicht, dass du dein Versprechen korrekt umsetzt und garantiert nach aktuellen Erkenntnissen sichere Verschlüsselung benutzt.
Ich möchte aber nicht, dass der User jedes Mal wenn er eine Datei ansehen bzw. herunterladen möchte, das Passwort zum Entschlüsseln eingeben muss.
Warum muss der User regelmäßig die Datei im unverschlüsselten Zustand benutzen bzw. erreichen können?
Offenbar ist es gegenüber dem User irrelevant, ob die Datei verschlüsselt ist. Sie verhält sich ihm gegenüber unverschlüsselt. Warum ist Verschlüsselung trotzdem relevant?
Ich habe mir überlegt, dass ich die Datei mit dem User Passwort, mit dem er sich auch auf der Website einloggen kann, verschlüsseln könnte und wenn der User eingeloggt ist, sozusagen im Hintergrund die Dateien entschlüssel, damit der User das gar nicht mitbekommt.
Das Problem ist hier aber, dass ich das Passwort beim Login Vorgang in einer Session abspeichern müsste, da das Passwort in der DB ja nur als Hash abgespeichert ist.
Meine Frage hier wäre, wie sicher ist das?Sicher gegen was? Ich halte es für unsinnig, die Sicherheits einer gewählten Lösung zu beurteilen, solange nicht klar definiert ist, gegen welches Szenario eine Abschottung durch Extraaufwand erfolgen soll.
Oder denke ich vollkommen falsch, und es gibt eine sicherere/bessere Lösung?
Wenn ein User ohne weitere Maßnahmen eine Datei hochladen und jederzeit wieder herunterladen kann: Welchen Sinn hat dann eine serverseitige Verschlüsselung? Erkläre mir den, und wir können weiterdiskutieren, welche Maßnahmen sinnvoll sind. :)
- Sven Rautenberg
-
Moin!
Ich habe eine Website auf der sich verschiedene User einloggen können (Das Passwort ist als Sha-512 Hash in der DB gespeichert).
Die einzige gültige Speicherform für ein Passwort ist bcrypt-gehasht. PHP bietet da zum Glück ab Version 5.5 eine einfache Funktion an, die den ganzen Kram im Hintergrund einfach erledigt, und ab PHP Version 5.3.7 gibt es eine Bibliothek, die diese Funktion re-implementiert.
Siehe https://github.com/ircmaxell/password_compat
da bin ich anderer Meinung!
Früher dachte man, md5 ist "Die einzig gültige Speicherform". Dann war es ein anderer Algorithmus und dann der nächste. Ich denke, dass ein gut gewähltes Passwort welches selbst nur mit md5 gehasht ist, einigermaßen sicher ist (in Verbindung mit Salts natürlich).
Wenn Jemand wirklich auf einen Account zugreifen möchte und genug Möglichkeiten hat, ist es mMn egal wie man es macht. Das beweisen finde ich jedes Mal die Meldungen, wenn das Pentagon oder andere Regierungsnetzwerke gehackt werden. Ich weiß das ist jetzt ein Apfel-Birnen Vergleich.
Wie viele Millionen werden für die Sicherheit bei solchen Websites oder generell Netzwerken ausgegeben und wie viele "Kluge" Köpfe sind dort nur für die Sicherheit Zuständig und trotzdem passiert es.Heute betrachtet man vielleicht bcrypt als "einzig gültige Speicherform" aber morgen kann das schon wieder anders sein.
Ich möchte nun einen Upload realisieren, wo die einzelnen User Dateien hochladen können die dann verschlüsselt auf dem Server abgespeichert werden.
Was willst du damit erreichen?
Wenn ein User die Datei hochlädt, und durch die Verschlüsselung niemand anderes drankommt, kann er sich den Upload im Prinzip auch sparen. Von Online-Backups hast du auch nicht gesprochen (da wäre so eine Einweg-Speicherung nachvollziehbar). Aber selbst dort würde ich meine Daten VORHER verschlüsseln - ich vertraue dir einfach nicht, dass du dein Versprechen korrekt umsetzt und garantiert nach aktuellen Erkenntnissen sichere Verschlüsselung benutzt.
Es geht mir in meinem Fall nicht um ein Backup sondern viel mehr darum, dass man auf die Daten immer zugreifen kann, egal wo man ist.
Die Daten VORHER zu verschlüsseln, ist keine Lösung die ich einen "Laien" "antun" möchte.Um was es mir auch geht ist folgendes. Wenn man unterwegs ist, hat man nicht immer die Möglichkeit die Daten lokal zu ver- bzw. entschlüsseln.
Ich möchte aber nicht, dass der User jedes Mal wenn er eine Datei ansehen bzw. herunterladen möchte, das Passwort zum Entschlüsseln eingeben muss.
Warum muss der User regelmäßig die Datei im unverschlüsselten Zustand benutzen bzw. erreichen können?
Offenbar ist es gegenüber dem User irrelevant, ob die Datei verschlüsselt ist. Sie verhält sich ihm gegenüber unverschlüsselt. Warum ist Verschlüsselung trotzdem relevant?
Einfach aus Sicherheitsgründen!
Ich habe mir überlegt, dass ich die Datei mit dem User Passwort, mit dem er sich auch auf der Website einloggen kann, verschlüsseln könnte und wenn der User eingeloggt ist, sozusagen im Hintergrund die Dateien entschlüssel, damit der User das gar nicht mitbekommt.
Das Problem ist hier aber, dass ich das Passwort beim Login Vorgang in einer Session abspeichern müsste, da das Passwort in der DB ja nur als Hash abgespeichert ist.
Meine Frage hier wäre, wie sicher ist das?Sicher gegen was? Ich halte es für unsinnig, die Sicherheits einer gewählten Lösung zu beurteilen, solange nicht klar definiert ist, gegen welches Szenario eine Abschottung durch Extraaufwand erfolgen soll.
Oder denke ich vollkommen falsch, und es gibt eine sicherere/bessere Lösung?
Wenn ein User ohne weitere Maßnahmen eine Datei hochladen und jederzeit wieder herunterladen kann: Welchen Sinn hat dann eine serverseitige Verschlüsselung? Erkläre mir den, und wir können weiterdiskutieren, welche Maßnahmen sinnvoll sind. :)
Wenn ein Mensch ohne weitere Maßnahmen seine Haustür aufsperren und jederzeit wieder zusperren kann: Welchen Sinn hat dann das eigentliche Zusperren der Haustür?
MfG
Naps-
Tach,
Früher dachte man, md5 ist "Die einzig gültige Speicherform". Dann war es ein anderer Algorithmus und dann der nächste. Ich denke, dass ein gut gewähltes Passwort welches selbst nur mit md5 gehasht ist, einigermaßen sicher ist (in Verbindung mit Salts natürlich).
das ist leider Unsinn, md5 und andere Crypto-Hashes sind darauf ausgelegt schnell zu sein und sind deswegen für den Einsatzzweck Passwortspeicherung schlecht geeignet; md5, SHA u.a. sind wunderbar auf Grafikkarten zu berechnen, md5 auf einer einzelnen GPU z.B. 400 Millionen Passwörter pro Sekunde (http://www.insidepro.com/eng/egb.shtml). bcrypt/scrypt dagegen sind darauf ausgelegt langsam zu sein und könenn damit genau das verhindern, was man bei einer verlorenen Passworttabelle verhindern will, nämlich einen Brute-Force-Ansatz; bcrypt ist sogar problemlos in der Zukunft um weitere Runden erweiterbar und damit relativ zukunftssicher (solange kein direkter Angriff auf den Algorithmus möglich ist.).
Wie viele Millionen werden für die Sicherheit bei solchen Websites oder generell Netzwerken ausgegeben und wie viele "Kluge" Köpfe sind dort nur für die Sicherheit Zuständig und trotzdem passiert es.
Es wird erschreckend wenig ausgegeben und es wird erschreckend wenig auf diejenigen gehört, die sich auskennen.
Heute betrachtet man vielleicht bcrypt als "einzig gültige Speicherform" aber morgen kann das schon wieder anders sein.
Ja und? Deshalb auf etwas noch schlechteres setzen ist sicher keine sinnvolle Lösung.
Offenbar ist es gegenüber dem User irrelevant, ob die Datei verschlüsselt ist. Sie verhält sich ihm gegenüber unverschlüsselt. Warum ist Verschlüsselung trotzdem relevant?
Einfach aus Sicherheitsgründen!
Sicherheit wovor? Du kannst auf die Daten zugreifen, jeder der dein System kompromittiert kann das, der User kann es; vor wem soll das schützen?
Wenn ein Mensch ohne weitere Maßnahmen seine Haustür aufsperren und jederzeit wieder zusperren kann: Welchen Sinn hat dann das eigentliche Zusperren der Haustür?
Da hat der User den Schlüssel in der Hand, das möchtest du ja nicht.
mfg
Woodfighter -
Moin!
Ich habe eine Website auf der sich verschiedene User einloggen können (Das Passwort ist als Sha-512 Hash in der DB gespeichert).
Die einzige gültige Speicherform für ein Passwort ist bcrypt-gehasht. PHP bietet da zum Glück ab Version 5.5 eine einfache Funktion an, die den ganzen Kram im Hintergrund einfach erledigt, und ab PHP Version 5.3.7 gibt es eine Bibliothek, die diese Funktion re-implementiert.
Siehe https://github.com/ircmaxell/password_compat
da bin ich anderer Meinung!
Das darfst du auch sein. Deshalb bietet diese einfach benutzbare API die Möglichkeit, sowohl programmiererseitig auch andere Algorithmen zu benutzen, als auch alle mit bisher aktiven Algorithmen erzeugten Hashes weiterhin auf die alte Weise zu prüfen, aber parallel auch zu prüfen, ob der gespeicherte Hash nicht doch aktualisiert werden soll, weil mittlerweile eben neue Erkenntnisse hinsichtlich der Sicherheit gewonnen wurden.
Es wäre damit also gar kein Problem, folgendes Szenario zu erfüllen: Ganz früher wurde MD5 eingesetzt, dann SHA1 - beides nicht mehr sicher. Deshalb jetzt BCrypt. Aber die alten Hashes kann man nur erneuern, wenn man das Passwort kennt, und das kriegt man nur beim Login des Users mit. Kann dann aber alle alten Hashes ein letztes Mal checken und danach prüfen, ob ein Upgrade notwendig ist. Falls ja, speichert man den neuen Hash ab.
Ja, uralte Accounts, in die sich niemand mehr einloggt, kriegen auf diese Weise nie einen neuen Hash. Da muss man sich aber sowieso fragen, ob der Account nicht nach einer gewissen Zeit der Inaktivität mal eine Benachrichtigung bekommen sollte.
Früher dachte man, md5 ist "Die einzig gültige Speicherform". Dann war es ein anderer Algorithmus und dann der nächste. Ich denke, dass ein gut gewähltes Passwort welches selbst nur mit md5 gehasht ist, einigermaßen sicher ist (in Verbindung mit Salts natürlich).
Nein, ist es nicht. Mit Brute-Force kann man bei gehashten Passworten, auch mit Salt, schon sehr viel machen. Und User sind ja nun wirklich nicht kreativ bei der Erstellung eines komplett zufälligen Passworts.
Wenn Jemand wirklich auf einen Account zugreifen möchte und genug Möglichkeiten hat, ist es mMn egal wie man es macht. Das beweisen finde ich jedes Mal die Meldungen, wenn das Pentagon oder andere Regierungsnetzwerke gehackt werden. Ich weiß das ist jetzt ein Apfel-Birnen Vergleich.
Sicherheit entsteht, wenn das Knacken des Accounts teurer ist als der potentielle Gewinn, den man daraus ziehen kann. Das ist eine rein wirtschaftliche Betrachtung.
Welchen Gewinn kann man aus dem Knacken des Pentagons ziehen, und welchen aus einem Account bei dir?
Wie viele Millionen werden für die Sicherheit bei solchen Websites oder generell Netzwerken ausgegeben und wie viele "Kluge" Köpfe sind dort nur für die Sicherheit Zuständig und trotzdem passiert es.
Es gibt vielfältige Möglichkeiten, warum Systeme trotz Sicherheitsmaßnahmen geknackt werden. Meistens sind es Lücken in der Software, die bei angeblich sicheren Systemen dann doch zum Verhängnis werden. Eine vernünftige Passwort-Policy und die bestmögliche Speicherung als Hash ist jedenfalls bislang noch nicht für Einbrüche verantwortlich gemacht worden. Und genau darum geht es: Zu verhindern, dass durch offensichtliche Dummheit beim Programmieren ein Einbruch allzu leicht möglich wird.
Wenn du nicht die nach aktueller Erkenntnislage bestmöglichen Algorithmen einsetzen willst, dann fällt das nach meiner Meinung schon unter offensichtliche Dummheit. Es ist ein bewußtes Senken der Systemsicherheit, obwohl es vollkommen unnötig wäre, weil die bestmögliche Sicherheit keinerlei Extra-Aufwand verursacht.
Heute betrachtet man vielleicht bcrypt als "einzig gültige Speicherform" aber morgen kann das schon wieder anders sein.
Wie gesagt: Der Upgrade-Pfad für alle ab heute gehashten bcrypt-Werte existiert ja - und zwar transparent für den User, und mit minimalem Umsetzungsaufwand für dich als Programmierer. Es gibt wirklich keine Ausrede, das Bestverfügbare nicht einzusetzen.
Ich möchte nun einen Upload realisieren, wo die einzelnen User Dateien hochladen können die dann verschlüsselt auf dem Server abgespeichert werden.
Was willst du damit erreichen?
Wenn ein User die Datei hochlädt, und durch die Verschlüsselung niemand anderes drankommt, kann er sich den Upload im Prinzip auch sparen. Von Online-Backups hast du auch nicht gesprochen (da wäre so eine Einweg-Speicherung nachvollziehbar). Aber selbst dort würde ich meine Daten VORHER verschlüsseln - ich vertraue dir einfach nicht, dass du dein Versprechen korrekt umsetzt und garantiert nach aktuellen Erkenntnissen sichere Verschlüsselung benutzt.
Es geht mir in meinem Fall nicht um ein Backup sondern viel mehr darum, dass man auf die Daten immer zugreifen kann, egal wo man ist.
Das kann der User auch ohne Verschlüsselung auf dem Server.
Die Daten VORHER zu verschlüsseln, ist keine Lösung die ich einen "Laien" "antun" möchte.
Um was es mir auch geht ist folgendes. Wenn man unterwegs ist, hat man nicht immer die Möglichkeit die Daten lokal zu ver- bzw. entschlüsseln.
Das geht auch ohne Verschlüsselung auf dem Server.
Ich möchte aber nicht, dass der User jedes Mal wenn er eine Datei ansehen bzw. herunterladen möchte, das Passwort zum Entschlüsseln eingeben muss.
Warum muss der User regelmäßig die Datei im unverschlüsselten Zustand benutzen bzw. erreichen können?
Offenbar ist es gegenüber dem User irrelevant, ob die Datei verschlüsselt ist. Sie verhält sich ihm gegenüber unverschlüsselt. Warum ist Verschlüsselung trotzdem relevant?
Einfach aus Sicherheitsgründen!
Einfach Krypto auf ein Problem werfen macht es nicht sicher.
Gegen welches Szenario willst du dich absichern?
Und wie kann der User das nachprüfen?
Wenn ein User ohne weitere Maßnahmen eine Datei hochladen und jederzeit wieder herunterladen kann: Welchen Sinn hat dann eine serverseitige Verschlüsselung? Erkläre mir den, und wir können weiterdiskutieren, welche Maßnahmen sinnvoll sind. :)
Wenn ein Mensch ohne weitere Maßnahmen seine Haustür aufsperren und jederzeit wieder zusperren kann: Welchen Sinn hat dann das eigentliche Zusperren der Haustür?
Der Vergleich hinkt: Bei der Haustür hat der Mensch den Schlüssel in seiner eigenen Gewalt.
Bei deiner Frage geht es aber darum, dass der Mensch eben gerade keinen Schlüssel zur Tür hat, sondern immer von dir die Tür geöffnet bekommt, weil er sich ihr nähert und durchgehen will. Insofern ist das Vorhandensein der Tür irrelevant, er könnte auch ohne dein Dazutun durch einen einfachen Mauerdurchbruch gehen.
- Sven Rautenberg
-
Wenn ein User ohne weitere Maßnahmen eine Datei hochladen und jederzeit wieder herunterladen kann: Welchen Sinn hat dann eine serverseitige Verschlüsselung? Erkläre mir den, und wir können weiterdiskutieren, welche Maßnahmen sinnvoll sind. :)
Wenn ein Mensch ohne weitere Maßnahmen seine Haustür aufsperren und jederzeit wieder zusperren kann: Welchen Sinn hat dann das eigentliche Zusperren der Haustür?
Der Vergleich hinkt: Bei der Haustür hat der Mensch den Schlüssel in seiner eigenen Gewalt.
Bei deiner Frage geht es aber darum, dass der Mensch eben gerade keinen Schlüssel zur Tür hat, sondern immer von dir die Tür geöffnet bekommt, weil er sich ihr nähert und durchgehen will. Insofern ist das Vorhandensein der Tür irrelevant, er könnte auch ohne dein Dazutun durch einen einfachen Mauerdurchbruch gehen.
Ich habe mich da denke ich falsch ausgedrückt. Ja in dem Beispiel hat der User den Schlüssel "in der Hand". Ich habe das eher auf das Verschlüsseln selber bezogen.
Das der User vertrauen in mich haben muss, ist eine andere Sache. Es geht mir bei dem Projekt auch nicht um eine riesen User-Gruppe die ich nicht kenne.Der User hat doch mehr oder weniger auch "den Schlüssel in der Hand" weil er sich ja einloggen muss.
Zu der Frage gegen welches Szenario ich mich absichern möchte: ich möchte verhindern, dass im Falle eines unerlaubten Zugriffs, egal welcher Art, auf dem Server, die Dokumente dort "offen herumliegen".
MfG
Naps-
Moin!
Zu der Frage gegen welches Szenario ich mich absichern möchte: ich möchte verhindern, dass im Falle eines unerlaubten Zugriffs, egal welcher Art, auf dem Server, die Dokumente dort "offen herumliegen".
Welche Art von unerlaubtem Zugriff? Über welchen Weg? Von welchen Personen?
Im Moment befinden wir uns hinsichtlich der Definition noch im Bereich "Mach, dass nix böses passiert - egal was das sein könnte". Und pauschal hilft da Verschlüsselung nicht.
- Sven Rautenberg
-
Moin!
Zu der Frage gegen welches Szenario ich mich absichern möchte: ich möchte verhindern, dass im Falle eines unerlaubten Zugriffs, egal welcher Art, auf dem Server, die Dokumente dort "offen herumliegen".
Welche Art von unerlaubtem Zugriff? Über welchen Weg? Von welchen Personen?
z.B. wenn Jemand zugriff auf dem Webserver hat, weil er das FTP Passwort (aus einem mir unbekannten Grund) besitzt.
MfG
Naps-
Moin!
Moin!
Zu der Frage gegen welches Szenario ich mich absichern möchte: ich möchte verhindern, dass im Falle eines unerlaubten Zugriffs, egal welcher Art, auf dem Server, die Dokumente dort "offen herumliegen".
Welche Art von unerlaubtem Zugriff? Über welchen Weg? Von welchen Personen?
z.B. wenn Jemand zugriff auf dem Webserver hat, weil er das FTP Passwort (aus einem mir unbekannten Grund) besitzt.
Erste Frage: Warum ist FTP verfügbar? Zweite Frage: Warum ist es via Passwort möglich, auf den Server zu gelangen, und nicht mit SSH Public Key Authentifizierung.
Lösung: Kein FTP benutzen.
Das war ja einfach. :)
Ok, wenn jemand unautorisiert den Festplatteninhalt deines Servers in Erfahrung bringen kann, dann würde das ja bedeuten, dass er durch das Abgreifen sämtlicher Dateien dann nicht an das Passwort zum Entschlüsseln rankommen darf. Aber wie wolltest du das Passwort speichern? PHP-Sessions liegen auch auf der Festplatte als Datei. Dein ganzer Verschlüsselungscode liegt auf der Festplatte.
Selbst wenn derjenige aktiv die Dateien nicht entschlüsseln kann, so wäre das einfachste doch, die Login-Funktion zu manipulieren und Username und Passwort erreichbar irgendwohin zu speichern, damit er sich danach mit diesen Daten selbst anmelden kann.
Deine Argumente dagegen?
- Sven Rautenberg
-
Moin!
Moin!
Zu der Frage gegen welches Szenario ich mich absichern möchte: ich möchte verhindern, dass im Falle eines unerlaubten Zugriffs, egal welcher Art, auf dem Server, die Dokumente dort "offen herumliegen".
Welche Art von unerlaubtem Zugriff? Über welchen Weg? Von welchen Personen?
z.B. wenn Jemand zugriff auf dem Webserver hat, weil er das FTP Passwort (aus einem mir unbekannten Grund) besitzt.
Erste Frage: Warum ist FTP verfügbar? Zweite Frage: Warum ist es via Passwort möglich, auf den Server zu gelangen, und nicht mit SSH Public Key Authentifizierung.
Lösung: Kein FTP benutzen.
Das war ja einfach. :)
;)
Ok, wenn jemand unautorisiert den Festplatteninhalt deines Servers in Erfahrung bringen kann, dann würde das ja bedeuten, dass er durch das Abgreifen sämtlicher Dateien dann nicht an das Passwort zum Entschlüsseln rankommen darf. Aber wie wolltest du das Passwort speichern? PHP-Sessions liegen auch auf der Festplatte als Datei. Dein ganzer Verschlüsselungscode liegt auf der Festplatte.
Selbst wenn derjenige aktiv die Dateien nicht entschlüsseln kann, so wäre das einfachste doch, die Login-Funktion zu manipulieren und Username und Passwort erreichbar irgendwohin zu speichern, damit er sich danach mit diesen Daten selbst anmelden kann.
Deine Argumente dagegen?
Ich habe keine mehr! Das heißt die einzig "sichere" möglichkeit meine Sache umzusetzten ist, dass der User das Passwort zum entschlüsseln jedes mal eingibt.
Bzw. dass z.B. beim Loginvorgang alle Dokumente des Users entschlüsselt werden und das passwort nie zwischengespeichert wird. Ich weiß jetzt liegen kurzfristig die Daten unverschlüsselt am Server. Das könnte ich aber verkraften.
Die Problematik hier ist denke ich aber die Größe und Anzahl der Dokumente. Ab einer gewissen Menge ist das nicht mehr machbar, alles beim Login zu entschlüsseln.MFG
Naps
-
-
-
-
-
-
-
-