SMTP Passwort wird nicht verschlüsselt abgelegt

[kitatu]

Hallo,

ich habe soeben festgestellt dass das SMTP-Passwort für den Emailversand nicht in der Datenbank in der Tabelle "configuration" unter "configuration_value" verschlüsselt abgelegt wird, sondern in Klartext. Gibt es hierfür einen Fix, Workaround, Zusatzmodul oder irgendwas ähnliches welches dieses Sicherheitsproblem behebt? Leider sind meine Programmierkenntnisse hierzu zu beschränkt um selber eine Lösung bereitstellen zu können.

Im Zuge der gegenwärtigen Diskussion um Sicherheit im IT-Bereich (und ich glaube die Sicherheit kann nicht hoch genug geschraubt werden), halte ich dies für grob-fahrlässig.

Sollte es hierzu schon Diskussionen geben, bitte ich um Info wo man sich über die Behebung dieses Problems informieren kann. Hab leider dazu nichts gefunden.

Schöne Grüße

Linkback: https://www.modified-shop.org/forum/index.php?topic=28837.0

[ShopNix]

Grob fahrlässig ist ein hartes Wort, und niemand (der auf einem vernünftigen Server arbeitet) muß ein smtp-Passwort vergeben.

[web28]

Da das SMTP Passwort an den SMTP Server übertragen werden muss ist es nicht möglich das Passwort verschlüsselt in der Datenbank zu speichen, jedenfalls nicht bei einem OpenSource Projekt, der Ent/Verschlüsselungs Algorythmus wäre ja bekannt.

An die Datenbank kommt auch niemand unbefugtes heran, und falls doch, ist das SMTP Passwort das geringste Problem.

[ShopNix]

Das Datenbank-Passwort liegt übrigens auch im Klartext auf dem Server. Geht auch nicht anders.

[webald]

Da das SMTP Passwort an den SMTP Server übertragen werden muss ist es nicht möglich das Passwort verschlüsselt in der Datenbank zu speichen, jedenfalls nicht bei einem OpenSource Projekt, der Ent/Verschlüsselungs Algorythmus wäre ja bekannt.

Man könnte es wie bei der Speicherung der Kreditkarten lösen. Hierzu wird ja auch eine Verschlüsselung in der Db benutzt.

Ich würdenaber ehernvorschlagen den SMTP-Server besser zu schützen. Man benutzt für den Shop eigene Mailadresen und lässt für diese Mailadressen nur Verbindungen vom Webserver zu, einem aussenstehenden nutzt dann auch das paswort nix, da ervom falschen Rechner zugreift.

[wolkenkrieger]

Grob fahrlässig ist ein hartes Wort, und niemand (der auf einem vernünftigen Server arbeitet) muß ein smtp-Passwort vergeben.

Auweia!

[fishnet]

@wolkenkrieger, deine Antwort auf Posting #2 hätte mich jetzt interessiert 

[kitatu]

@ShopNix
Aber du kennst schon die E-Mail-Konfigurationsseite im Shop?
Dort wird explizit nach dem SMTP-Kennwort gefragt. Diese wird in der Datenbank abgelegt.

Das Kennwort ließe sich durchaus in der Datenbank verschlüsselt ablegen. Mit dem Script der den Versand der Software anschließend initiiert, können die Daten ausgelesen und "on-the-fly" entschlüsselt und an Sendmail übergeben werden. Die Verschlüsselung könnte evtl. mit einem öffentlichen Schlüssel  vom Hoster erfolgen.

Deswegen bleibe ich dabei - grob-fahrlässig, zumal es immer wieder dazu kommt, dass Datenbanken geknackt und ausgelesen werden.

[ShopNix]

Aber du kennst schon die E-Mail-Konfigurationsseite im Shop?
Dort wird explizit nach dem SMTP-Kennwort gefragt. Diese wird in der Datenbank abgelegt.

Natürlich kenne ich die Seite. Du musst aber auf einem ordentlich konfigurierten System nicht mit smtp arbeiten. Dann musst Du auch das Kennwort nicht eingeben. Gibst Du es trotzdem ein, handelst Du "grob fahrlässig"

Das Kennwort ließe sich durchaus in der Datenbank verschlüsselt ablegen. Mit dem Script der den Versand der Software anschließend initiiert, können die Daten ausgelesen und "on-the-fly" entschlüsselt und an Sendmail übergeben werden. Die Verschlüsselung könnte evtl. mit einem eigenen privaten Schlüssel erfolgen.

Bedeutet unterm Strich, dass Du dem verschlüsselten Kennwort die Entschlüsselung beilegst. Du schließt das Dingen somit im Safe ein und lässt den Schlüssel des Safes stecken. "Grob fahrlässig"

Deswegen bleibe ich dabei - grob-fahrlässig, zumal es immer wieder dazu kommt, dass Datenbanken geknackt und ausgelesen werden.

Na und wenn? Dann kann der böse Cracker ein paar Mails über Deinen Account verschicken. Das sind in diesem Worst Case nun wirklich Peanuts in Relation zum Gesamtschaden.

Das alles hat Dir web28 weiter oben schon gesagt, also sei nicht bockig und seh's ein.

[baalze]

Ich denke diese SMTP-Klartextpasswörter machen die Geschichte jetzt erst einmal nicht unsicher.
Man könnte sich allerdings überlegen generell sensible Daten nicht als Klartext abzuspeichern.
Insbesondere Daten, welche nicht wieder entschlüsselt werden müssen, sollten vernünftig verschlüsselt werden; beispielsweise Loginpasswörter, MD5 ~ Klartext.
Falls eine Entschlüsselung erforderlich ist, so sollte Key und Cipher nicht an gleicher Stelle (z.B. config <> DB) abgelegt werden wie ShopNix vorgeschlagen hat.

[wolkenkrieger]

@wolkenkrieger, deine Antwort auf Posting #2 hätte mich jetzt interessiert 

Naja, ganz einfach (in meiner Denke zumindest^^): sichere Systeme haben eine physische (zumindest aber eine deutlich logische) Trennung nach Aufgaben (DB, Web, Mail, ...), um eine Kettenreaktion bei einer Kompromittierung zu verhindern oder sie zumindest so schwer bzw. unwahrscheinlich wie möglich zu machen.

Ich geh mal davon aus, dass er die mail()-Funktion als solches meint. Der User, unter dessen Account also der Webserver läuft, bekommt erzwungener Maßen Zugriff auf einen betriebssystemnahen Befehl (popen). Damit steht ein Tor offen für Angriffe. Idealerweise konfiguriert man einen Webserver ja so, dass der Apache (oder eben ein anderer entsprechender Dienst) in einem maximal eingeschränkten Account läuft, der eben nur die für den reinen Webserverbetrieb essentiell notwendige Berechtigungen hat. Idealerweise beinhalten die eben keinerlei Zugriffsmöglichkeiten auf OS-nahe Komponenten (popen, exec, system, etc. sind "abgeklemmt").

Kommuniziert der Mailserver aber via SMTP mit einem Mailserver, muss ein eventueller Angreifer entweder beide Server oder aber zumindest die Kommunikation zwischen ihnen angreifen (MITM), was bei einem gut konfigurierten Mailserver wegen SSL und diversen anderen Sicherheitsmechanismen ausgesprochen schwer bis nahezu unmöglich ist.

Ich habe mal gelernt: wenn du Hürden einbauen kannst, bau sie ein. So hoch wie du kannst und so oft wie du kannst. Sicherheit geht vor Performance und Bequemlichkeit.

Die Plaintext-Ablage eines SMTP-Passwortes macht meine Argumentation natürlich lächerlich - ist mir klar. Aber auch dafür gibt es praktikable Lösungen. Zumal damit lediglich der reine Mailversand über ein einziges Konto in Gefahr gerät - nicht aber der Mailserver als solches.

Oder liege ich da falsch?

Einschränkung (nach Absprache mit meinem Serverspezi): systemnahe Zugriffe sind dann zulässig (also aus Sicherheitssicht), wenn dahinter auf OS-Ebene entsprechende Überwachungen (Prozessüberwachung zum Beispiel oder accountgebundene Kommando-Aliase) aktiv und ausreichend sorgfältig eingerichtet sind.

Das dürfte aber bei den wenigsten von uns mangels vollständigem Zugriff auf den Server (oder Kenntnissen, wie bei mir *lol*) möglich sein.

[ddlab]

Jeder kann mit wenigen Handgriffen selbst Verschlüsselungen einbauen, wenn er meint daß dies wichtig wäre.
Ich benutze seit langem AES256, rein für php oder auch für Übertragungen zum Client, für das es kompatible js- und php-Klassen gibt.
Ich gehe mal davon aus daß jeder Webadmin eines shops (also nicht unbedingt der Inhaber selbst) FTP-Zugang hat und daß er weiß wie man Verzeichnisse per .htaccess vor http-Zugriffen schützt. Das würde an dieser Stelle zu weit führen.
In ein derart geschütztes Verzeichnis, im folgenden Beispiel "crypt", (auf das der Server selbst natürlich zugreifen kann) kommt eine Datei, die ich "token.php" nenne, und am besten in das gleiche Verzeichnis die AES-Klasse (nicht aus Sicherheitsgründen dort hinein, nur weil sie woanders nicht gebraucht wird). Dann habe ich eine eigene Klasse, die sich darum kümmert. Und das sieht dann (stark vereinfacht) so aus:

include_once '../crypt/token.php';
include_once '../crypt/aes.class.phps';

class ddlab_crypt{
   function encr($value) {
   global $token;
      return base64_encode(AES::encrypt($value, $token, 256));
   }
   function decr($value) {
   global $token;
      return AES::decrypt(base64_decode($value),$token, 256);
   }
}

Im Falles des smtp-Passwortes bräuchte man sich nur die Stellen in den scripts heraussuchen, in denen das Passwort in die db geschrieben und wieder ausgelesen wird.

vor dem Screiben in die db: $ddlab->crypt->encr('vergebenes SMTP pw')
zum Verwenden: $ddlab->crypt->decr('gespeichertes SMTP pw')
(Klassennamen entsprechend selbst anpassen)

Das funktioniert dann natürlich auch für alle anderen sensiblen Werte, wie Bankverbindungen, Emailadressen etc. etc.
Ich verwende dies schon länger in Intranet-Anwendungen, bei denen echt eine Menge sensibler Daten geschubst werden und Auftraggeber z.T. besondere Sicherheitsmaßnahmen wünschen.

(bezüglich modified bin ich totaler Anfänger)

Das hat bei allen Betrachtungen zur Sicherheit natürlich nur insoweit Sinn, wenn ein Angreifer nur die Datenbank entert, nicht aber auch das Dateisystem. Dann ist eh alles zu spät.

[wolkenkrieger]

Das ist gar nicht mal so doof

[ddlab]

"garnicht mal so doof" Ja weiß ich.

Hatte vergessen:
Die token.php enthält nichts wie eine Variable $token='js34hHj78...HJtmh56hh9'; mit insgesamt 64 Zeichen.
Bei der Verwendung von 0-9, a-z und A-Z kann eine Stelle des Schlüssels 62 Möglichkeiten annehmen, somit kann der ganze Schlüssel 64^62 verschiedene Kombinationen haben.

[ddlab]

Noch ne Anmerkung: Der Token steht deshalb nicht in der Klasse selbst (wo er eigentlich auch recht gut placiert wäre), weil beim Setup eines Systems i.d.R. ein neuer Token erstellt wird, der scriptgesteuert z.T. auf mehrere Server verteilt werden muß (wie in meinem Falle bei den Intranet-Anwendungen örtlich getrennter Firmen).