Erweiterung der Regeln für gültige Passwörter

[fiedsch]

Hallo zusammen,

ich muß für ein Projekt die Vergabe eines neuen Passworts an ein Member erweitern.

Wenn ich das korrekt nachgelesen habe, wird in modules/registration/ModulePassword.php "nur" die Längenvorgabe für ein neues Passwort geprüft.

Ich benötige hier aber noch weitere Prüfungen bzgl. Passwort-Komplexität, die bei Scheitern auch dem User kommuniziert werden müssen.

Ich habe mich gestern etwas duch die beteiligten Module gelesen und hätte gerne eure Meinung/Einschätzung zu meinem Ansatz (vielleicht denke ich ja auch zu kompliziert):

Um möglichst updatesicher zu sein, erstelle ich ein eigenes Modul, das ich unter

$GLOBALS['FE_MOD']['user']['lostPassword'] = 'MyExtendedModulePassword'; 

registriere. Über einer Erweiterung der Datenbank erstelle ich neue Felder wie z.B. eines in tl_member, das
speichert, wann das Passwort zuletzt geändert wurde. Außerdem lege ich eine neue Tabelle mit der
Passworthistorie an

id | userid | altes_pwd

mit der ich ggf. prüfen kann, ob ein neues Passwort gültig ist, weil von diesem User noch nicht (oder "schon länger nicht") vergeben wurde.

Das oben registrierte MyExtendedModulePassword.php sieht dann in etwas so aus.

class MyExtendedModulePassword extends ModulePassword {

        /**
     * Set the new password
     */
    protected function setNewPassword()     {
 
           // hier bestehenden Code dupliziert und eigene Erweiterungen eingetragen
           // nicht elegant :-(

        }

} 

Alternative: die bestehende ModulePassword.php patchen und einen Hook einbauen (habe ich im Hook überhaupt Zugriff auf den User und das $this um Templatevariablen zu setzen und ggf. das Template zu wechseln?).

Der vorgesehene Hook aus $GLOBALS['TL_HOOKS']['setNewPassword'] hilft mir leider nicht weiter (?), da an dieser Stelle das neue Passwort ja bereits gesetzt ist.

Für die Ausgabe einer Meldung an den User, der ein neues Passwort vergeben will fällt mir (alternativ) ein, ein eigenes Widget in Anlehnung an system/modules/FormPassword.php zu implementieren. In dessen

protected function validator($varInput) { } 

könnten der Verifikationscode und die Meldungen an den User untergebracht werden.

Dieses Widget wäre dann unter

$GLOBALS['TL_FFL']['password'] 

zu registrieren? Das neue Widget hätte durch

Widget extends Controller extends System 

auch die Möglichkeit auf den User zuzugreifen und in die Datenbank zu schreiben?


Danke für eure Meinungen!

[xchs]

Im ER gibt es dazu auch eine Erweiterung. Den Namen weiß ich jetzt spontan leider nicht auswendig und ist mir momentan am Handy auch grad zu mühsam, danach zu suchen. Ist aber bestimmt schnell gefunden.

[jan.theofel]

Hi,

du suchst securepasswords.

Jan

[fiedsch]

Hallo xchs,

Im ER gibt es dazu auch eine Erweiterung.

Danke für den Tip! Das hatte ich gar nicht zu hoffen gewagt :-) Ich habe dort "securepasswords" gefunden und werde mir gleich mal anschauen, wie das arbeitet -- man will ja dazu lernen.

@Jan: Danke. Unsere Posts haben sich zeitlich überschnitten. Ich habe es mir jetzt angeschaut und es bleibt "nur" noch die Passworthistorie zu implementieren. Mit der Basis von securepasswords sollte das aber leicht gehen.

Andreas

[jan.theofel]

Hi Andreas,

und das kannst du dann ja Andreas Schempp (dem Autor) als Patch senden, damit er das in die offizielle Version mit aufnehmen kann. ;-)

Jan

[Thomas]

ROFL

Sorry, den musste ich raus lassen.
Das geht wirklich gegen alle Sicherheitsregeln. Davon mal ganz abgesehen, dass ich das Datenschutz rechtlich sehr bedenklich finde, Passwörter in einer Historie zu packen.
Darauf warten böse, böse Buben nur. ^^

Was ich mir vorstellen könnte ist, dass man nicht das zuletzt Genutzte im Neuen Passwort wieder verwenden kann. Das wäre vielleicht ein generelles Feature für Contao, was ich bei reiflicher Überlegung dann doch vermisse.

[fiedsch]

Nur so als Information: Leute die eine Passworthistorie verwenden haben grundlegende Sicherheitskonzepte nicht verstanden. 90% aller User verwenden 3 Passwörter die immer Rotieren.

@leo: Da stimme ich Dir vollkommen zu. Es gibt aber leider Situationen in denen Argumente versagen. Wenn Du deinem Kunden sagen kannst, daß er einfach zu blöd ist, dann ist das schön, hilft mir aber leider nicht: Die Password-Policy ist in Stein gemeißelt und steht an dieser Stelle nicht zur Diskussion :-(

Wenn es nach mir geht, ist etwas wie vorgeschlagene Extension securepasswords schon "schlecht", da sie damit erzwungenen Passwörter nur zu vielen gelben Zetteln am Monitor führen.

@Thomas: die Historie soll natürlich genauso gehasht abgelegt werden wie das aktuelle Passwort.

Sei es, wie es sei, es muß umgesetzt werden. Was ich dabei erreichen will, ist nur, daß es mit einem sauberen Ansatz gemacht wird, der zum einen Pflegeleicht ist (updatesicher) und zum zweiten evtl. auch von jemand anderes genutzt werden kann, der vor dem gleichen Problem steht.

Mit der vorgeschlagenen Erweiterung securepasswords bin ich nun so weit, daß ich zusätzlich via $GLOBALS['TL_HOOKS']['setNewPassword'][] das neue Passwort in einer eigenen Tabelle für die Historie ablege.

Die Funktion SecurePasswords::validatePassword($strRegexp, $varValue, Widget $objWidget) würde ich erweitern. Dabei habe ich aber noch zwei konzeptionelle Probleme:

(1) Ich generiere ein neues gehashtes Passwort aus dem plain Passwort in $varValue. Da ich aber nicht weiß, was bei der ursprünglichen Generierung eines alten Passworts als Salt verwendet wurde
werde ich nicht das gleich Ergebnis bekommen und damit auch nicht prüfen können, ob es vom User bereits vergeben wurde.

Momentane Idee dazu: alle Kandidaten aus der Historie holen und den Salt extrahieren. Mit allen Salt-Kandidaten das Passwort hashen und dann schauen, ob es unter den in der Historie abgelegten Passwörten vorkommt.

Also in etwa so:

      $this->import('Database');

      $objOldPaswords = $this->Database->prepare("SELECT * FROM tl_member_recent_passwords WHERE pid=? LIMIT ?")->execute($user_id, $GLOBALS['TL_CONFIG']['pw_recent_blocked']);

          $arrSalts = array();

          $oldPasswords = array();

      while ($objOldPaswords->next()) {

           // extrahiere $salt aus $objOldPaswords->password;

            $arrSalts[] = $salt;

           $oldPasswords[] = $objOldPaswords->password;
         }

        foreach ($arrSalts as $salt) {

         $hashedPassword = sha1($salt . $varValue) . ':' . $salt; // $varValue ist das Plain-Text-Password aus validatePassword($strRegexp, $varValue, Widget $objWidget)

        // und dann prüfen, ob $hashedPassword in $oldPasswords enthalten ist

       } 

Dann kommt aber leider das grundlegene Problem Nummer zwei: Bis hierher ist noch kein User angemeldet, wir haben also auch keine User-ID, die wir in obigem SELECT verwenden könnten

Idee hierzu: Im PostLogin-Hook das Passwort als ungültig markieren und den User davon in Kenntnis setzen. Hätte den Nebeneffekt, daß wir so eine einmalige Ausnahme machen könnten (außer wir loggen den User in PostLogin auch gleich wieder aus).

Das würde zwar funktionieren, bleibt aber unbefriedigend, da die "Fehlermeldungen" nun an verschiedene Stellen kommen würden.

Nachdem der Verweis auf securepasswords schon der Bringer war, habe ich nochmal Hoffung auf einen Tip.

Besten Dank für eueren Input,
Andreas

[fiedsch]

Vielleicht noch ein Wort zu der "sicheren Speicherung der Passwörter". Das ist defakto nur mit richtigen crypts möglich und das ist in Contao schwer, da in der localconfig.php alles drin steht um es auch wieder zu entcrypten.

Das halte ich für falsch. Ein Mitgliederpasword wir mit sha1() gehasht in der Datenbank abgelegt. Das ist nicht reversibel.

Ich meine mit "verschlüsselt abspecihern" nicht Contaos Mechanismus, einzelne Date verschlüsselt (und natürlich auch wieder entschlüsselbar) abzuspechern (-> encryption-key in der localconfig), sondern genau so, wie Contao das aktuelle Passwort in der tl_member ablegt.

[fiedsch]

Google mal bitte "rainbow tables"

... und finde auch "salzen".

Und mit "halte ich für falsch" hatte ich mich auf

da in der localconfig.php alles drin steht um es auch wieder zu entcrypten.

bezogen.

[isa]

Hallo,
habe diesen Thread gelesen. Das hier ist im Prinzip genau mein Problem. Habe Contao 3.0.6 im Einsatz und benötige eine Erweiterung oder Anleitung für Passwortvorgaben. Die Erweiterung SecurePassword funktioniert unter meiner Installation nicht. Konntest du deine Anforderung lösen und hast einen Tipp für mich?
Vielen Dank! Isa

[fiedsch]

nein, die Anforderung ist zwischenzeitlich zum Glück entfallen, so daß ich das dann nicht weiter verfolgt habe.

"Zum Glück", da ich solche Restriktionen für falsch halte. Das führt nur zu Postit-Zetteln am Monitor oder noch schwächeren Passwörtern ...

[mvo]

Aber mal trotzdem hypothetisch: Tuts zum Zweck der Passworthistorie nicht einfach ein (uneindeutigerer) einfacher Checksum der wie-auch-immer-gespeicherten Passwörter? Oder schlichtweg die Hälfte des Keys. Will meinen: Man muss ja nicht den ganzen Key speichern - mit dem geringen Risiko, dass ein Passwort fälschlicherweise abgelehnt wird, aber mit der Sicherheit, dass die Daten (selbst wenn die Verschlüsselung mal irgendwann in sinnvoller Zeit knackbar sein sollte) nicht das Passwort verraten.

Passwortpolitik ist leider immer kein schönes Spiel. Irgendwo zwischen dem 5-Zeichen-Wörterbuch-Passwort für alle Anwendungen und dem täglich wechselnden 15-Zeichen-Code, den sich keiner mehr merken kann. Was eine Historie angeht: Ich könnte wetten, die meisten User hängen dann einfach eine Zahl oder Sonstiges an das alte Passwort (das man sich merken kann) an. Will man das verhindern, dann muss man nach Ähnlichkeiten zu alten Passwörtern suchen (wie es mancherorts gemacht wird), was dann aber wirklich jegliche Form der Sicherheit aushebelt.

[isa]

Aber wie realisiert ihr unabhängig von einer Passworthistorie und dem Verschlüsselungsproblem eine Steigerung der Passwortkomplexität? Es sollen so wie bei SecurePassword einfach Vorgaben gemacht werden, die bei der Passwortwahl einzuhalten sind und entsprechend bei der Vergabe geprüft werden müssen. Wie steuert ihr die Einhaltung der Mindestanforderungen an Passwörter?

[fiedsch]

SecurePassword. Habe es aber noch nicht mit Contao 3.x probiert. Was funktioniert denn bei Dir nicht?

[isa]

SecurePassword. Habe es aber noch nicht mit Contao 3.x probiert. Was funktioniert denn bei Dir nicht?

Die Installation der Erweiterung ist erfolgreich, die Auswahl der Vorgaben unter Einstellungen funktioniert. Wenn ich dann im Benutzer das Passwort neu vergebe und abspeichern möchte, verschwindet der Seiteninhalt und eine weiße Seite wird mir angezeigt.

[xchs]

Aktiviere in den Einstellungen die Ausgabe der Fehlermeldungen.