Hallo,
bin nicht sicher, ob das nen Bug oder Feature ist, aber wäre es nicht sinnvoll das SMTP Passwort in der Datenbank (oxshops > OXSMTPPWD) zu verschlüsseln, statt es im Klartext anzuzeigen?
Gruß
sinnvoll schon, aber der Shop braucht das Passwort beim Verschicken jeder Email, also schränkt das die Möglichkeiten der Verschlüsselung auf 1-2 wenige ein, die aber durch ihre Beschaffenheit absolut keinen Vorteil für die Sicherheit bringen würden, somit würde es nur mehr CPU Power fressen und sonst nix bringen.
Übrigens, die Zugangsdaten für Payment Module liegen ebenfalls alle unverschlüsselt in der Datenbank 
1 Like
Danke für die schnelle Antwort!
Ausgehend von der Aussage zu den Payment Modulen scheint es also normal zu sein kritische Passwörter wie dieses nicht zu verschlüsseln. Ich bin sehr überrascht. Und nun auch im Zwiespalt hinsichtlich des Datenschutzes.
Ja selbst wenn das Passwort verschlüsselt wäre, muss es ja von irgendeinem Service entschlüsselt werden. Also würde ein “böser” Mensch halt das verschlüsselte Passwort kopieren und an den Dienst übermitteln. Also nix gewonnen.
Liegt der Entschlüssellungsdienst in Oxid, nutzt der “böse” Mensch halt den, um das Passwort zu entschlüsseln.
Eine Möglichkeit wäre es natürlich, Passwörter auf Apache-Ebene als Environment-Variable zu hinterlegen, aber erstens, wer kann das? Und zweitens liegen die Daten dann ja wieder offen rum, nur halt wo anders.
Das Sicherste wäre nun also, der Dienst selbst erlaubt über das Passwort / Token / Entrypoint nur eine IP - Der Dienst muss also sicherer werden. Mindestens aber, brauchst du ein einmaliges kryptisches Passwort und oder Token, idealerweise sogar rotierend. Alles andere ist fahrlässig und geht Oxid nichts an.
Datenschutz hat an dieser Stelle auch wenig mit Passwörtern zu tun, die legst du ja selbst für dich alleine fest. EDIT außer natürlich ein Kunde trägt ein Klartextpasswort in die Datenbank ein, um “eingeloggt” zu bleiben - aber hier wieder das Selbe. Wie soll es sicher vor “uns” Betreibern gesichert werden, würden wir es verschlüsseln, müsste auch der Dienst in der Lage sein dass zu entschlüsseln und wir, oder “böse” Menschen könnten das Verschlüsselte wieder an den Dienst senden. Für die DSGVO wäre an der Stelle wohl ein Hinweis von Nöten.
2 Likes
Indirekt: mit einem einfachen Blick in die Datenbank (leicht übertrieben) kann man Zugriff auf die E-Mail Adresse erhalten über die alle Kundenbestellungen laufen. Bin kein Datenschutzbeauftragter, aber sensibilisiert und verunsichert von dem ganzen Gewese um die DSGVO.
Wenn es üblich ist sowas in Klartext zu speichern und das sowieso alle(Shophersteller) so machen, dann wird es da in Hinsicht auf Datenschutz bestimmt auch keinen Ansatzpunkt geben an dem wir, als Shop-Betreiber, uns strafbar, bzw. haftbar machen.
Absolute Sicherheit gibt es meiner Meinung nach sowieso nicht, aber es grenzt dann bei Klartext PWs auch schon mal an Fahrlässigkeit. Man muss es ja nicht ZU einfach machen 
Die DSGVO sieht vor, dass Betreiber sicher stellen oder sicher stellen lassen, dass der Server sicher ist. Wer fahrlässig mit seinen Daten umgeht (Zu einfaches Passwort, zu oft auf anderen Plattformen verwendet, zu offen gespeichert, Serversoftware nicht sicher/aktuell, Virenbefall auf dem Remoterechner) kann belangt werden. Durch einen Auftragsverarbeitungsvertrag beispielsweise und einer angemessenen eigenen “Absicherung” wird ein großer Teil der Verantwortung auch an den Hoster/Provider übertragen. Allerdings können die natürlich nichts für den Zustand der Maschine, auf der Betreiber seine Passwörter speichert oder mit der er sich auf den Server verbindet.
Die DSGVO hat also so gesehen schon ein paar Punkte zum Thema “Klartextpasswörter”.
1 Like
ganz ungesichert sind die Klartext-Passwörter nicht, man muss ja immer noch in die DB rein, um an sie zu kommen.
Wobei das PW für die Datenbank ja auch im Klartext in der config Datei liegt, keine Ahnung, wie das von Datenschützern gewertet wird. Aber wenn man das PW für die DB hat, kann man auch gleich an die Kundendaten ran und da ist das SMTP PW auch egal.
1 Like
Guter Punkt, ich werde dazu mal unseren Datenschutzbeauftragten nerv- konsultieren. 
Danke für Euren Input!
Wobei man sich fragen muss, warum config settings in der DB verschlüsselt sind, und der key dafür ist für alle zugänglich im Source. Sinn macht das auch nicht.
Gruss
Marcel
1 Like
Das macht sehr wohl Sinn, wenn man z.B. nur aufgrund von Injections Zugriff auf die Datenbank bekommt aber keinen Zugriff auf das Dateisystem hat.
Und das versenden von E-Mails ist auch keine zeitkritische Anwendung, wenn es hier im schlimmsten Fall 100ms länger dauert dürfte das niemanden wirklich stören. Das selbe gilt für die Zahlungsmodule.
1 Like
Das ist noch ein anderes Thema (historisch gewachsen), steht aber auch schon länger auf der Agenda.
Rückmeldung nach Konsolidierung unseres Datenschutzbeauftragten:
Am besten sei es, wenn alle personenbezogenen Daten in der Datenbank verschlüsselt sind.
Um DS-GVO sicher zu sein werden außerdem 14 Punkte empfohlen von denen, meines Wissenstandes nach, nur drei in OXID angewendet werden. Drei von den restlichen Punkten liegen außerhalb des Einflussbereiches von OXID selbst, um diese muss sich der jeweilige Betreiber kümmern.
Orientierungshilfe: Anforderungen an Anbieter von Online-Diensten zur Zugangssicherung
Diese Infos seien nun einfach mal dahingestellt. Ich bin selbst etwas überfordert damit und weiß nicht so recht wie ich damit umgehen soll (und ob ich die Punkte überhaupt richtig zu OXID zugeordnet habe).
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.