Fehler in passwordhashing.php

[kanu]

Moin,
mir ist gerade aufgefallen, dass ich als Admin die Passwörter der Mitglieder nicht mehr zurücksetzen kann. Es dauert ein paar Sekunden, dann bekomme ich einen Fehler 500. Hat das noch jemand?

Am Mailversand liegt es nicht, der klappt über das Nachrichtenmodul normal.

An den log komme ich gerade nicht dran, kann ich aber nachreichen.

[kanu]

Auf der Spielwiese kann ich es nicht nachvollziehen- da kann ich als Admin sämtliche Passwörter direkt ändern. Wie kann ich das aktivieren?

[kanu]

Hier der Auszug aus dem errorlog (lighttpd):

Code: Alles auswählen

12:24:27: (mod_fastcgi.c.2702) FastCGI-stderr: PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /var/www/intern/adm_program/system/classes/passwordhashing.php on line 76

Code: Alles auswählen

return password_hash($password, $algorithmPhpConstant, $options);

Das Generieren des neuen Passworts scheint nicht zu funktionieren und erzeugt so den Fehler.

[XimeX]

Such in der DB in der Tabelle preferences nach "system_hashing_cost". Ist der wert auf 31? Den Fehler hatten schon mehrere. Stell den Wert auf 10.

[kanu]

Danke für die fixe Antwort, ich werde das nachher mal ausprobieren. Aktuell habe ich mir phpmyadmin zerschossen, das muss ich erstmal wieder auf die Beine bekommen. Ich melde mich dann, wenn ich es überprüft habe.

So, SQL samt phpmyadmin neu installiert
Wert auf 10 geändert, klappt jetzt

[fasse]

@ximex: wie kommt denn dieser Wert 31 da rein? Ist das ein Fehler der mittlerweile behoben ist?

@kanu: hast du deine testumgebung direkt auf die Beta2 aktualisiert oder war die vorher auf der Beta 1?

[kanu]

Ich habe mir die aktuelle Version bei github besorgt, ob das beta 1 oder 2 ist kann ich nicht sagen. Zwischenschritte habe ich nicht gemacht

[XimeX]

@Fasse: ich bin den code jetzt nochmal durchgegangen (aktueller code) und könnte mir nicht erklären wie man da auf 31 kommt. Aber ich hab vor paar tagen?/wochen? schon mal eine Verbesserung eingespielt. Aber selbst davor hätte es nach meiner logik nicht dazu kommen sollen. Jetzt aber noch weniger. Ich glaube das die jetzigen 31er alles noch "restbestände" sind. Wohl aus der v3.1
Ich werd das weiter im auge behalten

[Giovanni9030]

Hallo XimeX,
habe heute das Update von der 3.1.9. auf die 3.2.-Beta 2 gemacht, der Eintrag im Feld system_hashing_cost ist immer noch die 31. Update klappte im Gegensatz zu Beta1 auf die Beta 2 ohne Probleme.

LG Hans

[XimeX]

Wie muss ich das verstehen?
War der Wert schon auf 31 wie du noch auf v3.1.9 warst oder war er es erst nach dem update?

Sind in deiner v3.2 Version diese Änderungen schon enthalten?
https://github.com/Admidio/admidio/comm ... eff5e5834e

Edit:
Ahhh ich glaub ich hab zumindest den Fehler warum der Wert nicht neu gesetzt wird. Ändere mal nachdem du die neuen v3.2 Dateien genommen hast und bevor du das Update durchführst, diese Stelle in der update.php

Code: Alles auswählen

    // Zeile 358
    // erst einmal die evtl. neuen Orga-Einstellungen in DB schreiben
    require_once('db_scripts/preferences.php');

    // calculate the best cost value for your server performance
    $benchmarkResults = PasswordHashing::costBenchmark(0.35, 'password', $gPasswordHashAlgorithm);
    $updateOrgPreferences = array('system_hashing_cost' => $benchmarkResults['cost']);

    $sql = 'SELECT org_id FROM ' . TBL_ORGANIZATIONS;
    $orgaStatement = $gDb->query($sql);

    while($orgId = $orgaStatement->fetchColumn())
    {
        $gCurrentOrganization->setValue('org_id', $orgId);
        $gCurrentOrganization->setPreferences($defaultOrgPreferences, false);
        $gCurrentOrganization->setPreferences($updateOrgPreferences, true);
    }

Das erklärt aber noch nicht warum es überhaupt dazu kommt das ein 31 dort steht

[Giovanni9030]

War der Wert schon auf 31 wie du noch auf v3.1.9 warst oder war er es erst nach dem update?

Sind in deiner v3.2 Version diese Änderungen schon enthalten?
https://github.com/Admidio/admidio/comm ... eff5e5834e

Der Wert war schon in der 3.1.9 und auch in der Beta 2 auf 31, also wurde beim Update keine Änderung gemacht.
Die Änderungen von Github waren schon enthalten.
Was mir jedoch aufgefallen ist:
In neuer Zeile 363 (alte 368) steht bei mir

Code: Alles auswählen

$defaultOrgPreferences['system_hashing_cost'] = $benchmarkResults['cost'];

In deiner update.php steht aber in Zeile 363

Code: Alles auswählen

$orga_preferences['system_hashing_cost'] = $benchmarkResults['cost'];

Für deine letzten Änderungen müsste ich nochmals zurück auf die Beta 1.
Werde das noch probieren, kann aber etwas dauern.

LG Hans

[XimeX]

Sry das war von mir vll nicht ganz verständlich ausgedrückt.
Nimm einfach nochmal die neueste Version und bau die Änderung ein die ich im vorigem Post geschrieben habe.

[fasse]

@ximex: da der Fehler scheinbar aus der 3.1 kommt, sollten wir vor der Passwortprüfung des Admins ein SQL einbauen, welches den Wert fix auf 10 setzt, wenn er größer ist.

[XimeX]

Wenn wir das einbauen sollten wir eine Überprüfung auf den Wert 31 machen. Dieser ist der maximale Wert (außer man verwendet das SHA512 Verfahren. Dann liegts bei 999999999. Deswegen auch _nicht_ >=31 abfragen)
Werte über 10 sind nichts besonderes. Eigentlich sollten die Server stark genug sein um zumindest 12 zu schaffen. Alles über 20 wäre sehr hoch für die _heutige_ Zeit. Aber noch im grünen Bereich.
Auf meinem Notebook braucht er bei cost=20 ca 60sec für einen Hash. Man sagt die ideale Hashzeit ist so zwischen 0,2 und 0,4sec.
Aber 60sec würden nicht gleich Schuld sein dass das Script abbricht. (Achtung: Stufen steigen Exponentiell!)

Falls wir noch eine neue v3.1 rausbringen sollten wir das dort auch einbauen. Falls sich die Fälle häufen sollten wir auf alle Fälle eine neue Version rausbringen.

[Giovanni9030]

Sry das war von mir vll nicht ganz verständlich ausgedrückt.
Nimm einfach nochmal die neueste Version und bau die Änderung ein die ich im vorigem Post geschrieben habe.

Hab ich gemacht.

Folgende Vorgangsweise nochmals ausgeführt:
1. Version 3.1.9 eingespielt (system_hashing_cost = 31)
2. In der Datenbank den Wert auf 10 geändert, da mein früherer Updateversuch misslang.
3. Update von 3.1.9. auf 3.2.0. Beta1 ausgeführt (diesmal ohne Fehlermeldung, vielleicht wegen der Änderung auf cost = 10)
4. In der Datenbank den Wert wieder auf 31 geändert
5. Update von 3.2.0. Beta 1 auf die 3.2.0. Beta 2 (Fehler 500 vom Server, Update braucht anscheinend ewig, dann abgebrochen)
6. In der Datenbank den Wert wieder auf 10 geändert (kein Fehler mehr und Update war extrem schnell abgeschlossen)
7. In der Datenbank steht jetzt der Wert 351000. Admidio funktioniert zwar, nur das Speichern einer Änderung dauert ewig.
8. In der Datenbank den Wert wieder auf 10 geändert, das Speichern geht jetzt wieder blitzschnell.
Bis jetzt läuft alles einwandfrei.

LG Hans