[mano]

Hallo,
bei der Vergabe eines neuen Passworts wird dieses automatisch auf Sicherheit geprüft und mittels einer Ajax Abfrage an ein PHP Scirpt gesendet.

  function sendRequest() {
 var param = document.getElementById('user_password').name + '=' + document.getElementById('user_password').value;
   XMLHttpRequest.open('POST', 'index.php?ajax_script=password_secure', true);
    XMLHttpRequest.onreadystatechange = handleResponse; 
    XMLHttpRequest.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
    XMLHttpRequest.send(param);
  }

Allerdings finde ich dieses sehr unsicher, da das Passwort unverschlüsselt an das PHP Script übertragen wird. Ist dieses evtl. anders machbar?
Wie kann ich außerdem "index.php" durch die aktuelle Datei ersetzen ohne die PHP Varaible PHP_SELF zu nutzen?

[Bleistift]

SSL nutzen

[robo47]

Zitat von Bleistift

SSL nutzen

Ne alternative gibts nicht wirklich, wenn du das Formular abschickst, wird es ja auch unverschlüsselt geschickt.

[Jann Hendrik]

Eine Alternative könnte ich mir vorstellen, wenn du was mit JS programmierst, dass das auf dem client gecheckt werden kann - und es dann mit SSL übertragen wird.

Allerdings schliesst das eine Prüfung auf dem Server damit nicht aus, weil auch eine Lösung ohne JS existieren sollte.

[Ben]

Was willst du eigentlich machen? Die "Stärke" des Passworts herausfinden und ggf. eine Meldung ausgeben, dass man doch noch ein Sonderzeichen o.Ä. in das Passwort mit aufnehmen sollte?

Wenn ja, kannst du ja auch einfach via AJAX jedes Zeichen einzelnd untersuchen und in einer Flag-Variablen speichern, ob gewisse Voraussetzungen schon erfüllt sind, also z.B. Buchstaben = true/false, Ziffern = true/false, Sonderzeichen = true/false.

[$traight-$hoota]

Zitat von mano

Allerdings finde ich dieses sehr unsicher, da das Passwort unverschlüsselt an das PHP Script übertragen wird.

Auch ohne Ajax wird das Passwort unverschlüsselt übertragen, wenn du kein SSL benutzt.

Zitat von Jann Hendrik

Eine Alternative könnte ich mir vorstellen, wenn du was mit JS programmierst, dass das auf dem client gecheckt werden kann

jo, das wäre ne eine einfache möglichkeit zumindest die anzahl der übertragungnen zu vermindern. einfach die überprüfung per javascript auf dem client durchführen, also das php script nach javascript übersetzen.

[Bleistift]

Zitat von $traight-$hoota

jo, das wäre ne eine einfache möglichkeit zumindest die anzahl der übertragungnen zu vermindern. einfach die überprüfung per javascript auf dem client durchführen, also das php script nach javascript übersetzen.

Dann kann er aber nicht prüfen, ob das PW = dem alten PW ist... Bzw. er kann schon. Allerdings müsste er es dann Plaintext ausliefern (oder sich eine MD5-Funktion für JS bauen)

[mano]

Was willst du eigentlich machen? Die "Stärke" des Passworts herausfinden und ggf. eine Meldung ausgeben, dass man doch noch ein Sonderzeichen o.Ä. in das Passwort mit aufnehmen sollte?

Es wird damit die Stärke des Passworts ermittelt. Ich hatte einfach gedacht, dass es vielleicht noch eine bessere Möglichkeit gibt um Daten zu übertragen.
Mein interner Bereich wird bereits über eine SSL Verschlüsselung aufgerufen.

[pmayer]

Ja es gibt da ein paar Scripten im Internet und auch eigene Frameworks die einen HASH vom Passwort am Client berechnen und dann an ein Script auf der Serverseite senden.
Das wäre dann natürlich Bomben fest.

MfG Peter

[robo47]

Zitat von pmayer

Ja es gibt da ein paar Scripten im Internet und auch eigene Frameworks die einen HASH vom Passwort am Client berechnen und dann an ein Script auf der Serverseite senden.
Das wäre dann natürlich Bomben fest.

MfG Peter

Versteh ich das so, Hash steht in der Datenbank , User gibt das Passwort ein JS wandelt in Hash um, heißt wenn ich mein Login manipulieren will brauch ich "nur" den hash, was es ja nicht wirklich schwerer oder einfacher macht im Bezug auf das System oder ?

[$traight-$hoota]

Zitat von pmayer

Ja es gibt da ein paar Scripten im Internet und auch eigene Frameworks die einen HASH vom Passwort am Client berechnen und dann an ein Script auf der Serverseite senden.
Das wäre dann natürlich Bomben fest.

das ist vor allem bombesicher, weil der code zum verschlüsseln in javascript geschrieben von jedem eingesehen und nachgebaut werden kann.
also für eine "sichere übertragung" ist das nix.
man kann ein solches system nur verwenden wie von Bleistift ja schon beschrieben, um ein hash des ausgewählten passwords mit dem gespeicherten hash zu vergleichen:

Zitat von Bleistift

Dann kann er aber nicht prüfen, ob das PW = dem alten PW ist... Bzw. er kann schon. Allerdings müsste er esdann Plaintext ausliefern (oder sich eine MD5-Funktion für JS bauen)

das problem dabei ist aber, dass man theoretisch beliebige hashes an den server schicken kann und wenn der dann meldet "passwörter identisch", hat man auch schon das passwort geknackt. LOL.

[mepeisen]

Um sowas zum umgehen habe ich bei mir grundsätzlich einen Zähler eingebaut. Innerhalb von einer Minute darf man z.B. nur 5 mal falsch eintippen (konfigurierbar), alles weitere wird stillschweigend als Fehler ausgewiesen. Damit kann man so manche Bots kräftig in die Irre treiben und die Wahrscheinlichkeit erhöhen, dass sie das Passwort nicht mehr automatisiert knacken. Sie haben dann einfach kaum noch Durchsatz bei der Prüfung und wenn sie um diese Sicherheit nicht wissen, könnten gültige Passwörter abgewiesen werden.

Nur darum gehts: Die Hemmschwelle erhöhen. Einfache Methoden ausschließen. Eine hundertprozentige Sicherheit ist unmöglich. Einfache Regeln:

1. Niemals an den Client was ausliefern, weder Hashes, noch verschlüsselte Passwörter, noch Klartext. Weder in Cookies noch sonstwo.

2. Im Grunde ist auch das Speichern von Benutzername/Passwort in einer Session böse. Von einem Auto-Login des Benutzers sollte man Abstand nehmen und wenn man es doch will, den Benutzer darauf hinweisen, dass es gefährlich sein könnte (Vorbild zum Beispiel die Login-Box bei heise.de)

3. Validierungsprüfungen sollten nur von einem PHP-Skript ausgeführt werden, dass Ja/Nein zurückgibt. Es sollte nie die Möglichkeit geben, das Passwort direkt rauszufinden. Selbst eine Passwort-Vergessen-Seite sollte immer nur in neues Kennwort generieren.

4. SSL und vielleicht eine leichte Verschlüsselung/Verfälschung durch den Client reichen IMHO aus. Der Rest ist Humbug. Jemand, der sich die Mühe macht, sich in die Seite zu hacken per XSS, Netzwerk o.ä., so dass er die Übertragung belauschen kann, den machen Verschlüsselungen keine Mühe.