Diskussion: Erweiterter Schutz von Passwörtern in Contao

Mit diesem Thread möchte ich gerne zwei Fragen diskutieren:

1. Verhinderung der Übermittlung von Passwörtern im Klartext an den Browser.
2. Verschlüsseltes Speichern von Passwörtern in der Datenbank

Anstoß hierfür sind u.a. die Tickets #1733 und #1995 und einige Diskussionen hier im Forum.

Zu 1):
Bei den Feldern, die als 'hideInput' = true definert wurden, sind die Eingaben im HTML-Quelltext immer noch sichtbar (darauf weist Leo im Entwicklerhandbuch auch hin!), nur das "über die Schulter schauen" wird hiermit verhindert.
Das kann bei Passwörter-Feldern in seltenen Fällen unangenehme Folgen haben. Loggt sich der Benutzer z.B. bei einem Newsletterverteiler mit eingetragenem SMTP-Server nach dem speichern direkt aus, so könnte im Browser-cache die Seite und somit das Passwort noch enthalten sein. Auch wäre bei einem Hack der Seite (Gott behüte) das Passwort für einen Angreifer direkt auslesbar. Auch ohne Datenbank oder File-Access.

Eine mögliche Lösung wäre, dass beim rendern der Seite das Passwort nicht übermittelt wird. Damit aber auch ein Ändern zu einem leeren Feld möglich bleibt kann wie folgt vorgegangen werden:
Beim Aufbau der Seite wird der vorhandenen Feldinhalte durch eine fixe Zeichenfolge ersetzt (z.B. "***************"). Somit ist dann im value-Attribut des Input-Feldes nur diese Zeichenfolge ersichtlich.
Beim Speichern wird dann geprüft, ob irgendetwas anderes als genau diese Zeichenfolge gesendet wurde. Nur dann wird der neue Wert gespeichert. Wenn nicht, wird der ursprüngliche Wert nicht verändert.
Damit ist für den Anwender erkennbar, dass in dem Feld ein Wert vorhanden ist oder nicht und es kann der Inhalt gelöscht und geändert werden.
Nachteile:

• Die spezielle Zeichefolge (hier "***************") kann nicht mehr als gültiger Wert akzeptiert werden. Daher sollte er ggf. in der config.php definiert werden.
• Der Anwender könnte irrtümlich nur ein Zeichen ändern wollen und erhält dann was ganz anderes. (z.B. beim "ändern" des letzten Zeichens ein "**************A" als neues Passwort. Hier könnte aber vielleicht JS helfen.)

Ein solches Überschreiben könnte auch bei definiertem 'hideInput' = true aber 'doNotShow' = false genutzt werden.

Zu 2):
Da es kaum auszuschließen ist (auch wenn ich es mir wünsche und nichts gegenteiliges weiß), dass es eine Möglichkeit geben könnte, eine SQL-Injection zu realisieren, sollte für alle Passwörter die Möglichkeit existieren diese nur Verschlüsselt in der Datenbank abzugelegen.
Auch wenn der Core eine SQL-Injection sehr effektive verhindert, so ist man nie sicher, auch nicht mit Blick auf alle Extensions, das da alles 100% dicht ist. Wie gesagt, es geht um die Theorie.
Hierzu sind bereits die nötigen Funktionen im Core vorhanden und sollten für alle Passwort-Felder des Core aktivierbar sein.
Hierbei geht es nicht um die Passwörter der Benutzer und User, diese liegen als Hash vor. Auch rede ich explizit nicht von den Passwörtern in der localconfig.php (dort liegt ja auch der Schlüssel für die Verschlüsselung).

Hierzu müssten die Passwortfelder (z.B. tl_newsletter_channel.smtpPass) länger definiert werden. Im konkreten Fall von 32 auf 88 Byte, da zusätzlich zum Passwort noch ein Initialisierungsvektor gespeichert wird und das ganze Base64 codiert ist.
Weiterhin muss vor der Nutzung der Passwörter eine Entschlüsselung stattfinden. Beim Newsletter z.B. nur in der Newsletter::send nach dem Auslesen aus der Datenbank.

Damit es aber keine Probleme mit Servern gibt, die keine mcrypt-Unterstützung bieten, sollte die Verschlüsselung global ein- und ausschaltbar sein, oder aber die class Encryption soll sich transparent verhalten, falls mcrypt fehlt (also nicht ver- und entschlüsseln)

Was meint Ihr dazu?

Es ist ja immer noch die Frage, wo die eigentliche Baustelle ist: Zum Beispiel http://bit.ly/cdEr3Y

Carolina.

Autsch, es ist schon erschreckend wie doch immer wieder Leute Tricks finden, Daten abzugreifen.
Daher hatte ich ja auch diese Diskussion gestartet, um präventiv das Abgreifen von smtp oder ftp-Passwörtern zumindest weiter zu erschweren.

Beide vorgeschlagene Änderungen sind nicht notwendig, solange keine Lücken gefunden werden, was ich doch hoffe.
Sollte jedoch ein unberechtigter Login im Backend möglich werden, oder "alte" Daten einer vorherigen Session abgerufen werden können, dann würde ich mich über diese zusätzlichen Hürden freuen.
Wie schon im Ticket #1733 beschrieben, ist natürlich alle Mühe einer Verschlüsselung umsonst, sobald die localconfig.php direkt ausgelesen werden kann. Ich hoffe jedoch, dass ein file-Zugriff auf den Server die größte Hürde darstellt.

Selber bin ich schon mal beim einrichten meines WLAN beim Router vom Nachbarn gelandet und konnte dort aus den Passwort-Feldern seine kompletten Zugangsdaten auslesen. Anschließend hatte ich ihm geholfen seinen Router sicher zu machen und die Zugangsdaten zu ändern. Das Hauptproblem war jedoch die mangelnde Kenntnis des Nachbarn, was durch die unverschlüsselten Daten in den Passwort-Feldern noch potenziert wurde.

Ich selbst sehe den Core von Cantao als sehr gut und überlegt entwickelt an, jedoch möchte ich das nicht für alle Extensions so ungeprüft auch aussprechen. Ich habe mir bisher nur wenige angesehen und habe dort nichts schlechtes gesehen.

Also zurück zur Kernfrage.
Soll das übermitteln der Werte bei Passwört-Feldern lieber nicht erfolgen und sollte für Passwortfelder die Verschlüsselung in der Datenbank optional eingeplant werden? Wie siehts aus?

Nachfolgend ein Beispiel, wie ich mir den besseren Schutz der Passwörter vorstelle.

Das angefügte Archiv enthält eine Erweiterung, welche verhindert, dass die SMTP Passwörter aus den Einstellungen und aus dem Newsletter Channel an den Browser übertragen wird. Zudem wird auch das FTP-Passwort der Erweiterung BackupDBPlus berücksichtigt.
Die Variante mittels Erweiterung funktioniert zwar, ich würde mir dieses Verhalten jedoch bei allen Eingabe-Feldern vom Typ Passwort wünschen. Dann müsste nicht für jedes eine neue Behandlung hinzugefügt werden.

Zum verschlüsselten Speichern der Passwörter in der Datenbank (nicht relevant für das globale SMTP-Passwort, da dieses in der localconfig.php steht) kann in der Erweiterung im Verzeichnis dca, Datei tl_newsletter_channel die Zeile 44 auskommentiert werden.

Damit das ganze dann auch funktioniert muss noch in der Datei Newsletter.php des original Newsletter-Moduls folgendes in die Funktion send hinzugefügt werden.

PHP-Code:

---

   // Overwrite the SMTP configuration
   if ($objNewsletter->useSMTP)
   {
     if (isset($GLOBALS['TL_DCA']['tl_newsletter_channel']['fields']['smtpPass']['eval']['encrypt']) &&
         $GLOBALS['TL_DCA']['tl_newsletter_channel']['fields']['smtpPass']['eval']['encrypt'])
     {
       $objEncrypt = Encryption::getInstance();
       $objNewsletter->smtpPass = $objEncrypt->decrypt($objNewsletter->smtpPass);
     }
     $GLOBALS['TL_CONFIG']['useSMTP'] = true; 


---

(Die ersten drei, sowie die letzte Zeile sind zur Orientierung übernommen)

Weiterhin kann die Encryption transparent werden, falls kein mcrypt auf dem Server exisitiert, wenn folgende Zeilen in der Encryption.php ergänzt werden:

PHP-Code:

---

  protected function __construct()
  {
    if (!function_exists('mcrypt_module_open'))
    {
      $this->EncryptionEnabled = false;
      return;
    }
    $this->EncryptionEnabled = true;
 
[...]    
 
  public function encrypt($strValue)
  {
    if (!$this->EncryptionEnabled) return $strValue;
 
[...] 
 
  public function decrypt($strValue)
  {
    if (!$this->EncryptionEnabled) return $strValue; 


---

(Die drei Funktionen existieren schon, es geht nur um die ersten Zeilen danach)
Ergo, wenn kein mcrypt vorhanden, dann wird bei encrypt und decrypt nichts verändert.

Vielleicht kommt jetzt nach Pfingsten noch ein paar mehr Meinungen zusammen?

Die Erweiterung hat mittlerweile den Status release candidate 1 erreicht.

Folgende Funktionalitäten sind in Version 0.9.0 enthalten:
- Verstecken eines Passwortes im HTML-Quelltext bei TEXT-Eingabefeldern mit eval-Attribut hideInput
- Berücksichtigung von Verschlüsselter Speicherung (eval-Attribut encrypt)
- JavaScript zum vermeiden von "falschen" Änderungen.
- Konfigurierbarkeit des Platzhalters in den Einstellungen von Contao

Hallo weke,

es wäre fein, wenn Du die obengenannten neuen Funktionalitäten auch im ER unter "Freigabe-Notizen und Änderungs-Log" ersichtlich machen könntest.

Danke xchs, wurde nachgetragen!

Super, fein! So hat man nämlich einen Überblick, was sich zwischen den einzelnen Versionen geändert hat bzw. welche Funktionen neu implementiert wurden.